第881回では、家庭内のサーバーをVPN越しに公開できるリバースプロキシPangolinを紹介しました。今回はもっとシンプルなリバースプロキシ管理ソフトである、Nginx Proxy Managerを紹介します。
リバースプロキシの必要性
はるか昔、WebサイトはApacheなどのWebサーバー上に直接デプロイするのが一般的でした。ですが現在では、アプリケーションをホストするWebサーバーの前段にリバースプロキシを置く、二段階の構成が一般的となっています。
これはアプリケーションの多くが、コンテナやVMといった独立した環境でホストされるようになってきたことや、フレームワークが独自のアプリケーションサーバーを持っていることに起因しています。またアクセス制御、ロードバランス、SSL証明書の管理などを考慮すると、こうした処理はアプリケーション本体から切り離し、前段のリバースプロキシに一任したほうがメンテナンス性も向上するためです。
そしてリバースプロキシとしてよく利用されているのが、高速なWebサーバーとしても有名なnginxです。nginx + コンテナ/VMという構成は、今時のWebアプリの構成の鉄板と言えるでしょう。
Nginx Proxy Managerとは
nginx + Docker/
最初の1回だけならともかく、頻繁にコンテナの起動と削除を繰り返す開発環境では、やってられないでしょう。アプリ毎にアクセス制限をかけようなどと思ったら、さらに面倒なことになります。
そこでnginxの設定ファイルのコピペに疲れた貴方へお勧めしたいのが、Webベースでリバースプロキシを管理でき、SSL証明書の自動取得にも対応しているNginx Proxy Managerです。
Nginx Proxy Managerのデプロイ
Nginx Proxy Manager
$ sudo apt install -U -y docker.io docker-compose-v2
必須ではありませんが、NPMとアプリケーションコンテナを同一マシン上で動作させる場合、専用のコンテナネットワークを作成しておくほうがよいでしょう。このメリットは以下の2つです。
- NPMが対象のアプリケーションコンテナをサービス名で名前解決できる
- アプリケーションコンテナが、ホストにポートを公開する必要がない
特に後者が重要です。コンテナ同士が同一のコンテナネットワークに所属しない場合、Dockerの
今回は
$ sudo docker network create nginxproxy
NPM用のディレクトリを作成してから、その中にcompose.
NPMがHTTP/
$ mkdir ~/npm && cd ~/npm
$ cat >compose.yaml <<EOF
services:
app:
image: 'jc21/nginx-proxy-manager:2.13.5'
restart: unless-stopped
environment:
TZ: "Asia/Tokyo"
ports:
- '80:80'
- '81:81'
- '443:443'
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
networks:
default:
external: true
name: nginxproxy
EOF
準備ができたらNPMを起動します。
$ sudo docker compose up -d
サインインとデフォルトサイトの設定
Webブラウザから、
NPMにサインインすると、以下のダッシュボードが表示されます。ダッシュボードには設定済みのプロキシに関する情報が表示されます。
まずは右上のアイコンをクリックして、言語を日本語にしておきましょう。
プロキシの設定に先立って、デフォルトサイトを設定しましょう。ヘッダから
デフォルトでは
開発環境などでは、間違ったホストにアクセスしたことや、それに対してNPMが応答していることを明確にしたいでしょう。こうしたケースでは、デフォルトのまま運用するのが便利です。対してインターネットからアクセス可能にしたい場合は、無数にやってくる不正アクセスに対して、律儀に応答を返すのは悪手です。その場合は404や、444を返すことも検討してください。444はnginx独自のレスポンスコードで、クライアントに対して一切のレスポンスを返さず接続を閉じます。また別のサイトへリダイレクトさせたり、カスタム応答ページを返すことも可能となっています。
プロキシの設定
それではアプリケーションへのプロキシを設定しましょう。NPMのプロキシには、4つの種類があります。
プロキシホスト
プロキシホストはもっとも一般的な、HTTP/
以下のコマンドを実行し、コンテナを起動してください。compose.
$ mkdir ~/whoami && cd ~/whoami
$ cat >compose.yaml <<EOF
services:
whoami:
image: traefik/whoami:v1.11
container_name: whoami-service
restart: unless-stopped
networks:
default:
external: true
name: nginxproxy
EOF
$ sudo docker compose up -d
NPMのダッシュボードから
プロキシホスト作成のダイアログが表示されます。ドメイン名には、このホストへのアクセスに使うFQDNを入力してください。スキームは
今時のWebアプリには、ドメイン名と正規のSSL証明書がないと動かないものも増えてきました。ローカルなテスト環境であっても、従来のようにIPアドレスと自己署名証明書というわけにはいきません。NPMではプロキシホストの作成と同時に、Let's EncryptによるSSL証明書を取得できます。
NMPが管理している証明書から使用するもの選択します。ですがまだ証明書がないため、ここでは
筆者はAmazon Route 53でドメインをホストしているため、DNSプロバイダーは
最後に
プロキシホストのドメインにアクセスしてみましょう。whoamiコンテナにアクセスがプロキシされ、HTTPリクエストの内容が表示されました。またLet's Encryptの証明書によって、HTTPS通信が行えています。
ストリーム
ストリームはHTTP/
受信ポートには、NPMが待ち受けるポート番号を指定します。ここではわかりやすく、8022としてみました。
ストリームの場合、NPMが待ち受けるポートを追加で開く必要があります。NPMのcompose.
services:
(...略...)
ports:
- '80:80'
- '81:81'
- '443:443'
- '8022:8022' ← この行を追加
コンテナを再起動します。compose.
$ sudo docker compose up -d
これでホストの8022番ポートがNPMコンテナの8022番ポートと繋がりました。このポートへのアクセスは、NPMが別サーバー
リダイレクトホスト
リダイレクトホストはリバースプロキシではなく、クライアントを別のURLへ転送する機能です。クライアントからのリクエストに対して、NPMはプロキシせず、HTTPレスポンスコード30Xを返します。クライアントのブラウザはこの応答を受け取り、レスポンスに含まれる新しいURLへ自動的に再アクセスします。新しいドメインにサービスを引越したような場合に、古いサービスのドメインをNPMで受け、新ドメインへリダイレクトするといった使い方が考えられます。
404ホスト
404ホストは、文字通り常に404を返す機能です。普段利用することはないでしょうが、廃止したドメインの後始末などに役立つかもしれません。
Nginx Proxy Managerを使えば、面倒なリバースプロキシとSSL証明書の管理を、Webから手軽にポチポチで行えます。もちろんPangolinでも、WireGuardなしのローカルモードで動かせば、これと同様のことは可能です。ただしPangolinはやはり、VPN越しに使うことで真価を発揮するソフトです。また設定も少し複雑なため、LAN内での手軽なリバースプロキシ管理という面では、Nginx Proxy Managerに軍配が上がると筆者は考えています。さらに今回は紹介しきれませんでしたが、Basic認証やIPアドレスベースでアクセス制限をかけることも可能です。
nginxのリバースプロキシ設定を手作業でメンテしている方は、Nginx Proxy Managerを試してみてください。