ありがとうございます。つまり、./launcher rebuild app の代わりに ./launcher rebuild web_only （または rebuild data）を使用し、PostgreSQL や Redis が更新されたら、手動で更新するためにアップデートを注意深く読む必要があるということですね。スタンドアロンと比較した場合の主な利点は、再構築ではデータベースのシャットダウンと再起動を待つ必要がなく、データベースが停止した場合にトランザクションをロールバックする必要がないことです。
しかし、Falco の最新の変更により、シャットダウンに 10 分以上かかる場合を除き、データベースが停止することはありません。ユーザーが大幅に増えない限り、それほど時間はかからないはずです。そのため、アップデートはこの問題で失敗することはありません。主な影響は、アップデートに数分多く時間がかかるだけです。
私の理解では、最終的にこの変更は、ほとんど利益がないにもかかわらず、多くの複雑さと精神的なオーバーヘッドを追加することになります。もし私が間違っていたら訂正してください。これは皮肉やその他の意図はありません。
背景として、この変更は、私がボランティアで行っている（15年以上続いていますが）、仕事ではないため、かなりのメリットがない限り、そのオーバーヘッドに見合う価値はありません。そこは個人の状況によって大きく異なります。
pfaffman
(Jay Pfaffman)
23
その通りです。
その意見を持つ人はたくさんいますが、私はそれが驚くべきことだと感じ続けています。Postgres のアップグレードは年に 1 回未満であり、通常、最初の変更から数か月遅延してもペナルティはありません。2 コンテナー セットアップを使用すると、シングル コンテナーの場合よりも Postgres のアップグレードを遅延させることが容易になります。これは私にとってさらに利点のように思えます。
2 コンテナー セットアップを使用すると、
./launcher bootstrap web_only && ./launcher destroy web_only; ./launcher start web_only
通常、1 分未満のダウンタイムで済みます。
しかし、あなたはそうしたくないので、そうしないでください。
「いいね！」 3
Postgres のアップグレードを遅らせることは、これまで単純な設定 YAML の変更で済みましたが、皆さんがそれをサポートしなくなるという計画がない限り、の話です。アップグレードのための数分間のダウンタイムは許容できますし、私の目には、標準的ではなく、より複雑な構成を適切に維持する一人の人間（それが私です！）に依存するよりも、リスクが低いように思えます。
Ed_S
(Ed S)
25
私の見解では、2つのコンテナの主な利点はダウンタイムの削減です。あなたと同じように、数ヶ月に一度の20〜30分のダウンタイムは許容範囲だと思います。しかし、フォーラムによってはそれが多すぎると感じることも容易に理解できます。
「いいね！」 1
そうですね。たとえ90分間の単独停止時間と5分間の分離停止時間を比較したとしても、その変更は割に合わないと思うでしょう。しかし、もしそれだけの時間がかかるのであれば、日中の都合の良い時間帯ではなく、深夜にアップグレードを行うでしょう。私たちはリアルタイムの株式取引プラットフォームではなく、ビデオゲームに関する無料フォーラムなのですから。
pfaffman
(Jay Pfaffman)
27
2 コンテナ セットアップでは、その単純な変更を行う必要があることさえ知る必要はありません。また、アップグレードを開始してから、すでに Postgres のアップグレードを開始していたことを知る可能性はゼロになります。
しかし、私は 35 年近くシェルで生きてきました。
そして今、これらのコマンドライン アップグレードを自動化する (Postgres のアップグレードやその他の多くのことを処理する) ダッシュボードがあります。
しかし、壊れていないものを修正せず、物を移動したり、潜在的に壊したりすることが怖いことは理解しています。
「いいね！」 2
私はSlackwareから始めました。フォーラムのメンテナンスは楽しいプロジェクトではないので、Google HomeをHome Assistant（またはその週に気に入った他のもの）と統合しようと頭を打ち続けることができるように、なくなってほしいと思っています。
「いいね！」 1