DigitalOceanなどよりも優れているので、はい、良いことです。
大丈夫でしたが、制約についても指摘しました。サイトのトラフィックとアクティビティは非常に低かったため、これらのサイトでかなりのアクティビティを期待する場合は、より多くのリソースが必要です。アクティビティが増えるにつれて、Discourseのリソース使用率は増加します。
これは、あるサイトを他のサイトから分離する必要があるかどうかによります。商用のDiscourseホスティングは、通常、請求システムなどに対応するために特別な処理が施された大規模なマルチサイトクラスターです。
ええと、高度な設定を行わない限り、すべてのサイトが親サイトの認証情報を共有します。つまり、高度な設定を行わない限り、親サイトがnoreply@example.comとして設定されている場合、子サイトでも使用されます。サイトごとに固有のメールアドレスが必要な場合は、追加の設定が必要になります。
「問題」をどのように分類するかによります。
マルチサイトでの単一の app.yml は可能ですが、マルチサイトの場合は 2 コンテナインストール（Web とデータを分離）に移行することを推奨します。
いくつかの課題を乗り越え、yml ファイル内のパスを変更してから起動する必要があります。基本的に、/var/discourse-a が独自の構成を持ち、/var/discourse-b が独自の構成を持つようなものです。
これらはかなり技術的に関わる概念であることに注意してください。マルチサイトをホストするには、ディスコースとその内部動作に関する経験が本当に必要です。不安を感じる場合は、ディスコースのマネージドホスティングを検討するか、専門家にセットアップしてもらうことを検討してください。これにより、時間の経過とともに頭痛が大幅に軽減されます。予算がある場合は、Marketplace に投稿することを検討してください。
はい、だからこそ、時間の経過とともに、より多くのリソースを持つ上位のプランにいつでもアップグレードできると言っていたのです。その…プラン…に長く留まるつもりはまったくありませんでした。ただ、水面を試すときに不必要な費用を避けたいだけなんです。わかりますか？
サーバーリソース以外に、それらを分離したいと思う理由をいくつか挙げてもらえますか？現時点では、それらを別々のサーバーに置く良い理由が見当たりませんが、まだ知らないことについていくつかの異なる視点を学ぶことはいつでも歓迎です。
それは非常に興味深い点ですね。それは知りませんでした。ですから、実際に既に行われており、機能しているもののようですね。知れてよかったです。
親サイトとはどういう意味ですか？各インストールは独立しているのではないでしょうか？どちらが親と見なされるのでしょうか？
少し混乱しています。app.yamlファイルを見ると、Brevoメールと認証情報専用の部分がありますね。コミュニティごとに個別のapp.yamlファイルを持つ方法も取れると言っていましたよね。そうすると、各コミュニティに独自のBrevo認証情報（通知メールを含む）があるということになりませんか？
適切にバックアップできなくなるようなこと、または通知メールが正しく送信されないようなことです。繰り返しますが、私は専門家ではなく、Discourseを使い始めたばかりなので、他の人が問題と見なすかもしれないが、私にはまだ見えていないこともあります。
はい、私もそう考えていました。共有されるのはサーバー自体だけで、他はすべて別々のインストールとして機能するはずなので、上記のメールに関する質問が出てきたのです。
私にとって最も困難なステップは、数か月前にDiscourseのインストールに深く飛び込んだことだったと思います。それについてはまったく知識がありませんでした。「docker」が何を意味するのかさえ知りませんでした。現時点では、セルフホスティングに関してはまだ「基本的なDiscourseユーザー」だと考えていますが、より明確な視点を持っています。そして、このコミュニティとChatGPT/Claudeの助けを借りて、もう少し学び、物事がどのように機能し、インストールされるかについてメモを取ることができました。課題は構いませんし、正直なところ、これは単にソフトウェアをインストールしているだけです。核爆弾を作っているわけではありません 
何か問題が発生したら、すべて削除して、サーバーごとに単一のインストールに戻せばいいだけです。すべてOKです 
前述したように、自分のコミュニティはすでにインストールされているので、最も難しい部分はすでに終わっていると思います。指示に従い、質問をすることが得意なので、試しながら、いつでも一時停止して調査したり、メモを取ったりすることができます。
今の私の目標は、その仕組み、長所と短所、何が可能で何が不可能かといった仕組みを理解することにあります。そうすれば、後で後悔することになるような、物事を修正するのに時間をかけすぎるような、良い決断ができるようになるからです。
ですから、皆さんが今日共有してくださっているこれらの情報は非常に貴重です。考えるべき良いアイデアを与えてくれます。特に、Discourseチームが提供する管理ホスティングがマルチサイトであると述べたことは、これが可能であることを私に実感させてくれました。もう少し手順が必要かもしれませんが、すべて実行可能です。
フィードバックに本当に感謝しています 
まず、単一のマルチサイトにするか、単一のサーバーで複数のスタンドアロンサイトをホストするかを決める必要があります。どちらか一方を決定するまで、上記で尋ねられたことへの回答は保留します。理解すべきことがたくさんあります。単に仮想マシンにDiscourseをインストールしたからといって、自動的にマルチサイトの煩雑さの対象になるわけではありません。例えば、私自身がマルチサイトのインストール体験を完璧にするのに3年かかりました。確かに、ドキュメントの多くは明確ではなく、正しく行うために多くのことをFTFO（Find The F***ing Out / 自分で調べる）する必要がありました。そして、私は2016年から2017年頃からDiscourseを使用しており（現時点で約9〜10年）、その経験があります。
ですから、一歩引いて、何を達成しようとしているのかを再考してください。そうすれば、それに集中できます。
繰り返しますが、Discourseのインストールが最大の障害ではないことに留意してください。学ぶべきことはまだたくさんあり、Discourseの使用と展開を9年間行っても、私は毎日新しいことを学んでいると考えています。
それが私の目標でした。私が構築しているものにとって、単一のマルチサイトにする利点はないと思います。私の目標は、独立したインストールを使用して1台のサーバーを利用することでコストを節約することだけです。
複雑になることについても、あなたが言いたいことは理解しています。だからこそ、インストールはできたものの、いくつかの概念を理解できるようになりつつある今でも、インストールに関しては自分を基本的なユーザーだと考えていると言ったのです。
35年近く音楽を作ってきましたが、毎日新しいことを学んでいるので、それはそれで良いことです。毎日学ぶのは得意ですし、そうでないことを期待することもありません だからこそ、私はこのコミュニティにいるのです。皆さんと一緒に新しいことを学ぶために。
もし、同じサーバー上で、コードやコンテナを共有せずに複数のDiscourseサイトを持ちたいだけであれば、以下を試すことができます。
app.ymlを注意深く読み、mountsセクションを理解してください。各サイトに対して、異なる予測可能なマウントが必要になります。最低限、これらのディレクトリを手動で編集する必要があります。
私がこれを実行した唯一の時（そして、最も非人間工学的な方法だったと思いますが）、私は2つの異なるディレクトリにDiscourseコードをクローンしました。これは必要ないかもしれませんが、試していないのでわかりません。
各ディレクトリで、接続チェックと再構築をスキップするためのいくつかのフラグを使用して./discourse-setupを実行しました。これにより、ベースラインのapp.ymlファイルができました。次のステップは、両方のファイルを手動で編集することでした。マウントを変更し、ポートを公開するセクションをコメントアウトし、外部のnginxにSSLと内部フォワーディングを処理させるためにweb.socketedテンプレートを追加しました。
その後は、各ディレクトリで./launcher rebuild appを実行するだけでした。
正直なところ、このセットアップにはあまり乗り気ではなかったので、数ヶ月いじった後、諦めました。しかし、あなたがやろうとしていることは確かに可能であり、自分で解決する必要があることを示しています。
また、すべてのサイトがリソースを使用する公平な機会を得られるように、ワーカーの数を減らすことも検討するかもしれません。しかし、それは最初の基礎が築かれたときの思考実験です。
詳細な情報ありがとうございます！
まだ最適なオプションを検討中で、たとえこのオプションを使うことになったとしても、まだいくつかのことを把握する必要があります。
これのことですか？「mount」という単語で検索しても何も出てこなかったので、ボリュームに関連するものだと推測したのですが？
もしそうなら、そこに次のような異なるパスを作成するのですか？
var/discourse/shared/website1
var/discourse/shared/website2
など？
つまり、一方のパス（例：var/discourse/shared/website1）で通常のインストールを実行し、そのファイルをもう一方のパス（var/discourse/shared/website2）にコピーしたということですか？
もしそうなら、なぜ ./discourse-setup を実行するのですか？ファイルを上書きしませんか？
代わりに、両方のパスで通常のインストールを実行する方が良いのではないでしょうか？2つの完全に独立したインストールのように？特に「フラグ」などについて言及されているので、私のような人間にとっては、心配しなければならないことが増えるだけであり、通常のインストールを行い、その後各パスの app.yaml ファイルを編集する方が良いかもしれません。
編集：気にしないでください。少し調べたところ、「クローン」がこの文脈で何を意味するのか理解できました。リポジトリのファイルをクローンしたのですね。ある「パス」にすべてをインストールしてから、そのファイルを別の「パス」にコピーしたのかと思っていました。
すでにDiscourseのインスタンスを稼働させていますか？あなたはしばらくこのフォーラムを利用していますね。すでにインスタンスが稼働しているサーバー上に2つ目のインスタンスをセットアップしようとしていますか？
学ぶための最良の方法は試してみることです。安価なVPSをセットアップして試してみてください。もしインスタンスをまだ実行していないのであれば、通常のセルフホストされたサポート付きインストールを実行して、操作に慣れてください。訪問者は実質的にゼロでしょうし、何かを保存する必要性もないでしょう。インストールを破棄して、習得できるまで何度も試すことができます。もし2つ、あるいは3つのインスタンスを単一のVPS上で実行し、それらがすべて（実質的に）ゼロトラフィックであるなら、最も安価なVPSでもおそらく動作するでしょう。
もし成功したら、私たち皆が学べるようにチュートリアルを投稿してください！
はい、実行しています。追加のインスタンスをインストールしたいと考えています。
このインストールはまだ新しく、ユーザーがサインアップしていないため、その点については問題ありません。まずバックアップを取り、このサーバーですべてを試します。まだ実際のリスクはありません。
必ずそうします。他の人の助けになれば幸いです。
@itsbhanusharma 私は、現在のインスタンスのパスを「discourse」からウェブサイト名（例：「website-name」）に変更したいと考えていたため、ChatGPTとClaudeの両方にいくつかの質問をしていました。どちらもいくつかの良い点を指摘しました。その一つが、各インストールに2GBのRAMが必要な場合、合計5つインストールすると、10GBが必要になるのではないかということです。
その場合、このプランの方が良いかもしれません。
CX43Intel ® / AMD
8 VCPU
16 GB RAM
160 GB NVMe SSD
20 TB Traffic incl.
€ 9.49 / month
5つのインスタンスに対して、まだ非常に良い価格です（$5 x 5 = $25ではなく）。
各インスタンスに2GBが必要という点について、どうお考えですか？このシナリオでは正確でしょうか？共有したこのプランは適切だと思いますか？
やめてください！
顧客がDiscourseサイトに害をもたらす事例が複数あります。彼らは盲目的にChatGPTのアドバイスに従ったためです。
これはもう少し複雑で、2+2のように単純に計算できるものではありません。そして、これがマルチサイト方式の方が良いアイデアである主な理由です。
もう一度言いますが、やめて、休憩を取り、少し立ち止まって、自分のニーズを再考することをお勧めします。ここMetaには良いリソースがありますし、私が信頼できる唯一のAIボットはDiscourseのアドバイスについては https://ask.discourse.org です。
私も同意しますが、ボットが提供する情報源を読んで情報を確認してください。そうすれば、ボットがリンクを捏造していないことも確認できます（起こり得ることです！）。
それは少し極端ですね… 誰もチャットGPTのアドバイスに盲目的に従っているわけではありません（少なくとも私はそうではありません）。だからこそ、ここで皆さんとこの会話をしているのですから。
私はそれらのツールをツールとして使っています。それらは私が他の視点を見ることができるような事柄を提示してくれます。その後、私はオンラインで調査したり、ここでコミュニティに質問したりします。その過程で、Discourseに厳密には関係のない他の概念も示してくれます。これも良いことです。ツールはそれを使う人と同じくらい優れているだけです。
そして、ChatGPTやClaudeからのヒントで多くのことを成し遂げてきました。彼らの言うことすべてを却下することはできません… 盲目的に 
これについてもう少し詳しく教えていただけますか？もしChatGPT / Claudeの情報が不正確なら、私だけでなく、将来これを読むかもしれない他の人たちのためにも教えていただけるとありがたいです。
私のケースでは、いくつかの理由からそうではありません（そして、何か見落としていない限り、それらは以下の通りです）：
繰り返しますが、マルチサイトの動作に関する私の見解が間違っているのかもしれませんが、私が理解している限りでは、私には適していないようです。
現時点での私のニーズは次のとおりです：
このツールについては知りませんでしたので、共有していただきありがとうございます。ブックマークしました。
ただし、Discourse AIボットがその主題に関する多くのコンテンツを持っているため、より知識が豊富であるとしても、ChatGPTやClaudeの言うことすべてを盲目的に（すみません、もう一度やりました（笑））無視すべきではないと言わざるを得ません。私はChatGPTやClaudeも使っています。なぜなら、時には特定のことがDiscourseにのみ関連しているわけではなく、他のことについてももう少し学びたいからです。
いずれにせよ、あなたのフィードバックと時間に感謝します。すでに大いに役立ちました。
私が理解した限りでは、あなたはセットアップについて深く考えすぎています。
根本的に、あなたは次々と多くのDiscourse（ひいては他のソフトウェアでも）インスタンスを立ち上げて、思いついた1000個の素晴らしい新しいコミュニティのアイデアをすべて一度に追求すべきではありません。
コミュニティ構築は反復的なプロセスであり、集中力が必要です。一度に複数のコミュニティに焦点を分散させると、手に負えないほどの作業を抱え込むことになります。
私の提案はあくまで考察のためのものであり、前にも述べたように、私がこれらの実験を行ったとき、それらは単に「できるからやっている」友人たちの集まりでした。
これらが一般的ではないのには理由（一つか二つ）があります。これらは、後々多くの頭痛と寝不足を引き起こすことになるかなりのメンテナンスと管理のオーバーヘッドを伴います。警告しておきます。
あなたの目標を考えると、私はこの声明で話を締めくくりたいと思います。あなたが達成しようとしていることは不可能ではありませんが、今日が可能なことすべてを達成する日ではありません。手元にあるものに集中し、最初のコミュニティを構築してください。残りのことは、時が来たらついてきます。
実験による学習という点では、コスト削減が主な目標であれば、マルチサイトが、それがもたらすすべての妥協点とともに、進むべき道です。
フィードバックありがとうございます。
おっしゃることは理解できます。正直なところ、私が関わっているすべてのことについて必要なコミュニティをすべて構築するとしたら、4〜5ではなく、15くらいになるでしょう。
現在、本当に重要で構築すべきと思われる3つに絞り込むことができました。現時点では、その3つすべてが、ユーザーが私が持っている、または構築中の製品やサービスに関する経験を話し合う場所を提供するために、独自のスペースを必要としています。
前述したように、すべてがお互いに依存し合うマルチサイトは私にはしっくりこず、正直なところ、あなたが言及した頭痛や寝不足は、その場合（少なくとも私自身の経験や、物事が互いに依存していた他の分野での経験からすると）マルチサイト構成の方が起こりやすいでしょう。どういうわけか、私の直感が「やるな」と言っており、それに従っています。間違っているかもしれませんが、いずれ証明されるでしょうが、まずは直感を信じます。
いずれにせよ、お時間をいただき、ご協力いただきありがとうございました。感謝します
それでは、幸運を祈ります、旦那様！新しい冒険が実り多きものになりますように。
こんにちは、皆さん、そして明けましておめでとうございます！
これは私にとって時宜を得たトピックです。なぜなら、時間とお金を節約するために、まさに自分のセットアップを調整している最中だからです。私はトラフィックは非常に少ないですが、私にとって大切な3つの小さなプライベートサイトを持っています。また、新しいアイデアを試すために、さらに多くのサイトを立ち上げられるようにしたいと考えています。そのため、マルチサイトには興味があると思います。
とはいえ、ちょうど1つのサイトをDigitalOceanからHetznerに移行したところ、コスト削減に驚きました。最小構成のcx23プランが月額わずか3.49ドルで、これは単一の小さなサイトにはほぼ理想的です。DigitalOceanでは同様の構成で月額15.60ドルを支払っていました。
この記事やその他の関連トピックを読んだ上で、マルチサイトに関する私の主な懸念は、すべてのサイトでダイレクトデリバリーメールを使用したいということです。その際、メールのドメイン名はサイトのドメイン名を使用し、サイトメンバーに認識されやすく、信頼されるようにしたいと考えています。その設定方法に関する説明は、あまり分かりやすくないようです。
そのため、現時点では、スタンドアロンサイトのままで、それらをすべてHetznerに移行するのが最善かもしれないと結論付けています。スタンドアロンサイトの設定にはかなりの時間がかかるため、お金は節約できますが、時間の節約にはあまりならないでしょう。
それは可能ですが、すべて同じSMTP認証情報を使用している場合に限ります。
新しいHetznerの方がはるかに安価なので、古い料金で1サイトだけを持つよりも、3サイトで十分にお得になります。
1GBのRAMでマルチサイトを構成することは推奨しませんし、設定にも手間がかかりますが、新しいホスト名エイリアス（hostname aliases）の環境設定（env setting）が最大の問題の1つを解決します。
cx23には4GBのRAMがあります。他の2つのサイトを個別のcx23サーバーに移行するので、どうなるか見てみましょう。大丈夫だと思いますが。
これは、mail-receiverはメールの受信のみに関係し、SMTP認証情報がないため、混乱しています。
送信用メールについて話していますか？送信用メールの場合、各サイトはapp.ymlに独自のSMTP認証情報が設定されていませんか？
いいえ、メール受信機能は別です。マルチサイトを使用している場合、YMLファイルは1つだけであり、そこにSMTPの送信認証情報を設定します。メール受信機能を使用している場合、別の問題が発生しています。なぜなら、各サイトにメール受信機能が必要だからです（少なくとも、私が見つけた唯一の解決策はそれです）。