サイトを 3.1.0.beta1 から 3.1.0.beta2 に更新し、新しいバージョンをブートストラップした後、古いアプリコンテナを破棄して新しいものを開始する前に、少なくとも 1 つのサイトでユーザーに汎用エラーページが表示され始めました。
テストサイトやその他の実行中のサイトでは気付きませんでしたが、発生していても気付かなかった可能性はあります。
いずれにせよ、少なくとも 1 つのケースで「ゼロダウンタイム」アップデートプロセスは成功しませんでした。
9件の投稿が新しいトピックに分割されました: Problems with self-hosted upgrade to 3.x: cannot roll back
投稿が既存のトピックにマージされました：セルフホスト版の3.xへのアップグレードに関する問題：ロールバックできない
GUIアップデーターを使用していなかったことを繰り返します。マルチコンテナインストールを使用しています。実行したのは以下の通りです。
git pull
./launcher bootstrap app
./launcher destroy app && ./launcher start app
./launcher cleanup
（マルチコンテナインストールでも、Webアプリにはappを使用しています。通常の方法ではないことは承知しています。web_onlyと入力するのが嫌なのです）
bootstrapを開始してからアプリを破棄するまでの間に、新しいデータベースに対して古いバージョンが実行され、エラー画面のみが表示されました。その内容は覚えていませんし、スクリーンショットを撮るためにダウンタイムを長くするようなことはしませんでしたが、白い画面に文字が表示されるだけで、システムのメンテナンスページではありませんでした。以前にも数回経験したことがありますが、bootstrapが非同期の「ゼロダウンタイム」再構築の一部としてdb:migrateを実行する際に、実行中の古いソフトウェアがスキーマの不整合により失敗するというものです。
私が目にしたのは、データベースの不整合が発生した場合に起こることでした。データベースを破損させて平然と続行するよりも、ずっと良いことです！投稿したのは、ポイントアップデート（ここでは3.1.0.beta1から3.1.0.beta2へ）が、マルチコンテナデプロイメントにおける通常の低ダウンタイムアップデートで時折発生するような、3.1.0.beta1のコードとdb:migrateを実行した後のデータベースとの間にスキーマの互換性の問題を引き起こす、まれなケースがあることを警告するためでした。
私の経験は、GUIアップデーターでRubyに関するエラーが報告されたものとは異なります。全く関係のない問題です。私の投稿がアナウンスから一般的な「問題」スレッドに移動されたことは認識していますが、この特定のアップデートが影響を与える可能性があることを、私のようなセルフホスティングユーザーに警告するためにアナウンスに投稿したことを明確にしたいです。
私のメッセージは、バグや問題についての不満ではありませんでした。単に、この特定のリリースに関連する、通常は発生するがまれにしか起こらない、リリースノートで特に言及されていないケースについての通知を意図したものでした。
Dockerマネージャーがイメージ内から更新できないことを認識しないという苦情は、他のセルフホスティング管理者への有益な通知を提供しようとした私の試みとは全く関係ありません。
これらの無関係な問題を独立したスレッドに分離する方がはるかに理にかなっているでしょう。 @supermathie による編集：完了しました
「いいね！」 1
Introducing Post Deployment Migration を使用した 2 段階移行を実行していますか？
このパターンは、たとえばブルー/グリーンデプロイメントを実行していて、以前のバージョンが引き続き機能する必要がある場合に重要です。
「いいね！」 1
これで質問に答えられたと思います。launcher スクリプトは SKIP_POST_DEPLOYMENT_MIGRATIONS をサポートしていません。
繰り返しますが、バグを報告しているのではありません。 通常のドキュメント化されたプロセスを使用して launcher をマルチコンテナインストールで使用している他の人々に、今回のインストールは通常の経験とは異なることを警告しようとしているだけです。
本当に、本当に、正直に、私はこれを言っています、これはバグ報告ではありません！
もし launcher でブルー/グリーンデプロイメントを行いたいのであれば、それを実装するために launcher に PR を提供する必要があります。
「いいね！」 1
トピックタイトルの「問題」は、私のコメントが発表スレッドから移動されたときに付けられたもので、私が考えたものではありません。タイトルを明確にするために変更しました。これで、私が問題を訴えているのではないことが、ご理解いただければ幸いです。
「いいね！」 1
すべて順調です！
マルチコンテナのブルー/グリーンデプロイメントを行っているユーザーはごく少数だと推測されますが、その方法に関する提案は大歓迎です。
また、私がリンクしたトピックをどのように見つけるかについても、存在を知らないと見つけるのが簡単ではないと推測されます。
「いいね！」 2
SKIP_POST_DEPLOYMENT_MIGRATIONS のドキュメントは確認していましたが、launcher を使用したゼロダウンタイムデプロイの方法を示すこの投稿を見落としていました。
それが可能だとわかったので、今度はそれを検討する必要があります。もし実施したら、私がやったことを MKJ's Opinionated Discourse Deployment Configuration に追記します。
個人的に無料で、空き時間に運用しているサービスで、4ナイン、時には4.5ナインの可用性を提供しているのに、それについてあまり熱心になれないでいました。これは、テスト合格ポリシーで、時折ホストを再起動してセキュリティアップデートを行うことさえ含めて、そのようなことができている Discourse の開発品質の証です。
「いいね！」 3
dashboard.literatecomputing.com が使用している Ansible スクリプトは、新しいコンテナが起動された後に Rake タスクを実行して、デプロイ後のマイグレーションを行います。これは web_only.yml で SKIP_POST_DEPLOYMENT_MIGRATIONS が有効になっていることを前提としています。これは、仕組みを理解していないと時限爆弾になりうるため、私が管理していることがわかっているサイトでのみ行っています。
多くのアップグレードでは、新しいコンテナをブートストラップしても実行中のコンテナに問題は発生しませんが、一部では問題が発生します。アップグレードによって、古いコンテナがデータベースを使用できなくなるようなマイグレーションが行われることは珍しくありません（SKIP_POST_DEPLOYMENT_MIGRATIONS を使用しない場合）。
「いいね！」 2