Docker container で nginx を起動するときとか、nginx.conf で何かしらのパラメータを動的に設定したいことがあると思います。server_name とか。 今回は nginx.conf で何とかして環境変数を読み込む手法を紹介します。 TL;DR env ディレクティブと ngx_http_perl_module (or lua_nginx_module) を使って、環境変数を nginx 変数に設定する。 Example server_name を環境変数 SERVER_NAME から動的に読み込む例を示します。 user nginx; worker_processes 4; env SERVER_NAME; http { perl_set $server_name_from_env 'sub { return $ENV{"SERVER_NAME"}; }'
TLS SNI support enabledとなってればOK。 これでSSLのClientHelloにくっついてきたサーバ名を拾ってくれる。 nginxの設定 nginxにインクルードするコンフィグの例、本家ドキュメント案内通り、普通に設定してよい。 ファイルを用意するのが面倒なのでHttpLuaModuleでコンテンツを返却しています。 server { listen 443; server_name cert1.example.com; root html; index index.html index.htm; ssl on; ssl_certificate certs/cert1.example.com.cert; ssl_certificate_key certs/cert1.example.com.key; location / { default_type 'text/pl
When we need to collaborate with outside companies to manage web site's content, admin tool site is sometimes used. So admin tool has to be exposed on the Internet network. In this case password authentication function is often used to restrict other client's access. But Nginx can also use client certificate authentication function. So I would like to introduce client certificate implementation in
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
Analytics cookies are off for visitors from the UK or EEA unless they click Accept or submit a form on nginx.com. They’re on by default for everybody else. Follow the instructions here to deactivate analytics cookies. This deactivation will work even if you later click Accept or submit a form. Check this box so we and our advertising and social media partners can use cookies on nginx.com to better
OpenRestyはnginxのほかにngx_luaをはじめとするCで書かれた各種サードパーティモジュールとngx_luaのAPIを利用したrestyモジュール、そしてLua/LuaJITで構成されています。 OpenRestyに含まれているnginx自体は本家のnginxと基本同じなので、別にOpenRestyを利用しなくても自分でngx_luaを組み込んだり、サーバ上にrestyモジュールを配布することで似たような環境を構築することは可能ですが、OpenRestyであれば主要なモジュールやライブラリが./configure、make、make installの一連の流れですべてゴソッとインストールされますし、OpenRestyのconfigureスクリプトはnginxのconfigureスクリプトを継承したものなのでnginxのconfigureオプションをほぼそのまま利用することもで
[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを
SREチームの@cubicdaiyaです。今回はnginxによるTCPレイヤーでのロードバランスについて解説します。 ロードバランサーとしてのnginx nginxはHTTPやTCP、UDP等の複数のレイヤーでロードバランサーとして稼働させることができます。(TCPロードバランサーは1.9.0以降、UDPロードバランサーは1.9.13以降で利用可能です) また、ngx_http_ssl_module や ngx_stream_ssl_module を利用することでそれぞれのレイヤーでTLSを有効化することも可能です。 TCPロードバランサー用のモジュールを有効にする HTTPレイヤーでロードバランスするためのモジュールはデフォルトで組み込まれますが、TCP(とUDP)レイヤーでロードバランスするにはnginxのconfigureスクリプトに--with-stream(あるいは --with
Mozilla SSL Configuration Generator Redirecting to the updated SSL Configuration Generator…
解説 worker_processes auto; - Nginx本体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf
user www www; ## Default: nobody worker_processes 5; ## Default: 1 error_log logs/error.log; pid logs/nginx.pid; worker_rlimit_nofile 8192; events { worker_connections 4096; ## Default: 1024 } http { include conf/mime.types; include /etc/nginx/proxy.conf; include /etc/nginx/fastcgi.conf; index index.html index.htm index.php; default_type application/octet-stream; log_format main '$remote_addr - $r
Nginx Caching See how to cache both dynamic and static content using Nginx! Like Varnish, Nginx is a very capable web cache. Many administrators reach for Varnish, often before it's really needed. However, there are two things to know about Nginx: Nginx can serve static content (directly) very, very efficiently. This is good when the static files are on the same server as Nginx. Nginx can also act
Nginxでは, serverコンテキストのlocationコンテキストにおいて, proxy_passディレクティブを利用することで任意のホストにアクセスを転送することができます. 例えば, serverコンテキストにおいて, location / { proxy_pass http://127.0.0.1:5000; } みたいに書いてあげれば, localhostの5000番ポートにアクセスを転送することが出来ます. Webサービスでは, こういう感じでNginxが443番(HTTPS)や80番ポート(HTTP)で受けたアクセスを5000番ポートなどで動いているWebアプリケーションに転送している訳です. で, このproxy_passディレクティブは, IPをそのまま書くのではなく, 次のようにドメインを書くこともできます. location / { proxy_pass http
(追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調
Nginx で location の判定方法と優先順位を調べる
ピクセルトラッキングを想定した設定で、Nginx on EC2(c3.large) という環境で、極限まで設定をして、どれぐらいさばけるのか運用中、パフォーマンステストしてる時は、別のところに問題があり、Nginx自体の性能限界までテストできなかったので、実際どこまでいけるのかは計測できてない。 秒間1万とか2万は行けてたと思う、ちなみに実際の運用では秒間9000以上とかを記録していて、サーバ自体にはかなり余裕があるので、記録はまだまだ伸びると思う。 ちなみに empty_gif は応答が短すぎて、Nginx の $request_time では記録できない... 全部 "0.000" だから、どれぐらい掛かってるのか分からん...。 nginx.confの設定 user nginx; worker_processes auto; error_log /var/log/nginx/erro
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く