皆さん、こんにちは。
Discourse を 2 回セットアップしましたが、1 回目はコンテナ内、2 回目は VM 内にセットアップしましたが、どちらのインストールでも Discourse にアクセスできません。何が間違っているのかよくわかりません。
Discourse VM:
- コア 4
- RAM 6GB
- ストレージ 50GB
- OS: Ubuntu 22.04.3
クリーンな Post OS インストールコマンド:
apt update -y && apt upgrade -y && apt wget curl zip git docker.io -y && reboot
その後、次のガイドに従いました: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
完了後、コンテナは実行されていることがわかりますが、502 Bad Gateway が返されます。
セットアップ方法: Nginx リバースプロキシ (SSL を含む) → VM。これは機能しません。
ホストファイルに直接追加しても、ロードすらされません。
インストールの最後の数行から、docker が新しいネットワークを作成したことがわかります:
DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443
HOST マシンの IP を使用するにはどうすればよいですか？
ネットワーク内の別のネットワークは必要ありません。docker が HOST IP を使用しても構いません。この VM 上の唯一のサービスだからです。
どのような支援でも大変感謝いたします。
docker なしでインストールする公式の方法はありますか？
「いいね！」 2
pfaffman
(Jay Pfaffman)
4
コンテナはパブリックIPを持つマシン上にありますか？そのパブリックIPにはドメイン名が割り当てられていますか？
discourse-setup を実行しましたか？DNSが有効でホストが利用可能かどうかを確認する部分を通過しましたか？
証明書を取得できなくなるほど、Let’s Encrypt のレート制限を受けるまで、多数のリビルドを実行しましたか？
いいえ、このマシンにはローカルIPが割り当てられており、ファイアウォール経由でトラフィックがlocalIPにルーティングされます。これは問題ではありません。
パブリックIPにはサーバーのAレコードがあり、正しくルーティングされます。forum.somedomain.comは–\u003e正しいサーバーを指します。
はい、インストールは完了しました。コンテナが実行されているところまで、100％完了しました（3回）。
ドメイン/DNSチェックはすべてパスします。有効であると表示されます。
いいえ、SSL証明書はリバースプロキシ経由で発行されるため、レート制限されることはありません。証明書はあります。
このインストールは100％完了しています。問題は、Dockerが新しいネットワーク172.17.0.1を作成しており、これは必要ないことです。HOSTのローカルIP192.xx.xx.xxを使用したいからです。
コンテナは実行されていますが、別のネットワーク上にあります。HOST IPに到達できません。
Dockerホストは、新しいネットワークではなく、ホストサーバーのIP（192.xxx.xxx.xxx）である必要があります。おそらく機能していますが、そのネットワーク上でです。
インストールにローカルIPを使用するように指示するにはどうすればよいですか。172.17.0.1ではなく。
@pfaffman このような感じです。あなたがしたコメントからです
./discourse-setup でホストIP 192.168.1.X を使用し、インストール時にネットワークを設定するにはどうすればよいですか？
pfaffman
(Jay Pfaffman)
7
リバースプロキシでは discourse-setup を使用できません。yml ファイルを自分で編集する必要があります。同じマシンで他のサイトと一緒に Discourse を実行することに関するトピックがいくつかあります。
SSL を行うリバースプロキシを使用している場合は、ssl および let’s encrypt テンプレートを削除する必要があります。
それが問題なのです。このマシンでは他のサービスを実行していません。スタンドアロンVMです。
誤解があると思います。
./docker-setup は正常にインストールされます。アプリ用の独自のネットワーク 172.17.0.1 を作成します。
インストールまたはDockerコンテナをホストIP 192.168.1.X で使用するにはどうすればよいですか？つまり、独自のネットワークを作成するのではなく、ブリッジネットワークを使用します。
pfaffman
(Jay Pfaffman)
9
しかし、あなたはこう言いました。
リバースプロキシを使用している場合、discourse-setup は使用できません。
はい、リバースプロキシは別のサーバーにありますが、言っていることは理解できます。
アイデアがあります。ネットワークからのすべてのトラフィックをDockerコンテナのネットワークにルーティングするつもりです。
nginxリバースプロキシの背後でDiscourseを実行するためのインストールガイドはありますか？
または、自分でDiscourseをビルドする方法はありますか？
Jagster
(Jakke Lehtonen)
11
それは非常に些細なことです。Nginxがトラフィックを送信しているapp.ymlでHTTPポートを許可し、SSLを無効にします。修正する必要があるのはその2点だけです。もちろん、実際のIPを伝える必要がありますが、それはバックエンドがDiscourse、Moodle、WordPressのいずれであっても常に必要です。UFWは、バックエンドへの直接アクセスを許可する必要がないため、フロントエンドとバックエンド間のアクセスを制限しようとします。
私の記憶が正しければ、ここにApache2の設定方法に関するドキュメントがあります。Nginxも同様のことを行いますが、もちろん独自のやり方です。
それとも、今何を見落としていますか？
「いいね！」 1
最初から始めますので、単純なことを見落としているだけかもしれません。
Nginx リバースプロキシがあります。パブリック IP を実行および管理し、サービスへのルーティングを行っています。
例: クライアントが cloud.domain.com をリクエストします → Nginx リバースプロキシ (SSL を処理) → cloud.domain.com にポイントします
次に、Discourse 用の VM をセットアップし、以下を使用しました。
Ubuntu 23.04。OS インストール後のコマンド:
apt update -y \
apt upgrade -y \
apt install wget curl zip git docker.io -y
次に、Discourse のこのガイドに従いました: discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
インストールは正常に完了し、問題が発生します。
docker0 ネットワークのため、ホストから Docker コンテナにアクセスできません。172.17.0.2 に ping を送信でき、正常に動作していますが、ホストマシン 192.168.1.10:80/443 からコンテナへのトラフィックが流れません。
私が望むのは、コンテナが 80 および 443 ポートを公開しているため、コンテナがホストネットワークを使用することだけです。
最初の Nginx リバースプロキシは、外部からのトラフィックを処理し、VM に正しく渡します。そうでない場合、./discourse-setup はドメイン名を正しく認識せず、コンテナの SSL 証明書を取得できなくなります。
結論として、コンテナは 100% 動作していることはわかっています。Docker ネットワークのためにアクセスできないだけです。
情報が必要な場合はお知らせください。
merefield
(Robert)
13
もう1つのアプローチは、discourse のベースイメージを使用することです。
https://hub.docker.com/r/discourse/base
そして、たとえば docker compose を使用して独自のオーケストレーションを構築します (redis や postgres などの他のサービスが必要であることを忘れないでください)。
Jagster
(Jakke Lehtonen)
14
Nginx または Nginx+Varnish を使用して、同じ VPS 上または異なる IP の VPS 上の Discourse でそれを行うことができます。リバース プロキシとして機能する Nginx を実際にどのように使用しているのかがわかりません。例が少し難しいのは、それらが例であるのか、それとも実際にプライベート ネットワークを使用しようとしているのかを知る方法がないためです。
しかし：
もちろん、それは着信トラフィックを処理するためです。バックエンドには別のポートを使用する必要があります。
次のようなもの（これは実際には Varnish で使用されますが、原則はまったく同じで、非常に初歩的なものです）：
proxy_pass http://127.0.0.1:8080;
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 https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_pass_header Server;
理解しました。具体的に説明していただきありがとうございます :)。
このDockerネットワークが混乱しているため、何を使用すればよいかわかりません。
まったくその通りです。だからDockerにイライラしているのです lol
以下は、WANネットワークがNginxリバースプロキシから正しいホストへのトラフィックを渡し、ルーティングする方法を正確に示しています。
map $scheme $hsts_header {
https "max-age=63072000;includeSubDomains; preload";
}
server {
set $forward_scheme https;
set $server "10.10.1.38";
set $port 443;
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name forum.domainname.com;
# Let's Encrypt SSL
include conf.d/include/letsencrypt-acme-challenge.conf;
include conf.d/include/ssl-ciphers.conf;
ssl_certificate /srv/ssl/domainname.pem;
ssl_certificate_key /srv/ssl/domainname-ke.pem;
# Asset Caching
include conf.d/include/assets.conf;
# Block Exploits
include conf.d/include/block-exploits.conf;
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
# Force SSL
include conf.d/include/force-ssl.conf;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $http_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
location / {
# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;
# Proxy!
include conf.d/include/proxy.conf;
}
}
奇妙なことに、クライアントがNginxリバースプロキシマネージャーを求めていたときに、一度Dockerコンテナを設定したことがありますが、それは非常に簡単でした。
docker-compose up -d
それだけです。プライベートIP 192.168.1.3 はコンテナが公開した80/443に到達でき、発信トラフィックは192.168.1.3に正しくルーティングされました。
Jagster
(Jakke Lehtonen)
16
サンドボックス内で動作するパケットシステムなので、紛らわしいのです。基本的にそういうものです。
しかし、Dockerを理解することは、それを使うこととは別のことです（そして今、多くの開発者が泣き始めています🤣）。リバースプロキシはファイアウォール経由でIPにトラフィックを送信しており、そのIPとリスニングポートを伝える必要があります。そして、そのIP上にDiscourse、つまりDockerがあり、app.ymlで指定したポートで動作しています。Discourse自体と連携する内部Nginxが残りの処理を行います。
SSL終端処理はすでに完了しているので、Discourseは443をリッスンすべきではありません。
そして、リバースプロキシでキャッシングを使用することは基本的にできません。バックエンドであるDiscourseはウェブページではなく、JavaScriptとJSONを送信するウェブアプリケーションです。
なんとなく理解しました。
それは同意できます。泣いているとは言いませんが、Linuxに精通しているシステム管理者や開発者にとっては無駄です。LXCまたはVMを作成して分離し、Dockerに別の分離された環境を作成させるのは、冗長で無意味です。
ここが混乱している部分です。app.ymlは、Dockerネットワーク172.17.0.1/16上の172.17.0.2に80:80と443:443を公開しており、VMのIPは10.10.1.38です。
Discourse/Dockerに、10.10.1.38に来るすべてのトラフィックを172.17.0.2に渡し、すべての発信トラフィックを10.10.1.38に渡すようにするにはどうすればよいですか。この問題を解決するために必要なのはそれだけです。文字通り。
私のリバースプロキシは、WANからforum.domainname.comへのルーティングを処理します。
キャッシングは削除されました。
「いいね！」 1
Jagster
(Jakke Lehtonen)
18
それらを変更しない場合のみです。本来行うべきように、ポートは1つだけ使用してください。
80:80 および 443:443 はデフォルトであり、リバースプロキシやその他のフロントエンドとして機能するものが存在しない場合にのみ、それ自体で使用されます。
「いいね！」 1
アイデアをいただきました。
すべてのベースファイルをチェックしていましたが、解決したと思います。
とても簡単でした（笑）。再構築中なので、公式にサポートされている標準のインストール方法を使用すれば100％機能するかもしれません。
成功しました。フォーラムは正常にインストールされ、動作しています。
標準的でサポートされているインストール方法を使用しています 
「いいね！」 2
@pfaffman これはサポートされているインストールになったため、インストールに移動できます。
Jagster
(Jakke Lehtonen)
22
あります。サポート対象外としてタグ付けされているだけです 
そもそも、リバースプロキシなしでインストールを開始しなかったのは、どのような問題があったからですか？単に興味があるだけです。
