リバースプロキシの後ろで動作するようにするには、手動で変更を加える必要があります。それをどのように行うかを知っていて、app.yml を作成した後にそれを行うと仮定します。
これは機能するかもしれません：
./launcher destroy app
mv containers/app.yml first_app.yml
./launcher rebuild first_app
./discourse-setup
その後、リバースプロキシの後ろに配置するように app.yml を編集します。
UnixソケットでDiscourseをリッスンしているときに混合コンテンツの警告が表示されます。新規インストールです。
私の記憶が正しければ、それはキャッシュされたロゴです（force https パラメータを有効にしていると仮定します）。ブラウザの開発者ツール/ネットワークタブで確認していただけますか？
これを解決済みとしてマークしてください。HTTPS設定を強制し、（また、サブディレクトリパスを追加するためにrake search replaceを実行する必要がありました）。メインはApacheと他の多くのサイトを稼働させています。このexample.orgの例では、WordPressがインストールされており、Apacheリバースプロキシを/forumsで実行し、DiscourseがWebsocketでリッスンしています。
@rikingの方法の代わりに、一番上にありますか？
「ダブルNGINX」の方法のウォークスルーへのリンクはありますか？
残念ながら、NGINXについては何も知りませんが、@rikingのウォークスルーは十分に簡単に見えますが、より良い方法がある場合は、その詳細をいただけると幸いです。
こんにちは！
GitリポジトリからファイルをクローンしてDiscourseをインストールし、ご提案いただいた手順を実行しました。ただし、SSLプロトコルはNginxプロキシマネージャーを使用して処理しました（app.ymlのポート443の公開部分をコメントアウトしました）。
Portainer v2.11.0を使用しており、Discourseコンテナが正常に作成されていることは確認できますが、ウェブサイトを実行できず、502 Bad Gatewayエラーが発生します。
エラーを修正する方法について、何かアイデアはありますか？
SSLおよびLet’s Encrypt証明書も削除しましたか？
外部プロキシを、コンテナ内のNginxプロキシではなく、Discourseに直接接続するように構成するのは合理的ではありませんか（すべてが二重プロキシされることになります）？それとも、内部Nginxプロキシは、外部プロキシでは処理できない重要なタスクを実行していますか？
こんにちは、nginx.sock ファイルがない場合はどうすればよいですか？
❯ ls /var/discourse/shared/standalone/
backups postgres_backup postgres_run state uploads
log postgres_data redis_data tmp
テンプレートを含めましたか？
Dietpi OS の Raspberry Pi 4 に Discourse をインストールしようとしており、Nextcloud のような nginx で動作するアプリもあります。トンネルとして Cloudflared サービスを使用しようとしていますが、Discourse のインストールが完了した後、トンネルを作成するための Discourse サービスポートが見つかりません。localhost に接続すると、Nginx の開始ページが表示されます。Discourse サイトにはどこからアクセスできますか？
補足: Cloudflared サービスを使用したいので、certbot は設定していません。
こんにちは。GitHub - nginx-proxy/nginx-proxy: Automated nginx proxy for Docker containers using docker-gen の背後で Discourse をインストールしようとしていますが、方法がわかりません。
Discourse のソケットを nginx-proxy コンテナに公開し、仮想ホストごとの場所設定 を追加してみましたが、うまくいきませんでした。
他のサービスは正常にプロキシの背後でセットアップできましたが、Discourse だけがうまくいきません。何かアドバイスはありますか？
好奇心から、以下の2つのアプローチの長所と短所を教えていただけますか？
何らかの理由で、NGINXを起動してページを提供し、NGINXなしでDiscourseを起動しても問題ありません。しかし、最初のアプローチを使用すると、常に次のエラーが発生します。
/var/discourse/shared/web-only/log/rails/production.log
Job exception: Error connecting to Redis on data:6379 (Redis::TimeoutError)
/var/discourse/shared/web-only/log/rails/unicorn.stderr.log
Failed to report error: Error connecting to Redis on data:6379 (Redis::TimeoutError) 3 heartbeat: Error connecting to Redis on data:6379
そして、2番目のアプローチを使用すると、./launcher rebuild <app>を実行してもビルドすらできません。次のようなエラーが発生します。
I, [2022-09-12T08:54:16.483648 #1] INFO -- : cd /var/www/discourse & git fetch --depth 1 origin tests-passed
fatal: unable to access 'https://github.com/discourse/discourse.git/': Could not resolve host: github.com
I, [2022-09-12T08:54:56.561225 #1] INFO -- :
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & git fetch --depth 1 origin tests-passed failed with return #<Process::Status: pid 35 exit 128>
ここにコードを入力または貼り付けます
web_only コンテナを使用していますが、data コンテナは実行していませんか？
いいえ、結構です。
app.yml を変更して、discourse コンテナがプロキシと同じ名前のネットワークで実行されるようにしました。
その後、nginx-proxy のドキュメントで推奨されている _location 設定を、このスレッドの値で追加し、discourse ソケットを (簡単のためホストと同じパスで) 利用可能にしました。
しかし、どこかに権限の問題があるようです。正確にはわかりませんが、設定は nginx によって認識され、https リクエストを行うとこのエラーが発生します。
[crit] 230#230: *21 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: <ip>, server: <domain>, request: "GET / HTTP/1.1", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
コンテナ内:
# ls -lah /var/discourse/shared/standalone/
total 12K
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 .
drwxr-xr-x 3 root root 4.0K Sep 12 10:51 ..
drwxr-xr-x 2 root root 4.0K Sep 12 09:19 nginx.http.sock
編集: これは sudo あり/なしで開始されたコンテナによる問題でした。
しかし、今はこれが発生しています:
[error] 219#219: *94 no live upstreams while connecting to upstream, client: <client-ip>, server: <domain>, request: "HEAD / HTTP/2.0", upstream: "http://<domain>/", host: "<domain>", referrer: "http://<domain>"
そして 502 Bad Gateway エラーが発生します。
実際には両方です。docker ps を使用すると、両方が実行されているのがわかります。文字通り唯一の違いは、expose セクションを有効にするか無効にするかだけですが、今考えてみると、expose: の行もコメントアウトする必要があるのか、それともその中のポートのリストだけなのか疑問に思っています。
投稿が重複してしまい申し訳ありません。以前、別の無関係な問題で混乱しており、設定のエラーによりソケットはもう使用されていませんでした。
現在の状況は以下の通りです。
[crit] 274#274: *7 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (13: Permission denied) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
一時的な回避策として chmod 777 shared/standalone/nginx.http.sock を実行したところ、以下のエラーが発生しました。
[error] 203#203: *1 connect() to unix:/var/discourse/shared/standalone/nginx.http.sock failed (111: Connection refused) while connecting to upstream, client: 192.168.160.1, server: <domain>, request: "GET / HTTP/2.0", upstream: "http://unix:/var/discourse/shared/standalone/nginx.http.sock:/", host: "<domain>"
明らかに何か間違っていますが、何が間違っているのか分かりません。NPMではなく nginx-proxy を使用していることに注意してください。これは少し異なり、特に VIRTUAL_HOST を定義する Docker コンテナを自動的に検出して設定を生成します。そのため、listen ディレクティブを含む sites-available ファイルには触らず、Discourse に関連する location / { ... } 部分のみを追加しました。
Discourse コンテナが Restarting (100) 7 seconds ago というステータスで再起動ループに入っていることに気づきました。これは、ソケットを削除できないというエラーが発生するためです。実際、それは実際のソケットではなくディレクトリでした。nginx-proxy コンテナに公開するためにボリュームのマウントを誤って操作したためだと思います。
ディレクトリを削除し、Discourse を再起動したところ、ソケットになりました。しかし、それを nginx-proxy にボリュームとして公開できません。
Error response from daemon: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting “/var/discourse/shared/standalone/nginx.http.sock” to rootfs at “/var/discourse/shared/standalone/nginx.http.sock”: mount /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock (via /proc/self/fd/6), flags: 0x5000: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
ソケットを同じパスに保持するのではなく、/tmp/nginx.http.sock にマウントする必要があったことが判明しました。ようやくできたようです！
/var/discourse/containers/web_only.yml でポートを次のように公開しても機能しなかった理由を突き止めました。
expose:
# - "443:443"
# - "80:80"
- "8080:80" # https
Solve Nginx 13: Permission denied) while connecting to upstream - Programmer All によると、SELinux が原因であり、SELinux を Permissive モードに設定するか、次のコマンドを実行して NGINX が Discourse にアクセスできるようにする必要がありました。
setsebool -P httpd_can_network_connect 1
興味深いのは、NGINX の設定がルートパスに設定されている場合は正常に機能しますが、ルート以外のパスに設定されている場合は機能しないことです。
NGINX が / を Discourse に転送するように設定 (機能する)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
NGINX が /discussions/ を Discourse に転送するように設定 (機能しない)
# Proxy requests to 443/discussions to Discourse listening on 127.0.0.1:8080
location /discussions/ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $http_host;
proxy_http_version 1.1;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
}
この場合、次のようになっています… NGINX がルート以外のパス /discussions/ を Discourse Docker に正常に転送したとしても、Discourse 自体はページをルートパス / のアセットを期待してロードしているようです。Discourse はルートパスでのみ実行する必要があるという要件ですか？ @pfaffman これまでにこのようなことを見ましたか？
/var/log/nginx/example.com.error.log
2022/10/01 09:33:23 [error] 1954781#1954781: *1 open() "/etc/nginx/html/images/discourse-logo-sketch.png" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /images/discourse-logo-sketch.png HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/discussions/"
2022/10/01 09:33:25 [error] 1954781#1954781: *1 open() "/etc/nginx/html/service-worker.js" failed (2: No such file or directory), client: 219.78.157.149, server: uat.example.com, request: "GET /service-worker.js HTTP/1.1", host: "uat.example.com", referrer: "https://uat.example.com/service-worker.js"
