nginx-proxy – docker-genを使用したDockerコンテナの自動nginxプロキシ

Github: https://github.com/jwilder/nginx-proxy

docker-genを使用したDockerコンテナの自動nginxプロキシ

nginx-proxyは、nginxとdocker-genを実行するコンテナを設定します。 docker-genは、nginxのリバースプロキシ設定を生成し、コンテナの起動と停止時にnginxをリロードします。

これを使用する理由については、Dockerの自動Nginxリバースプロキシを参照してください。

使用法

それを実行するには：

$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

次に、env varでプロキシしたいコンテナを起動しますVIRTUAL_HOST=subdomain.youdomain.com

$ docker run -e VIRTUAL_HOST=foo.bar.com  ...

プロキシされているコンテナは、 Dockerfile EXPOSEディレクティブを使用するか、 --expose docker runまたは--exposeフラグを使用して、プロキシされるポートを公開する必要がありdocker create 。

foo.bar.comをnginx-proxyを実行しているホストに転送するようにDNSが設定されている場合、その要求はVIRTUAL_HOSTのenv varが設定されたコンテナにルーティングされます。

画像の変形

nginx-proxyイメージには2つの味があります。

jwilder / nginx-proxy：最新版

この画像は、debian：jessieベースのnginx画像を使用しています。

$ docker pull jwilder/nginx-proxy:latest

jwilder / nginx-proxy：アルパイン

この画像は、nginx：alpine画像に基づいています。この画像を使用して、HTTP / 2（最近のChromeバージョンで必要とされるALPNを含む）を完全にサポートします。有効な証明書も必要です（詳しくは、以下の “letsencryptを使用したSSLサポート”を参照してください）。

$ docker pull jwilder/nginx-proxy:alpine

ドッカーの作成

version: '2'

services:
  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

  whoami:
    image: jwilder/whoami
    environment:
      - VIRTUAL_HOST=whoami.local

$ docker-compose up
$ curl -H "Host: whoami.local" localhost
I'm 5b129ab83266

IPv6のサポート

値trueをENABLE_IPV6環境変数に渡すことによって、nginx-proxyコンテナのIPv6サポートを有効にすることができます。

$ docker run -d -p 80:80 -e ENABLE_IPV6=true -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

複数のポート

コンテナが複数のポートを公開している場合、nginx-proxyはデフォルトでポート80上で動作するサービスになります。別のポートを指定する必要がある場合は、VIRTUAL_PORT env varを設定して別のポートを選択できます。コンテナが1つのポートのみを公開し、VIRTUAL_HOST環境変数が設定されている場合、そのポートが選択されます。

複数のホスト

コンテナに複数の仮想ホストをサポートする必要がある場合は、各エントリをカンマで区切ることができます。たとえば、 foo.bar.com,baz.bar.com,bar.comおよび各ホストは同じ設定になります。

ワイルドカードホスト

*.bar.comやfoo.bar.*ように、ホスト名の先頭と末尾にワイルドカードを使用することもできます。あるいは、正規表現でさえ、 ~^foo\.bar\..*\.xip\.ioを使ったxip.ioのようなワイルドカードDNSサービスと組み合わせて使うと、 foo.bar.127.0.0.1にマッチしfoo.bar.127.0.0.1.xip.io 、 foo.bar.10.0.2.2.xip.ioと指定された他のすべてのIP。このトピックの詳細は、nginxのserver_namesに関するドキュメントを参照してください。

複数のネットワーク

Docker 1.9でオーバーレイネットワークを追加すると、 nginx-proxyコンテナが複数のネットワーク上のバックエンドコンテナに接続する必要が生じる場合があります。デフォルトでは、 nginx-proxyコンテナが作成されたときに--netフラグを渡さないと、デフォルトのbridgeネットワークにのみ接続されます。つまり、 bridge以外のネットワーク上のコンテナに接続することはできません。

nginx-proxyコンテナを別のネットワークに接続する場合は、 --net=my-network docker createコマンドまたはdocker runコマンドで--net=my-networkオプションを渡す必要があります。この執筆時点では、コンテナ作成時には1つのネットワークしか指定できません。他のネットワークにdocker network connectするには、コンテナの作成後にdocker network connectコマンドを使用します。

$ docker run -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock:ro \
    --name my-nginx-proxy --net my-network jwilder/nginx-proxy
$ docker network connect my-other-network my-nginx-proxy

この例ではmy-nginx-proxyコンテナがmy-networkとmy-other-network接続されmy-networkそれらのネットワークに接続されている他のコンテナにプロキシできるようになります。

インターネットとローカルネットワークアクセス

パブリックインターネットからのトラフィックがあなたのnginx-proxyコンテナにアクセスすることを許可している場合は、一部のコンテナを内部ネットワークのみに制限し、パブリックインターネットからアクセスすることはできません。内部ネットワークに制限されるべきコンテナでは、環境変数NETWORK_ACCESS=internal設定する必要があります。デフォルトでは、内部ネットワークは127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16と定義されています。内部と見なされるネットワークのリストを変更するには、 /etc/nginx/network_internal.conf nginx-proxy /etc/nginx/network_internal.confにあるnginx-proxyファイルを次の内容で/etc/nginx/network_internal.confし、必要に応じて編集します。

# These networks are considered "internal"
allow 127.0.0.0/8;
allow 10.0.0.0/8;
allow 192.168.0.0/16;
allow 172.16.0.0/12;

# Traffic from all other networks will be rejected
deny all;

内部専用アクセスが有効になっているHTTP 403 Forbidden 、 HTTP 403 Forbidden拒否された外部クライアント

クライアントIPを隠すnginx-proxy前にロードバランサ/リバースプロキシがある場合（例：AWS Application / Elastic Load Balancer）、クライアントのIPを抽出するためにnginxのrealipモジュール（既にインストール済み）を使用する必要がありますHTTP要求ヘッダーから取得します。詳細については、 nginxのrealipモジュールの設定をご覧ください。この設定は、新しい設定ファイルに追加して/etc/nginx/conf.d/マウントすることができます。

SSLバックエンド

リバースプロキシをHTTPの代わりにHTTPSを使用してバックエンドに接続する場合は、バックエンドコンテナにVIRTUAL_PROTO=httpsを設定しVIRTUAL_PROTO=https 。

注意： VIRTUAL_PROTO=httpsを使用し、バックエンドコンテナがポート80と443を公開している場合、 nginx-proxyはポート80でHTTPSを使用します。これはほとんど確実ではないので、 VIRTUAL_PORT=443も含める必要があります。

uWSGIバックエンド

uWSGIバックエンドに接続する場合は、バックエンドコンテナにVIRTUAL_PROTO=uwsgiを設定します。バックエンドコンテナは、ソケットではなくポートでリスンし、そのポートを公開する必要があります。

FastCGIバックエンド

FastCGIバックエンドに接続する場合は、バックエンドコンテナにVIRTUAL_PROTO=fastcgiを設定します。バックエンドコンテナは、ソケットではなくポートでリスンし、そのポートを公開する必要があります。

FastCGI Filrルートディレクトリ

fastcgiを使用する場合は、ルートディレクトリにVIRTUAL_ROOT=xxxを設定できます

デフォルトのホスト

nginxのデフォルトホストを設定するには、env var DEFAULT_HOST=foo.bar.comを使用します。

$ docker run -d -p 80:80 -e DEFAULT_HOST=foo.bar.com -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

別々のコンテナ

nginx-proxyは、 jwilder / docker-genイメージと公式のnginxイメージを使用して2つの独立したコンテナとしても実行できます。

ドッキング・ソケットが公開されているコンテナ・サービスにバインドされないようにするには、これを行うことができます。

ドッカーの作成でこのパターンをデモすることができます：

$ docker-compose --file docker-compose-separate-containers.yml up
$ curl -H "Host: whoami.local" localhost
I'm 5b129ab83266

nginxプロキシを別のコンテナとして実行するには、ホストシステムにnginx.tmplが必要です。

まずボリュームを使ってnginxを起動します：

$ docker run -d -p 80:80 --name nginx -v /tmp/nginx:/etc/nginx/conf.d -t nginx

共有ボリュームとテンプレートを使用してdocker-genコンテナを起動します。

$ docker run --volumes-from nginx \
    -v /var/run/docker.sock:/tmp/docker.sock:ro \
    -v $(pwd):/etc/docker-gen/templates \
    -t jwilder/docker-gen -notify-sighup nginx -watch /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf

最後に、環境変数VIRTUAL_HOSTてコンテナを起動します。

$ docker run -e VIRTUAL_HOST=foo.bar.com  ...

letsencryptを使用したSSLサポート

letsencrypt-nginx-proxy-companionは、 nginx-proxyの軽量コンパニオンコンテナです。 Let’s Encrypt証明書の作成/更新を自動的に許可します。

SSLサポート

SSLは、単一のホスト、ワイルドカード、およびSNI証明書を使用して証明書の命名規則を使用するか、オプションで環境変数として証明書名（SNI用）を指定することでサポートされます。

SSLを有効にするには：

$ docker run -d -p 80:80 -p 443:443 -v /path/to/certs:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

/path/to/certsの内容には、使用中の仮想ホストの証明書と秘密鍵が含まれている必要があります。証明書とキーには、 .crtと.key拡張子を持つ仮想ホストの名前を付ける必要が.crt .key 。たとえば、 VIRTUAL_HOST=foo.bar.comコンテナには、 foo.bar.com.crtにfoo.bar.com.keyファイルとfoo.bar.com.keyファイルがfoo.bar.com.keyです。

仮想化環境（Hyper-V、VirtualBoxなど）でコンテナを実行している場合、/ path / to / certsはその環境に存在するか、その環境にアクセス可能にする必要があります。デフォルトでは、Dockerはホストマシン上のディレクトリを仮想マシン内で動作するコンテナにマウントすることができません。

Diffie-Hellmanグループ

Diffie-Hellmanグループはデフォルトで有効になっており、 /etc/nginx/dhparam/dhparam.pemは/etc/nginx/dhparam/dhparam.pemたキーが/etc/nginx/dhparam/dhparam.pemます。その場所に別のdhparam.pemファイルをマウントして、デフォルトのcertを上書きすることができます。仮想ホストごとにカスタムdhparam.pemファイルを使用するには、 dhparam接尾辞と.pem拡張子を持つ仮想ホストの後にファイル名を付けます。たとえば、 VIRTUAL_HOST=foo.bar.comコンテナには、 /etc/nginx/certs foo.bar.com.dhparam.pemディレクトリにfoo.bar.com.dhparam.pemファイルがfoo.bar.com.dhparam.pemです。

注： dhparam.pemファイルを/etc/nginx/dhparam/dhparam.pemマウントしないと、起動時に1つ生成されます。新しいdhparam.pemを生成するには数分かかるので、バックグラウンドでは低い優先順位で実行されます。生成が完了すると、 dhparam.pemは永続ボリュームに保存され、nginxがリロードされます。この生成プロセスは、初めてnginx-proxyを起動するときにのみ発生します。

互換性に関する警告：デフォルトで生成されたdhparam.pemキーは、A +セキュリティ用の2048ビットです。一部の古いクライアント（Java 6および7など）では、1024ビットを超えるDHキーをサポートしていません。これらのクライアントをサポートするには、独自のdhparam.pem提供するか、 -e DHPARAM_BITS=1024を渡して起動時に1024ビットのキーを生成するようにnginx-proxyに指示する必要があります。

別のコンテナの設定では、事前生成されたキーは使用できず、 jwilder / docker-genイメージもoffng nginxイメージも生成しません。それでもなお別のコンテナ設定でA +セキュリティが必要な場合は、手動で2048ビットのDHキーファイルを生成し、nginxコンテナの/etc/nginx/dhparam/dhparam.pemマウントする必要があります。

ワイルドカード証明書

ワイルドカード証明書とキーの名前は、ドメイン名の後に.crtと.key拡張子を付けて指定する必要が.crt .key 。たとえば、 VIRTUAL_HOST=foo.bar.comは、cert name bar.com.crtとbar.com.key使用します。

SNI

証明書が複数のドメイン名をサポートしている場合は、 CERT_NAME=<name>を使用してコンテナを起動し、使用する証明書を識別できます。たとえば、 *.foo.comと*.bar.com証明書にshared.crtとshared.keyという名前をshared.crtことができます。 VIRTUAL_HOST=foo.bar.comとCERT_NAME=shared動作するコンテナは、この共有証明書を使用します。

SSLサポートのしくみ

デフォルトのSSL暗号設定は、Firefox 1、Chrome 1、IE 7、Opera 5、Safari 1、Windows XP IE8、Android 2.3、Java 7に戻るクライアントとの互換性を提供するMozilla中間プロファイルに基づいています。DES-セキュリティのためにTLSベースの暗号が削除されました。この設定では、HSTS、PFS、OCSPステープル、SSLセッションキャッシュも有効になります。現在、TLS 1.0,1.1、および1.2がサポートされています。 TLS 1.0は廃止されましたが、その寿命は2018年6月30日までです。削除されたブラウザはChrome <22、Firefox <27、IE <11、Safari <7、iOS <5、Androidブラウザ<5。

下位互換性が要求されない場合は、環境変数SSL_POLICY=Mozilla-Modernをコンテナに含めることで、 Mozillaの最新プロファイルを使用することができます。このプロファイルは、Windows 7、Edge、Opera 17、Safari 9、Android 5.0、Java 8のFirefox 27、Chrome 30、IE 11のクライアントと互換性があります。

SSL_POLICY環境変数で使用できるその他のポリシーは、 Mozilla-OldおよびAWS ELBセキュリティポリシーです AWS-TLS-1-2-2017-01 、 AWS-TLS-1-1-2017-01 、 AWS-2016-08 、 AWS-2015-05 、 AWS-2015-03およびAWS-2015-03 。

Mozilla-Oldポリシーは、互換性のために1024ビットのDHキーを使用する必要がありますが、このコンテナは2048ビットのキーを生成します。 Diffie-Hellman Groupsセクションでは、これをバイパスするさまざまな方法（グローバルまたは仮想ホストごと）について詳しく説明します。

ポート80と443が公開されている場合のプロキシのデフォルトの動作は、次のとおりです。

コンテナに使用可能な証明書がある場合、ポート80はそのコンテナの443にリダイレクトされ、利用可能な場合にHTTPSが常に優先されます。
コンテナに使用可能な証明書がない場合、503が返されます。

後者の場合、接続を確立するための証明書がないため、ブラウザに接続エラーが発生する可能性があることに注意してください。 default.crtとdefault.keyという名前の自己署名付き証明書または一般的な証明書を使用すると、クライアントブラウザはSSL接続（警告あり）を受け、その後500を受け取ることができます。

SSLにリダイレクトせずにSSLモードと非SSLモードの両方でトラフィックを処理するには、環境変数HTTPS_METHOD=noredirect （デフォルトはHTTPS_METHOD=redirect ）を含めることができます。非SSLサイトをHTTPS_METHOD=nohttpで完全に無効にするか、 HTTPS_METHOD=nohttpでHTTPSサイトを無効にすることもできます。 HTTPS_METHODは、デフォルトの動作をオーバーライドする各コンテナで指定する必要があります。 HTTPS_METHOD=noredirectが使用されている場合、HTTPSユーザーがクライアントによってリダイレクトされないように、厳密なトランスポートセキュリティ（HSTS）は無効になっています。この設定を変更してもHTTPサイトにアクセスできない場合は、ブラウザがおそらくHSTSポリシーをキャッシュしていて、自動的にHTTPSにリダイレクトされます。ブラウザのHSTSキャッシュを消去するか、シークレットウィンドウ/別のブラウザを使用する必要があります。

既定では、 HTTP Strict Transport Security（HSTS）は、HTTPSサイトに対してmax-age=31536000で有効になっています。環境変数HSTS=offを使用してHSTSを無効にするか、 HSTS=max-age=31536000; includeSubDomains; preloadようなカスタムHSTS設定を使用できますHSTS=max-age=31536000; includeSubDomains; preload HSTS=max-age=31536000; includeSubDomains; preload HSTS=max-age=31536000; includeSubDomains; preload 。
警告：HSTSは、HTTPSバージョンのサイトをhttp://手動で入力しても、 max-age間、サイトに強制的にアクセスします。 HSTS応答を受け取った後にHTTPサイトにアクセスする唯一の方法は、ブラウザのHSTSキャッシュをクリアすることです。

基本認証のサポート

仮想ホストを保護できるようにするには、/ etc / nginx / htpasswd / $ VIRTUAL_HOSTディレクトリに相当するVIRTUAL_HOST変数を作成する必要があります

$ docker run -d -p 80:80 -p 443:443 \
    -v /path/to/htpasswd:/etc/nginx/htpasswd \
    -v /path/to/certs:/etc/nginx/certs \
    -v /var/run/docker.sock:/tmp/docker.sock:ro \
    jwilder/nginx-proxy

htpasswdファイルを作成するマシンでapache2-utilsが必要です。次の手順に従ってください

カスタムNginx設定

環境変数を使用してNginxを設定する必要がある場合は、プロキシ全体またはVIRTUAL_HOST単位でカスタム設定ファイルを提供できます。

デフォルトのプロキシ設定を置き換える

nginxコンテナのデフォルトプロキシ設定を置き換える場合は、 /etc/nginx/proxy.conf nginx /etc/nginx/proxy.conf設定ファイルを追加します。デフォルト設定のファイルは次のようになります。

# HTTP 1.1 support
proxy_http_version 1.1;
proxy_buffering off;
proxy_set_header Host $http_host;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $proxy_connection;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto;
proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl;
proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port;

# Mitigate httpoxy attack (see README for details)
proxy_set_header Proxy "";

注：このファイルを指定すると、デフォルトに置き換わります。 .tmplファイルをチェックして、必要なオプションがすべてそろっていることを確認してください。

注：既定の構成では、 Proxy HTTP要求ヘッダーが川下のサーバーに送信されないようにします。これは、攻撃者がいわゆるhttpoxy攻撃を使用するのを防ぎます。クライアントがこのヘッダーを送信する正当な理由はなく、脆弱な言語/プラットフォーム（ CVE-2016-5385 、 CVE-2016-5386 、 CVE-2016-5387 、 CVE-2016-5388 、 CVE-2016-1000109 、 CVE-2016-1000110 、 CERT-VU#797896 ）。

プロキシワイド

プロキシ単位で設定を追加するには、 /etc/nginx/conf.d終わる名前を使用して/etc/nginx/conf.d設定ファイルを追加します。

これは、 RUNコマンドでファイルを作成するか、またはファイルをconf.d COPYすることによって、派生したイメージで実行できます。

FROM jwilder/nginx-proxy
RUN { \
      echo 'server_tokens off;'; \
      echo 'client_max_body_size 100m;'; \
    } > /etc/nginx/conf.d/my_proxy.conf

または、 docker runコマンドでカスタム構成にマウントすることで実行できます。

$ docker run -d -p 80:80 -p 443:443 -v /path/to/my_proxy.conf:/etc/nginx/conf.d/my_proxy.conf:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

VIRTUAL_HOSTごと

VIRTUAL_HOST単位で設定を追加するには、設定ファイルを/etc/nginx/vhost.d追加します。 VIRTUAL_HOST終わる任意の名前を持つ複数の設定ファイルを許可するプロキシ全体の場合とは異なり、 VIRTUAL_HOSTファイル名は、 VIRTUAL_HOST後に正確にVIRTUAL_HOSTする必要があります。

バックエンドを追加したり削除したりして仮想ホストを動的に構成できるようにするには、派生イメージを使用するか、個別の構成ファイルをマウントするのではなく、外部ディレクトリを/etc/nginx/vhost.dとしてマウントするのが最も理に/etc/nginx/vhost.dます。

たとえば、 app.example.comという名前の仮想ホストがある場合は、そのホストのカスタム設定を次のように指定できます。

$ docker run -d -p 80:80 -p 443:443 -v /path/to/vhost.d:/etc/nginx/vhost.d:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
$ { echo 'server_tokens off;'; echo 'client_max_body_size 100m;'; } > /path/to/vhost.d/app.example.com

1つのコンテナに複数のホスト名（例： VIRTUAL_HOST=example.com,www.example.com ）を使用している場合は、各ホスト名に仮想ホスト構成ファイルが存在する必要があります。複数の仮想ホスト名に同じ設定を使用する場合は、シンボリックリンクを使用できます。

$ { echo 'server_tokens off;'; echo 'client_max_body_size 100m;'; } > /path/to/vhost.d/www.example.com
$ ln -s /path/to/vhost.d/www.example.com /path/to/vhost.d/example.com

VIRTUAL_HOSTごとのデフォルト設定

大部分の仮想ホストがデフォルトの単一設定を使用し、いくつかの特定の設定を上書きするようにするには、これらの設定を/etc/nginx/vhost.d/defaultファイルに追加します。このファイルは、 /etc/nginx/vhost.d/{VIRTUAL_HOST}ファイルが関連付けられていない仮想ホストで使用されます。

VIRTUAL_HOST環境単位の設定

VIRTUAL_HOST単位で “location”ブロックに設定を追加するには、前のセクションと同じように/etc/nginx/vhost.d下に設定ファイルを追加します。ただし、接尾辞_locationを除きます。

たとえば、 app.example.comという名前の仮想ホストがあり、別のカスタムファイルでproxy_cache my-cacheを設定した場合は、次のようにプロキシキャッシュを使用するように指示できます。

$ docker run -d -p 80:80 -p 443:443 -v /path/to/vhost.d:/etc/nginx/vhost.d:ro -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
$ { echo 'proxy_cache my-cache;'; echo 'proxy_cache_valid  200 302  60m;'; echo 'proxy_cache_valid  404 1m;' } > /path/to/vhost.d/app.example.com_location

$ { echo 'proxy_cache my-cache;'; echo 'proxy_cache_valid  200 302  60m;'; echo 'proxy_cache_valid  404 1m;' } > /path/to/vhost.d/app.example.com_location
$ ln -s /path/to/vhost.d/www.example.com /path/to/vhost.d/example.com

VIRTUAL_HOSTあたりのデフォルト設定

大部分の仮想ホストがデフォルトの単一locationブロック設定を使用し、いくつかの特定のものをオーバーライドするようにするには、これらの設定を/etc/nginx/vhost.d/default_locationファイルに追加します。このファイルは、 /etc/nginx/vhost.d/{VIRTUAL_HOST}_locationファイルが関連付けられていない仮想ホストで使用されます。

貢献する

プルリクエストまたは問題を送信する前に、githubで既存の問題またはプルリクエストがまだ開いていないことを確認してください。

ローカルでのテストの実行

テストを実行するには、 jwilder/nginx-proxy:testタグがjwilder/nginx-proxy:testものをテストするためにドッカーイメージを準備する必要がありますjwilder/nginx-proxy:test ：

docker build -t jwilder/nginx-proxy:test .  # build the Debian variant image

test / pytest.shスクリプトを呼び出します。

次に、画像のアルパインバリアントを作成します。

docker build -f Dockerfile.alpine -t jwilder/nginx-proxy:test .  # build the Alpline variant image

test / pytest.shスクリプトを再度呼び出します。

システムにmakeコマンドがある場合は、以下make呼び出してそれらのタスクを自動化することができます。

make test

テストスイートのしくみとtest / README.mdファイルでの新しいテストの記述方法の詳細を知ることができます。