マルチサイト対複数のコンテナ

インストール
1

Does anyone know the pros and cons of multisite vs multiple containers?

I currently have three Discourse instances as separate containers, and am thinking about converting two, maybe three more forums to Discourse - they’ll be on the same server (64GB RAM, running SSDs) so I’m wondering what might be the best way forward.

I’d prefer them to be as independent as possible, so each can be upgraded individually, backed up and restored individually, and issues with one should not affect another.

What do you suggest? Any pros and cons to look out for?

2

You won’t be able to upgrade individually with multisite, nor will you be able to segment plugins used. All of that is defined by the root multisite. Settings, themes, and backups can all happen separately, though.

Generally you’ll need a proxy in front to help with SSL certs, too.

「いいね！」 3
3

Actually, I’ve worked out a way to get let’s encrypt to get certs for multiple domains and not redirect to the primary domain. Setup Multisite Configuration with Let's Encrypt and no Reverse Proxy

@AstonJ, would you be interested in testing my howto? I’m 90% sure that it works, but it was some weeks ago that I last tested and I’m not entirely sure that the instructions “work” for someone who’s not me.

If you want all the sites to have the same plugins and be upgraded all at the same time, multisite is great.

「いいね！」 3
4

I could just switch off any unused plugins via the ACP (and I think there’s only one that one of the forums won’t need) so I guess it depends on are there any benefits to doing multisite? Specifically, performance and/or stability?

I think I read @Blake once post that it’s insane not to run PG in it’s own container (is that different to multisite?) hence why I’ve been thinking about doing this. Btw don’t quote me on what Blake said I could have well dreamt it :rofl:

I use HAProxy which deals with our SSL certs so I ‘think’ that may be ok.

I think it will depend on the benefits Jay - if there’s not much difference then I don’t mind carrying on as I have been as it’s become relatively easy to set-up and manage, but if there are some big advantages to going multisite I would definitely be interested :sunglasses:

5

The other advantage is that you’re running just one more copy of rails and nginx, so the additional RAM required is much less. You’ve got lots of RAM, though, so going with what works already is starting to sound like the best idea.

「いいね！」 2
6

こんにちは。マルチサイトのユーザーを統合して、1つのサイトに登録するだけで（Magentoのように）すべてのマルチサイトに同時に登録できるようにすることは可能ですか？または、Discourseのスーパーバリアントを使用して、フェデレーションのように機能させることはできますか？アラートが同期して機能し、サイト1のユーザーがサイト2からのアラートを受け取れるようにするにはどうすればよいですか？チャットについても同様です。
私は同じ大きな方向性を持つ4つのコミュニティを持っていますが、トピックが異なり、これらのコミュニティが互いに緊密に統合されることを望んでいます

7

サイトの1つをディスコースコネクト認証サーバーにし、残りのサイトすべてがそれに認証させることができます。

「いいね！」 2
8

サーバーを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 自体がこれらの独立したコミュニティへのゲートウェイとして機能し、それらが何であるか、どのようにアクセスできるかを説明できるようにしたいと考えています。各コミュニティの一部のカテゴリは一般に公開され、ウェブクローラーがアクセスできるようにして、ウェブ検索に表示されるようにしたいと考えています。

これはマルチサイト設定ですか、それともマルチコンテナ設定ですか、あるいは全く別のものですか？

9

Multisite で実行する際に、既知のプラグイン設計上の注意点はありますか？

私の Chatbot は Mulitsite をサポートしていないようですが（既知の問題です）、その理由を理解したいです。標準インストールでは問題なく動作しています。

具体的には、setup db task と、おそらく this job に問題があるようです。

「いいね！」 1
10

状況についてアップデートしたいと思います。

いくつか調査した結果、コンテナ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つのサイト間の違いに関連しているのではないかと推測しています。