編集：@pfaffman 氏が、以前 @tophee 氏が書いた内容を基に、これを独立したトピックとして書き直しました。私はまだテストしていないため、Chris の言葉を移動させた結果、誤りがあればそれは @pfaffman の責任である可能性が高いです。
Run other websites on the same machine as Discourse に記載されているように手動で行う代わりに、NGINX Proxy Manager を使用しない理由はあるでしょうか？
私はすでにこれを使用しています。自宅サーバーでしばらく使っていたのですが、Discourse インスタンスを新しいクラウドサーバーに移行した際、4 年前に旧サーバーで行った NGINX リバースプロキシの設定のほとんどを忘れていたことに気づきました。「なら NGINX Proxy Manager でやろう」と思いました。驚いたことに、ここ meta ではあまり言及されていないことに気づき、見落としている欠点があるのではないかと考え始めました…
確かに、これは少し試行錯誤が必要でしたが、以下のように動作させることができました（これが最善の方法である保証はありません。実際、より良い方法があることは確かです。そのため、修正や改善の提案を大歓迎します）：
まず、Discourse インスタンスにアクセスする方法は 2 つあります。1. ポートを公開する、2. WebSocket を経由する。このフォーラムのどこかで WebSocket の方が高速で効率的だと学びましたので、私はそれを使用していますが、ポートを公開する方がはるかに簡単です。したがって、ソケットが動作しない場合は、ポートを公開してみてください。混乱を避けるために：ポート経由で Discourse にアクセスするには、以下の手順 0、1、2、3、4、8 をfollowしてください。WebSocket を使用したい場合は、手順 0、1、5、6、7、8、9 を follow してください。
0. 出発点
まず、30 分間の標準インストール を完了したと仮定します。また、リバースプロキシを使用する場合は不要であるため、Discourse が Let’s Encrypt 証明書を取得していないと仮定します。NGINX Proxy Manager がそれを処理します。すでに証明書を持っている場合でも問題ありません。NGINX Proxy Manager が新しいものを取得するだけです。
1. NGINX Proxy Manager のインストール
次のステップは、NGINX Proxy Manager をインストールすることです。これにより、2 つの Docker コンテナ（NGINX Proxy Manager とそのデータベースコンテナ）が実行されます。
次に、あなたが尋ねている難しい部分があります。
最初の障害は、Discourse がデフォルトの Docker bridge ネットワークで実行されているのに対し、NGINX Proxy Manager はデフォルトで「ユーザー作成ネットワーク」（私の場合は npm_default と呼ばれます）で実行されていることです。つまり、NGINX Proxy Manager は Discourse を見ることができません。
2. すべてのコンテナをデフォルトの bridge ネットワークに移動させる
Discourse をカスタムネットワークに移動できるかどうか、またその方法がわからない 限り、NGINX Proxy Manager をデフォルトの bridge ネットワークに移動させる必要があります。これを行うには、docker compose ファイル 内の NGINX Proxy Manager の両方のコンテナに network_mode: bridge を追加します。
3. サービス名ではなく IP アドレスを使用する
次の問題は、デフォルトの docker compose ファイルを単に bridge ネットワークに移動しただけでは機能しなくなる点です。NGINX Proxy Manager はデータベースコンテナを見つけられなくなります。これは、サービス名の内部 DNS 解決（docker-compose ファイルが依存しているもの）は、ユーザー作成されたネットワークでのみ利用可能であり、デフォルトの Docker ネットワークでは利用できないためです。そのため、ハードコーディングされた IP アドレスに頼る必要があります（これは、コンテナの IP が変更された場合に機能しなくなるため、決して最適な解決策ではありません）。したがって、コンテナが機能しないことが分かっているにもかかわらず起動し、NGINX Proxy Manager のデータベースコンテナの IP アドレスをメモし、docker compose ファイル内の DB_MYSQL_HOST: "db" を DB_MYSQL_HOST: "<db_container_IP>" に置き換える必要があります。
これで、すべてのコンテナがデフォルトの bridge ネットワークにあり、NGINX Proxy Manager が Discourse とそのデータベースの両方を見られるようになります。
4. Discourse をアクセス可能にする
しかし、「Discourse を見る」ことと「アクセスできる」ことは同じではありません。したがって、NGINX Proxy Manager が転送するトラフィックを Discourse が受け入れるようにする必要があります。WebSocket を使用することにこだわらない場合、NGINX Proxy Manager を Discourse コンテナの IP のポート 80（443 ではない）に指し示すだけでよいでしょう。以下のように：
ただし、これはテストしていません。前述の通り、私は WebSocket 設定を使用しており、それにはさらにいくつかのステップが必要です。上記のホスト名/IP とポートは、WebSocket を使用する場合無視されます。
5. app.yml を設定して WebSocket を使用する
これは OP で説明されていますので、ここでは深入りしません。
6. NGINX Proxy Manager コンテナに WebSocket をマウントする
NGINX Proxy Manager が WebSocket にアクセスできるように、それをボリュームとしてマウントする必要があります：- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock。これがデフォルトの NGINX Proxy Manager docker compose ファイルへの最終的な変更です。以下に、私の環境で動作する最終バージョンを示します：
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
network_mode: bridge
ports:
- '80:80'
- '81:81'
- '443:443'
environment:
DB_MYSQL_HOST: "172.17.0.6"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "my-super-safe-pwd"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'my-super-safe-pwd'
volumes:
- ./data/mysql:/var/lib/mysql
7. NGINX Proxy Manager で WebSocket を使用するように設定する
最後のステップ：NGINX Proxy Manager に WebSocket を使用するように指示します。私の記憶では、「WebSocket サポート」をオンにするだけでは不十分だったため、OP の NGINX location を「高度な設定」タブにコピーしました。以下のように：
「カスタムロケーション」タブでは動作しませんでした。
8. SSL を有効にするのを忘れないでください
NGINX Proxy Manager 内の SSL 設定については言及していません。それは非常に自明であるように思われるため、プロセスのどの時点で有効化しても問題ないと思うからです。したがって、まだ行っていない場合は、私の設定は以下のようになります：
9. 注意点
tl;dr：Discourse コンテナを再起動するたびに、メインの NGINX Proxy Manager コンテナも再起動する必要があります（db の再起動は不要です）。
WebSocket を通じて Discourse にアクセスしている場合、Discourse コンテナを再構築する（ベースイメージを更新するために数ヶ月に一度必要とされる）と、以前の WebSocket が削除され、新しい WebSocket が作成されることに注意してください。その結果、NGINX Proxy Manager は Discourse インスタンスとの接続を失い、502 エラーを返します。将来の NGINX Proxy Manager のアップデートで新しい WebSocket を自動的に検出できるようになるかもしれませんが、現在（2022 年 1 月）では、NGINX Proxy Manager を再起動しない限り、再構築された Discourse コンテナを見つけることはできません。
解説
上記の手順が WebSocket とポートを組み合わせている理由が気になるかもしれませんが、単純な理由は、この投稿を書いている最中に、WebSocket を使用する際、NGINX Proxy Manager と Discourse が同じ Docker ネットワーク上にいる必要はないかもしれないとふと思ったからです。そしてこれが確認された後、誰も手順を完全に書き直す気分にならなかったのです。
サポートフォーラムの最も魅力的な側面は、問題をうまく説明することが、質問を投稿することなく解決策を見つけることにつながる点です。この場合、私は他の人の質問に答えていましたが、同時に自分自身の質問に対する答えも見つけたかもしれません。
しかし、NGINX Proxy Manager を 12 秒以上見てみた限りでは、問題なく機能すると思います。以前にも議論されたことがある別の「自動 NGINX プロキシ」ツールもありますが、私の「広範な」NGINX Proxy Manager の知識に基づけば、そちらの方が優れているかもしれません。Traefik への不満が増しているため、そのツールも見てみるつもりです。
死んでしまいました。
）。要するに、すべてが順調に進みました。その後、Discourse を WebSocket で動作させるための変更を加えましたが、これも問題なく動作しました。幸運なことに、以前の Discourse 設定では自動バックアップが行われていたため、数回のクリックですべてを復元できました（Discourse を使うほど、ますます愛着が湧きます！）。