皆さん、こんにちは。
Discourse/コンテナを（ホストやコンテナ自体のリソースの調整以外で）より速く起動/ブートさせるように調整することは可能でしょうか？（公式にはカバー/サポートされていなくても）
単一のスタンドアロンの app.yml の代わりに複数のコンテナファイルを使用することもできます。
しかし、正直に言って、コンテナを頻繁に再構築する必要がある人はほとんどいないですよね？
プラグインをインストールする必要がある場合、コンテナを再構築する必要はありません。再構築なしでプラグインをインストールする非公式な方法があります。
本当に起動を速くしたいのですか？つまり、コンテナを再起動した後に、より早くページを提供できるようになることですか？それはできません。Railsやその他のものを起動するには時間がかかります。
コンテナの再構築に伴うダウンタイムを意味するのであれば、2つのコンテナを使用するソリューションが適しています。
それでも十分でなく、ダウンタイムをゼロにしたい場合は、ロードバランサーを使用して、古いコンテナがページを提供し続けている間に新しいコンテナを起動し、新しいコンテナが準備できたら古いコンテナをシャットダウンするなどの方法があります。
再構築を意味するとは限りません。
たとえば、すべてを docker で管理するとします。
docker コンテナを再起動するだけでも、Discourse は起動時に多くのことを実行するように見えます — はい、それが私が意味していたことです — Ruby/Rails のようなもので、これを調整/削減できますか？ (なぜ毎回起動時にすべてが行われるのですか？それは永続化できないのですか？)
2コンテナソリューションとは何ですか？
関連するビットが衝突せず、同じホスト上で（両方のコンテナが）同じ外部の pgSQL および Redis に話しかける2つのコンテナですか？
それともゼロダウンタイムセットアップですか？
提供する準備をするために、たくさんのコードを読み込む必要があります。スマートフォン、コンピューター、または最新のテレビを起動したことがありますか？時間がかかります。それと全く同じです。コンテナにはOS全体が含まれています。
はい。Rails+Nginxを独自のコンテナに分離し、PostgresとRedisを別のコンテナに入れています（または、RedisとPostgresをどのように提供したいかによります）。