マルチサイトと複数のコンテナのそれぞれにどのような長所と短所があるか、ご存知の方はいらっしゃいますか？
現在、私は3つのDiscourseインスタンスを別々のコンテナとして運用していますが、さらに2つ、あるいは3つのフォーラムをDiscourseに移行しようと考えています。これらは同一サーバー（64GB RAM、SSD搭載）上で動作するため、どのような方法が最適か検討しています。
各インスタンスは可能な限り独立させて、個別にアップグレード、バックアップ、復元が行えるようにしたいと考えています。また、一つのインスタンスで問題が発生しても、他のインスタンスには影響が及ばないようにしたいです。
どのようなご提案がありますか？留意すべき長所や短所はありますか？
マルチサイト環境では、個別にアップグレードすることはできず、使用するプラグインを分離することもできません。これらすべてはルートマルチサイトによって定義されます。ただし、設定、テーマ、バックアップは個別に行うことができます。
また、一般的に SSL 証明書の管理を支援するために、前面にプロキシを設定する必要があります。
実は、Let’s Encrypt を使って複数のドメインの証明書を取得し、プライマリドメインへリダイレクトしない方法を見つけました。Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy
@AstonJ さん、私のハウツーを試していただくことは可能ですか？90% は動作すると確信していますが、最後にテストしたのは数週間前であり、私以外の人が手順通りに進められるかについては完全には自信がありません。
もし、すべてのサイトで同じプラグインを使用し、一括でアップグレードしたいのであれば、マルチサイト構成は非常に優れています。
ACP（管理パネル）を通じて未使用のプラグインを無効化することは可能です（おそらく、一部のフォーラムで不要なプラグインは 1 つだけだと思います）。つまり、マルチサイトを採用するメリットがあるかどうかは、特にパフォーマンスや安定性の面でどうなのかという点にかかっていますね。
以前、@Blake が「PG を独自のコンテナで実行しないのは狂気の沙汰だ」と投稿したと記憶していますが（これはマルチサイトとは異なる概念でしょうか？）、そのためこの件について検討していました。余談ですが、Blake の発言について確信は持てません。夢で見た可能性もありますしね 
当社は HAProxy を使用しており、SSL 証明書の処理を行っていますので、おそらく問題ないかと考えられます。
メリット次第ですね、Jay さん。大きな違いがなければ、これまで通り続けることにも問題ありません。セットアップと管理は比較的簡単になっていますから。しかし、マルチサイトにする場合に明確な利点があるなら、ぜひ興味があります 
もう一つの利点は、Rails と Nginx のコピーを 1 つ増やすだけで済むため、必要な追加 RAM が大幅に少なくて済むことです。ただし、あなたには十分な RAM がありますから、すでに動作している構成をそのまま使うのが、今や最善の案のように思えてきます。
こんにちは。マルチサイトのユーザーを統合して、1つのサイトに登録するだけで（Magentoのように）すべてのマルチサイトに同時に登録できるようにすることは可能ですか？または、Discourseのスーパーバリアントを使用して、フェデレーションのように機能させることはできますか？アラートが同期して機能し、サイト1のユーザーがサイト2からのアラートを受け取れるようにするにはどうすればよいですか？チャットについても同様です。
私は同じ大きな方向性を持つ4つのコミュニティを持っていますが、トピックが異なり、これらのコミュニティが互いに緊密に統合されることを望んでいます
サイトの1つをディスコースコネクト認証サーバーにし、残りのサイトすべてがそれに認証させることができます。
サーバーを1つにして、独立した3つのコミュニティを運用する必要があるのか、それとも複数のコンテナを使用する必要があるのか、あるいは別の方法があるのかを調べています。
現在、独立した3つのコミュニティがあります。そのうち2つは似ており（どちらも大学スポーツに関するものですが、2つの異なる学校向けです）、3つ目は料理とお菓子作りに関するものです。
ISPのIPアドレス制限のため、これらすべてを同じサーバーに配置したいと考えていますが、URLは別々にする必要があります。たとえば次のようになります。
foo.bar.com/team1
foo.bar.com/team2
foo.bar.com/cooking
team1.bar.com が foo.bar.com/team1 にリダイレクトされる、または個別の仮想サーバーにリダイレクトされることも問題ありません。（Apacheでそれが可能であることは知っているので、nginxでも直接または前面にプロキシサーバーを配置することで可能だと想定しています。）
理想的には、foo.bar.com 自体がこれらの独立したコミュニティへのゲートウェイとして機能し、それらが何であるか、どのようにアクセスできるかを説明できるようにしたいと考えています。各コミュニティの一部のカテゴリは一般に公開され、ウェブクローラーがアクセスできるようにして、ウェブ検索に表示されるようにしたいと考えています。
これはマルチサイト設定ですか、それともマルチコンテナ設定ですか、あるいは全く別のものですか？
Multisite で実行する際に、既知のプラグイン設計上の注意点はありますか？
私の Chatbot は Mulitsite をサポートしていないようですが（既知の問題です）、その理由を理解したいです。標準インストールでは問題なく動作しています。
具体的には、setup db task と、おそらく this job に問題があるようです。
状況についてアップデートしたいと思います。
いくつか調査した結果、コンテナ1つでマルチサイト設定が必要だと判断しました。外部のnginxサイトで設定を説明し、個別のDiscourseサイトへの誘導とトラフィックを処理します。これにより、list1のユーザーがlist2の内容を気にする必要なく、両方のサイトを読み取り専用（およびウェブクローラー向け）に公開できます。ウェブクローラーを満足させるためにrobots.txtを調整する必要があるかもしれません。
マルチサイト設定の例は参考になりましたが、Unixソケットでは動作しませんでした（ゲートウェイエラー）。そのため、別のポートに転送し、そのポートをコンテナ内の443にリダイレクトすることにしました。
app.ymlファイルでは、SSLテンプレートを有効にしましたが、letsencryptは有効にしませんでした。
テスト環境のサイトは動作するようになりました。今後は、今月後半か来月に予定している本番サイトへの移行時に発生する可能性のある問題を探しています。
証明書の問題は外部サーバー側で対応していますが、「安全でない」という問題に遭遇しました。これは、コンテナ内でhttpsを必須にすることで修正しました。cronで実行するタスクがあり、最新の証明書とキーをコンテナの/shared/sslディレクトリにコピーします（ssl.crtとssl.keyとして）。証明書が変更されたとき（おそらく7月）、コンテナ内のnginxを強制的にリロードして新しい証明書がロードされるようにする必要があるかどうかはまだわかりません。
Discourseの落とし穴が1つありました。
コンテナ内の/etc/nginx/conf.d/discourse.confファイルに、次のコード断片があります（ドメイン名は変更しています）。
if ($http_host != 'site1.my.domain') {
rewrite (.*) https://site1.my.domain$1 permanent
}
これはsite2.my.domainをsite1.my.domainにリダイレクトしていたため、コメントアウトする必要がありました。
注：コンテナを再構築すると、この編集をやり直す必要があります。これを回避する方法はありますか？
そして、ブラウザの落とし穴につながりました。Firefoxがそのリダイレクトを永続的であるとフラグ付けしたため、ブラウザのキャッシュを削除する必要がありました。（これは理解するのに非常に時間がかかりました！）
もう1つ奇妙なことがわかりました。
テスト環境のサイトでは、httpsを必須にするパラメータはどちらのサイトでもチェックされていませんでした。本番サイトでは、そのパラメータは設定ファイルにさえ存在しません。これは、2つのサイト間の違いに関連しているのではないかと推測しています。