問題タブ [blue-green-deployment]

次のアーキテクチャで WebSphere 8.5 を実行しています。2 つのアプリケーション サーバーで 1 つの IHS サーバーの負荷分散を行います。

もちろん、私は 2 つの AS に複数のアプリケーションを展開していますが、1 つのアプリケーションが 1 つの AS で利用できなくなったことを IHS が検出できないという印象を受けました。

スクリプトを使用して AS の 1 つのみでアプリケーションを停止しました。IHS は、アプリケーションを実行している AS と他の AS に要求をディスパッチし続け、次の不快なメッセージが表示されます。SRVE0255E: A WebGroup/Virtual Host to handle /xxxxxxxx has not been defined.

フェールオーバー プラグインの最も細かい粒度はアプリケーション サーバーですか?

ダウンタイムのリスクを軽減し、Blue / Green デプロイを実現する必要があります。IHS サーバーのルートを更新して、アプリケーションを実行しているサーバーでのみ負荷分散するように依頼する必要があります。

前もって感謝します

Blue-Green デプロイ戦略の一環として、prod RDS インスタンスのスナップショットを作成し、このスナップショットを新しいインスタンスに復元して、その後に db migration を適用し、新しい Green アプリケーションをそれにリンクしています。

RDS インスタンスには 100 GB のスペースがありますが、DB は現時点で 10 MB しか使用していません。

スナップショットの作成にかかる時間は約 2 分未満です

スナップショットからの復元には 25 分かかります。

ユーザーがこの期間中ずっと読み取り専用モードを維持することを余儀なくされ、DB サイズが現時点で 10 MB 未満であることを考えると、復元に 25 分間は長すぎます。

この復元時間は Amazon RDS の通常の時間なのか、それとも何か間違っているのか疑問に思っています。

• アマゾン RDS ポストグル。
• マルチ AZ: はい
• インスタンスクラス: ミディアム
• 汎用 (SSD)
• IOPS: 無効。

現在、Azure ServiceFabric で ReliableActors フレームワークを使用してアプリケーションを構築しています。スケールアップするにつれて、ブルー/グリーン デプロイを検討しています。ステートレス システムを使用してこれを行う方法を確認できます。ステートフル アクターを使用してこれを行う方法はありますか?

この質問に名前を付ける方法がよくわかりません。しかし、それを説明するために、以下に期待をリストします。

• アプリケーションを Bluemix 上で実行する。
• ローカルにコードを持つ。
• git を介して Bluemix にプッシュします。
• 新しいコードを有効にするには、アプリケーションを再起動してください。

問題は
、上記の状況で、サーバーの再起動中のダウンタイムを回避したい場合 (予期しない問題が発生した場合、ダウンタイムが長くなる可能性がある場合)、Web サイトが Bluemix サーバーを介してデータを転送し続けるにはどうすればよいかということです。シャドウサーバーを使用する必要がありますか? Web サイトがダウンタイムに気付かない場合にいつ (自動/手動) に切り替えるかを知るために、それらを管理するにはどうすればよいですか? どうもありがとう。

ここの画像で詳しく説明されているものと非常によく似たセットアップを試しています: https://raw.githubusercontent.com/Oreste-Luci/netflix-oss-example/master/netflix-oss-example.png

私のセットアップでは、クライアント アプリケーション ( https://www.joedog.org/siege-home/ )、プロキシ (Zuul)、検出サービス (Eureka)、および単純なマイクロサービスを使用しています。すべてが PWS に展開されます。

シンプルなマイクロサービスの 1 つのバージョンから次のバージョンに、ダウンタイムなしで移行したいと考えています。最初は、 https ://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html で説明されている手法から始めました。

私の意見では、このアプローチは Eureka などの発見サービスと「互換性」がありません。実際、私のサービスの新しいバージョンは Eureka に登録されており、すべてのルート (CF ルーター) を再マッピングする前でもトラフィックを受信して​​います。

これにより、Spring Cloud/Netflix のフェイルオーバー メカニズムに依存する別のアプローチにたどり着きました。

1. サービスの新しい (下位互換性がある) バージョンをスピンアップします。
2. このバージョンが Zuul/Eureka によってピックアップされると、トラフィックの 50% を取得し始めます。
3. 新しいバージョンが正しく動作することを確認したら、「古い」インスタンスを削除します。（PWSの「停止」ボタンをクリックするだけです）

私が理解しているように、Zuul はボンネットの下でリボン (負荷分散) を使用しているため、古いインスタンスがまだ Eureka にあるが実際にはシャットダウンしている一瞬で、クライアントに影響を与えずに新しいインスタンスで再試行することを期待しています。

しかし、私の仮定は間違っています。クライアントで 502 エラーがいくつか発生します。

私のapplication.ymlの一部

何がうまくいかないのかわかりません。

これは技術的な問題ですか？

それとも、私は間違った仮定をしていますか (POST はとにかく再試行されないことをどこかで読みましたが、これはよくわかりません)。

どうやってそれをするのか聞いてみたいです。

ありがとう、アンディ

Azure の WebApp 上に WordPress のアプリケーションがあります。

DEV と Prod という 2 つの環境があります。製品にはステージング スワップ スロットがあります。

DEV と PROD は、明らかに異なる MySQL データベースを使用します (現在、MySQL In App を使用していますが、ClearDB/MySQL セットアップに関する同じ質問です)。

それで、質問は - ブルーグリーン展開をどのように行うのですか? データベースをどうするか?

コードをさまざまな環境にデプロイするように Travis を構成しました。しかし - Prod のデータベースは訪問者による使用中に更新され、DEV は開発者によって更新されます (もちろん、Prod からの訪問者の変更はありません)。

それを実現するための解決策/実践はありますか?

PSそしてもう1つ問題があります。「MySQL In App (プレビュー)」では、WebApp とそのステージ (スワップスロット) のデータベースを分離することはできません。これは、私たちにとって追加の頭痛の種です。

昨日、チームと一緒に、シングル ページ アプリケーションをサポートするためにゼロ ダウンタイム デプロイを使用する可能性について話し合っていました。

それについて話し合っているうちに、1 つのエッジ ケースを特定しました。ユーザーがブラウザにページをロードすると、ページをリロードするまでメモリから削除できません。つまり、ユーザーがページをロードして Web サイトで作業を開始した場合 (たとえば、私が今行っているように長い記事を入力し始めた場合)、ページをリロードするまで、更新されたバージョンを受け取ることができません。

ユーザーのブラウザに古いバージョンのアプリケーションが表示されるという事実は無視できますが、以下に示す 2 つの点があります。

1. スパを提供するために使用される HTTP Api に重大な変更を導入した場合、ユーザーは記事を保存できなくなったり (データ損失!)、他のバックエンド関連のアクションを実行したときに他のエラーを受け取ったりする可能性があります。
2. ユーザーが SPA をリロードせずに新しいページに移動すると、次のページのテンプレートまたは外部の古いコンテナーと互換性のないコントロールのテンプレートを受け取ることができます。マークアップやアプリケーション ロジックの破損につながる可能性があります。
3. ユーザーが記事を入力している途中である可能性があるため、ユーザーに再ログインを強制することはできません。これは単に悪い UX です。

これらすべての点を考慮に入れると、次の解決策を提案できます。

1. ユーザー 1 は、SPA の v1 をブラウザーにロードします。
2. 認証トークンとともに、バージョン情報がブラウザーに送信されます (たとえば、JWT を使用)。
3. アプリケーションの v2 バージョンをデプロイしたいと考えています。v2 バージョンをスピンアップしますが、v1 を無効にしません。
4. ユーザー 2 は、SPA の v2 を自分のブラウザーに読み込みます
5. ユーザー 1 は、SPA の次のページに移動します。ロード バランサーはトークンのバージョン情報をチェックし、ユーザー 1 のトラフィックを v1 サーバーにルーティングします。
6. ユーザー 2 は、同じ方法で v2 にルーティングされます。
7. ユーザー 1 がアプリをログアウトし、ブラウザーを閉じます。
8. ユーザー 1 は再度ログインします。今回は v2 を受け取ります。
9. v1 アプリケーションが長時間トラフィックを受信しないと、破棄されます。

ただし、このアプローチでは、2 つ以上の複数のバージョンを有効にすることができます (たとえば、ユーザーが 1 日か 2 日オンラインでいる場合)。これは、最後のユーザーがログアウトするまで、データベースを新しいスキーマに移行できないことを意味します (Facebook などのサイトでどのように機能するかをイメージしてください)。複数のバージョンを使用することは問題ではありませんが、Docker や Rancher などのツールを使用すると簡単に行うことができます。

また、ステップ 7 では、ユーザーはページをリロードするか、ブラウザーを閉じる必要があります。そうしないと、ユーザーはまだ v1 で作業しているため、次のバージョンに強制することはできません。

私が持っている質問は、シングル ページ アプリケーションのゼロ ダウンタイム/Blue-Green デプロイを行うためにどのようなアプローチを使用するかということです。

特に既存の「ブルー」クライアント アプリケーションに関して、トラフィックを「グリーン」バージョンに切り替えるときに、アプリケーションの「ブルー」バージョンの有効期間をどのように管理しますか。

これらの問題を解決しましたか、他の解決策を知っていますか?

ブルー/グリーン展開戦略の実装を検討しています。これは、データベース駆動型の Web アプリケーション用です。現在、Teamcity と Octopus デプロイを使用しています。

私の知る限り、この戦略を達成するには、データベースへの変更は、両方のバージョンのアプリケーションが引き続き機能するようにする必要があるため、ロールバックの場合、データベースの変更を元に戻す必要はありません。

Octopus が提案するこれの実装を読みました here。

私の質問:

• 本番環境に昇格する前に、データベースの変更に対して本番環境で現在アクティブなアプリケーションをテストする人はいますか? たとえば、テストまたは UAT では?
• もしそうなら、特に Octopus で構成する場合、この要件を展開戦略にどのように適合させますか?

最近、marathon-lb github ドキュメント ( https://github.com/mesosphere/marathon-lb#zero-downtime -展開)。そして、スクリプトに現在のバージョン（緑色のもの）を完全にデプロイするように指示しているときに問題が発生しました。これは、青色または古いデプロイの最後の単一のタスクを強制終了してゼロにスケーリングしません。したがって、私の青いアプリは常に 1 のままです。marathon-lb github ドキュメントよりも zdd.py のより良いドキュメントはありますか?