2つのウェブサイト構成における App.yml の共有ボリューム

サポート インストール
1

app.yml を変更して、同じマシン（nginx の背後で動作）上に別の Discourse インスタンス（別のコンテナ、別のデータベース、考えられるすべての要素が分離されたもの）を起動できるようにしたいと考えています。

まず、現在の設定（重要な部分のみ）は以下の通りです：

## app.yml for site01
volumes:
  - volume:
      host: /var/discourse_site01/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

この設定は問題なく動作しており、インスタンスはオンラインで正常に稼働しています。次に、別の Discourse インスタンスをホストしたいと考えており、そのために別の app.yml で共有ボリュームを以下のように設定しました：

## app.yml for site02
volumes:
  - volume:
      host: /var/discourse_site02/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse_site02/shared/standalone/log/var-log
      guest: /var/log

この 2 番目の設定に何か落とし穴はありますか？本番環境のマシンで実行するため、この app.yml が正しいか確認したく思っています。

2

本番サーバーで直接実行するのではなく、事前にクローンやステージング環境でテストすることを強くお勧めします。

nginx の使用について詳しく教えていただけますか？同じマシン上に他の本番サービスはありますか？

3

@Stephen: nginx は単に最初の Discourse インスタンスへのリバースプロキシです。複雑なことはありません。実際、このセットアップは、nginx をフロントエンドサーバーとして設定するために meta.discourse で私が行った手順と同じものです。

このマシンでは他のサービスは一切実行されていません。実際、これは本番環境のマシンであるため、すべてを完全に分離されたホストフォルダ discourse_site02 に設定しました。これでご理解いただけますか？

私が説明した app.yml に問題は見つかりますか？それとも、設定に何か不具合があるとお考えですか？

4

では、なぜ2コンテナマルチサイトインストールを使用していないのでしょうか？ここではポータビリティがほとんど失われることはないと思います。サーバー間でインスタンスを移動させる最も簡単な方法は、バックアップを移行することです。

インスタンスを移動する必要がある場合は、新しいサーバーを起動し、古いインスタンスをリードオンリーに設定し、DNSを再設定してバックアップを復元するだけです。Cloudflare のような低 TTL サービスで DNS を処理している場合、小規模なサイトでも数分で移行できます。ユーザーは一時的なリードオンリーアクセスを経験するだけで、コンテンツが失われることはありません。

このようにリソースを分割する方がはるかに効率的です。2 つのデータベースサーバーと 2 つのウェブサーバーを別々のコンテナで実行することになり、nginx リバースプロキシの必要性が完全に不要になります。

5

@Stephen: はい、ご提示いただいたリンクは確認しました。ただし、設定の簡素化のため（当社は小規模なチームで経験も浅いため）、私が説明した方法、つまりデータベースが2つ、ウェブサーバーも2つなどという構成で進めたいと考えています。実際、これが私が好む構成です。

ご指摘いただいた非効率性の他に、何か見落としや注意点はありませんか？
私が示した2つの app.yml ファイルは正しいでしょうか？

お時間をいただき、素晴らしいソフトウェアを提供してくださりありがとうございます :smile:

よろしくお願いいたします。

6

@Stephen: 単に気になったのですが、2 つのコンテナ構成の設定はこれで正しいでしょうか？

先ほども述べた通り、リソースの節約や効率化は目指していません。将来的に何か問題が発生しない限り、この方法で実行しても問題ないかどうかを知りたいだけです。