なるほど、それは理にかなっています。そして、Mailgunを使っても問題ないと思います。
マルチサイトのセットアップを始めたときに、これらすべてをよりよく理解できるでしょう！
「いいね！」 3
@alltiagocom と同じような状況にあるため、割り込ませていただきます。メインのコミュニティのために小規模なHetznerサーバーにDiscourseをインストールしましたが、他のいくつかのFacebookグループも、一通り慣れたらDiscourseに移行することを考えていました。
「WordPressマルチサイト」には精通していますが、Discourseのマルチサイトはより手間がかかると理解しています。2つのスタンドアロンサイト（またはそれ以上）を運用するのと、マルチサイトを運用するのとでは、どちらが手間がかからないか疑問に思っていました。
これについて何か洞察はありますか？
マルチサイトの方がメンテナンスのオーバーヘッドが少なく、頭痛の種も減るでしょうが、結果は人それぞれです。
「いいね！」 1
Discourse初心者の方には、2つのサイトを運用することをお勧めします。
リバースプロキシなしでマルチサイトを運用する方法についてトピックを作成しましたが、現在は古くなっています。
変更が必要なのは、
を新しい
DISCOURSE_HOSTNAME_ALIASES: domain.com,other.domain.com
に置き換えられることだと思います。
「いいね！」 2
私の2セントですが、古いメモ、ChatGPT、Claude、DiscourseのAIボット、そしてここで共有されたいくつかのトピック（そしてプロセス全体についてメモを取り続けた後）の助けを借りて、一日中これに取り組んだ後の感想です。
リバースプロキシを追加する必要がある点に達するまで、すべてが順調に進んでいるように見えました。正常に動作していた最初のインスタンスが動作しなくなりました。DiscourseのAIボットにもういくつか質問しましたが、初日だったため、動作しなくなりました。それはボットの新規ユーザーに対する制限です。非常に協力的だったClaudeも、無料版を使用しているため停止しました。ChatGPTはすべての中で最も信頼性が低いため、そこからのすべての返信は、常に非常に懐疑的に受け止められます…
それから、私は再びフォーラムに来て、@pfaffmanが書いたものを含む、それに関するいくつかのトピックを読み始めました。それが最後の一線でした。私には、何を尋ねるべきかさえ理解できないほど、複雑すぎ、技術用語が多すぎました。
要約：最初のインスタンスは動作していたので、元に戻します（app.ymlファイルを変更前の状態に編集しています。入力しながら再構築しています）。
正直なところ、この複雑さにもかかわらず、最初の大きな障害を乗り越えればより多くのコミュニティを追加できるようになるとしても、追加のコミュニティのために月額4ドルを節約することが世界の終わりになるとは思いません。Hetznerでサーバーを設定し、次にDiscourseをインストールする方法はすでに知っているので、今は2つのコミュニティに留まり、両方で8ドルを支払い、先に進みます。数か月前にDigital Oceanで1つのドロッパーに12ドルを支払っていたことを考えると、望むなら3つのコミュニティのために同じ金額を支払う努力をすることができます。
それにもかかわらず、私は常にこれらの冒険を興味深いと感じています。なぜなら、その過程で何か新しいことを学び、最終的には、「できるかどうかわからないからやらない」と言うのではなく、「なぜやりたくないのか」を言えるからです。
ここで時間を割いて助けてくださった皆さんに感謝します。そして、このトピックが、私がやろうとしていたことを達成したい他の人々の助けになることを願っています。
以上です！
「いいね！」 8
だからこそ、私はあなたの戦略を再考する必要があると言ったのです。あなたが達成しようとしていたことは、以前にも達成されたことがあるため不可能ではありませんでしたが、それを正しく行うには、言説（ディスコース）についてかなりの理解が必要です。
ディスコースの仕組みについてもっと学びたいのであれば、自由な時間に実験を続けることをお勧めします。ここにいるほとんどの人はそうやって学びました。
「いいね！」 9
（ほとんど）理解するのに、認めたくないほど長い時間がかかりました！
「いいね！」 6
6件の投稿が新しいトピックに分割されました: 複数のアプリコンテナを単一のDiscourseサイトに
サポートされているDiscourseマルチサイトインストールをコマンドごとの実行手順書として文書化しています。
以前、「1台のサーバー上に複数のスタンドアロンインストール」というアプローチを試しましたが、その構成はサポートされていません。この記事では、明示的な手順を好む人向けに線形形式で書き直された、サポートされているマルチサイトアーキテクチャのみに焦点を当てます。
これが何か（サポートされている構成）
- 1つのDiscourseアプリコンテナ (
app) multisite.ymlを介して有効化されたマルチサイト- 共有Postgres + Redis（Discourseによって管理）
- Unixソケット経由の接続（Dockerネットワークは不要）
- 内部的に別々のサイトにルーティングされる複数のホスト名
これが何か（サポートされていない構成）
- HAProxyの背後にある複数の独立したDiscourseコンテナ
- アプリノードをドレインすることによるローリングリビルド
- サイトごとのSMTP認証情報（SMTPは共有）
運用上の注意点（期待値を正しく設定するために）
リビルド / ダウンタイム
マルチサイトではアプリコンテナが1つしかないため、./launcher rebuild appは唯一のノードを再起動します。これは、すべてのサイトで短いダウンタイムが発生することを意味します。
証明書 / ホスト検証
Let’s Encryptとホスト検証が確実に機能するように、すべてのホスト名をDISCOURSE_HOSTNAME_ALIASESに追加してください。
バックアップ / 後続の移行
各サイトは/admin/backupsで独自のバックアップを作成します。サイトのバックアップを後でスタンドアロンインストールにリストアすることが、通常の移行パスです。
完全なサポートされているマルチサイト実行手順書（コマンドごと）
0) ホストの前提条件
| ステップ | コマンド |
|---|---|
| システムの更新 | apt-get update && apt-get upgrade -y |
| 依存関係のインストール | apt-get install -y git curl sudo |
1) Discourse Dockerのインストール
| ステップ | コマンド |
|---|---|
| リポジトリのクローン | git clone https://github.com/discourse/discourse_docker.git /var/discourse |
| ディレクトリへ移動 | cd /var/discourse |
2) 最初のサイトのインストール（まずはシングルサイトとして）
| ステップ | コマンド |
|---|---|
| セットアップの実行 | ./discourse-setup |
これにより、/var/discourse/containers/app.ymlが作成され、最初のホスト名（例：forum1.example.com）が起動します。
3) マルチサイトの有効化
| ステップ | コマンド |
|---|---|
| 設定ディレクトリの作成 | mkdir -p /var/discourse/config |
| multisiteファイルの編集 | nano /var/discourse/config/multisite.yml |
multisite.ymlの例：
forum1:
host_names:
- forum1.example.com
forum2:
host_names:
- forum2.example.com
4) app.ymlを編集してマルチサイトとホスト名エイリアスを有効化
| ステップ | コマンド |
|---|---|
| app.ymlの編集 | nano /var/discourse/containers/app.yml |
以下を追加します。
DISCOURSE_MULTISITE: trueDISCOURSE_HOSTNAME_ALIASES: forum1.example.com,forum2.example.com
5) リビルド
| ステップ | コマンド |
|---|---|
| リビルド | ./launcher rebuild app |
6) マルチサイトDBの移行
| ステップ | コマンド |
|---|---|
| コンテナに入る | ./launcher enter app |
| マルチサイトマイグレーションの実行 | rails multisite:migrate |
| 終了 | exit |
| ステップ | コマンド |
|---|---|
| 再起動 | ./launcher restart app |
7) 確認
以下にアクセスします。
https://forum1.example.comhttps://forum2.example.com
各サイトには、独自の管理者、ユーザー、アップロード、およびバックアップがあります。
8) バックアップ / 後続の移行
サイトごとの管理者：
/admin/backups
後でサイトを独自のサーバーに分割したい場合は、そのバックアップをスタンドアロンインストールにリストアします。
上記の内容が現在のベストプラクティスと矛盾する場合は、この実行手順書を更新させていただきます。目的は、試行錯誤を減らすための線形的なサポート対象マルチサイトチェックリストを提供することです。
「いいね！」 2
すごい！マルチサイトの不明瞭な世界で明確にするために必要としていたガイドです！実際に非常に実行可能で、私が想像していたよりもずっと簡単に見えます。
単一のコンテナでしか実行できないのは少し残念ですが、それがなぜ必要なのかは直感的に理解できます。その結果、いくつかの小規模で静かなセルフホスト型フォーラムに最適でしょう。
あなたの返信は、独自の（Wiki）トピックに値し、適切に目印を付けるべきです。
「いいね！」 2
私向けかもしれない😍
「いいね！」 1
これは、Discourseがすでに「モノサイト」として稼働しており、それをマルチサイトに変換したい場合にも適用可能でしょうか？
ご尽力に大変感謝いたします！
「いいね！」 1
ありがとうございます！これは現在のサポートされているマルチサイトのプラクティスと一致しています。ここにあるものは、Discourseマルチサイトの現在の動作方法と競合するものではありません。
はい、既存のモノサイトインストールをマルチサイトに変換する場合も同じ手順が適用されます。モノサイトは、単一のデフォルトサイトを持つマルチサイトと実質的に同じです。DISCOURSE_MULTISITEを有効にし、multisite.yml（既存のサイトを含む）を追加し、一度リビルドし、その場でrails multisite:migrateを実行できます。
もしここにあって、もはやベストプラクティスを反映していないものがあれば、ランブックを更新することを非常に歓迎します。目標は、試行錯誤を避けるための線形的でサポートされたチェックリストです。
「いいね！」 3