皆さん、こんにちは。
全体を再構築せずに新しいバージョンに更新することは可能でしょうか？
2つのDiscourseアプリケーションが実質的に同一であり、一方の新しいイメージが準備できたら、それをコンテナのすべての設定/パラメーターを使用して2番目のDiscourseをデプロイするために使用できるシナリオを考えています。
このようなコンテナについて対処する必要があるのは、pgデータベースの移行だけでしょうか？
これは理にかなっていますか？もし可能なら、理想的にはソースコードをいじることなく、どうすればよいでしょうか？
よろしくお願いします、L。
イメージをビルドし、リポジトリにプッシュしてから、./launcher start-cmd app を使用してコンテナを起動するための Docker コマンドを取得できます（ただし、ローカルのリポジトリをコンテナリポジトリに置き換える必要があります）。
しかし、その後、データベースの移行、アセットのプリコンパイルなどを行う必要があります。
ダウンタイムを避けたい場合は、2 コンテナ設定を使用すると、古いコンテナが実行を継続している間に新しいコンテナをビルドでき、移行などを処理してくれます。
特に注意を払いたい場合は、app.yml で SKIP_POST_DEPLOYMENT_MIGRATIONS を設定し、新しいコンテナが起動した後に rake db:ensure_post_migrations db:migrate を実行できます。これを実行しないと、古いコンテナが使用できなくなるようにデータベースが移行される可能性があります。これはめったに問題にならず、また、ごく短時間のことです。
ダウンタイムは私にとって問題ではありません。
思いつく2つのアプリは、実質的に同一でありながら同じではないものです。
2つのアプリは、異なるサイト、つまり異なるデータベース、ボリューム、ポート、名前を持つことになりますが、いわば同じ基本ディスコース（+同じプラグイン、そのコア/ベースにとって重要ないかなるものも同じ）を持つことになります。
Discourseの理想的な世界では（もしそれがまだ存在しないなら）、そのようなシナリオのために、一度ビルドされた新しいイメージは、Dockerツールを使って直接使用することもでき、そのような「セカンダリ」コンテナの起動/ブートプロセスは、環境変数（env vars）の助けを借りて、データベースの必要なマイグレーションをチェック/実行することを決定するでしょう。
主な利点――多くの人がすでに考えたことでしょう――は、両方の（あるいは、そうする人がいるならさらに多くの）コンテナ/アプリに対して単一のイメージを持つことです。
私が説明したように、それは可能です。また、単一のイメージを使用して再構築しないことを可能にする新しいスキームも進行中です。これはサポートされていないため、ここで、またはGitHubでよく検索する必要があります。