こんにちは。Discourse のインストールが完了しました。非常にわかりやすくセットアップしていただき、ありがとうございます。
理想としては、Discourse サーバーを使い捨てにしたいと考えています。例えば、EC2 コンソールで誤ってサーバーを停止してしまっても、データを失いたくありません。
組み込みのバックアップ/復元機能は素晴らしく、すでにいくつかテスト実行しました。app.yml、アップロード、バックアップは S3 に保存しています。
次のステップは、データベースを Amazon RDS に移行することです。これについては、こちらに素晴らしいガイドがあります。
私の質問は、これを実行した場合、理論的にはインスタンスを終了しても安全で、新しいサーバーで Discourse をクローンし、app.yml を取得して ./launcher rebuild app を実行すればよいのでしょうか？それとも、PostgreSQL/アップロード/app.yml 以外にも状態が存在するのでしょうか？例えば Redis などに？
よろしくお願いいたします。
それは概ね正しいと思います。同時に2つ実行しないように注意する必要があります。新しいコンテナをビルドする際に、データベースを移行することになり、もう一方のコンテナでは使用できなくなる可能性があります（skip_post_deployment_migrationsを使用することでこれを回避できます）。Redis内のものは一時的なものと見なされ、バックアップされません。そこにある一部のものがどのように、あるいは復元されるかについてはよくわかりませんが、おそらく気にする必要はないでしょう。
@phil22 - あなたが提案しているようなセットアップに取り組んだことがありますが、それはあなたが考えているよりも微妙です。
Discourseチームは月に複数回のリリースを行っているため、新しいec2にクローンする際には元のバージョンに留まる必要があります。通常、アプリを盲目的にアップグレードしても問題ありませんが、一部のリリースにはメジャーなデータベースアップグレード（PG 12 → PG 13）が含まれており、これを追跡せず、外部RDSのアップグレードを怠ると、行き詰まる可能性があります。
ec2がEBSボリュームを使用し、それがアプリコンテナ内にマウントされるように設定することで成功しました。これにより、/sharedフォルダーのすべてのコンテンツを保存します。そのようにすれば、ec2インスタンスがなくなっても、この共有フォルダーのコンテンツはすべてEBSに永続化されます。さらに、場合によってはファイルをs3に保存するという考えを変えることがあります。その場合、アップロードされたファイルを保存する代替場所（/sharedフォルダーなど）があるのは良いことです。
お役に立てば幸いです。
@pfaffman と @Poster_Nutbag、どうもありがとう。非常に参考になりました！
EBS の方が良い選択肢のようですね。discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub から逸脱することを避けられます。
アドバイスに従い、RDS を選択することにしましたが、discourse_docker リポジトリの特定のコミットにピン留めします。これによりアップグレードがより複雑になるように思えますが、サーバーに問題が発生した場合、RDS 上で安全にすべてを保持でき、手動での復元なしで同じ作業状態にかなり迅速に戻れることを願っています。
（EBS でも同じことを達成できると思いますが、ボリューム暗号化とインスタンス間でボリュームをマウント/アンマウントするための Unix の魔法により、その自動化プロセスには少し不安があります）