問題タブ [blue-green-deployment]

現在、Heroku で 2 つの dyno を使用して Ruby on Rails プロジェクト (RefineryCMS) を実行しています。

サイトを更新するたびに、約 1 ～ 2 分間のダウンタイムが発生します。経営陣はこれに満足していません。

私たちが本当に望んでいるのは、ある種の (透過的な) Blue-Green Deployment です: http://martinfowler.com/bliki/BlueGreenDeployment.html

これは Heroku またはサービスとしての別のクラウド プラットフォームで実現できますか?

Unicorn も使用していますが、必要に応じて変更します。

Martin Fowler のBlue/Green Deploymentの記事を読んで、とても気に入りました。基本的には、「ブルー」ライブ環境と「グリーン」ライブ環境の 2 つのプロダクション クラス環境があるという概念です。「実際の」ライブ環境と見なされる環境は、常に 1 つだけです。したがって、これら 2 つの LIVE 環境の前に何らかのルーティング/スイッチ メカニズム (おそらく中間 Web アプリまたは変更されたソフトウェア ロード バランサー) を配置し、ユーザーがどの環境にルーティングされるかを決定します (ここでは Web アプリについて説明します)。

したがって、すべてのユーザーが、たとえば の Green LIVE 環境にルーティングされますhttp://green.example.com/myapp。次に、いくつかの新しい本番環境の変更をプッシュする準備ができたら、それらを Green LIVE にデプロイする代わりに Blue LIVE にデプロイし、少数 (~10%) のユーザーを Blue LIVE にルーティングし始めます。一般的な戦略は、ルーターに IP アドレスまたは Cookie を使用させて、ユーザーを Blue と Green のどちらにルーティングするかを決定することです。

プロダクションの変更 (Blue LIVE に適用) にバグ バグ/問題がないことを確信したら、ルーターを再構成して、すべてのトラフィックを で Blue LIVE にリダイレクトしhttp://blue.example.com/myappます。

さて、私の質問に：

私は GWT アプリを設計しており、この青/緑の切り替えパターンを実装したいと考えています。問題は、GWT アプリがクライアント側であり、Spring、Struts、JSP、サーブレット アプリが利用する通常のサーバー側 Web アプリ アーキテクチャに従っていないことです。

だから私は尋ねます：どうすれば2つのTomcatインスタンス（Blue TomcatとGreen Tomcat）を持ち、同じGWTアプリの2つの異なるバージョンを青/緑の「ルーター」の後ろからユーザーに提供できますか? 「ルーター」とは、おそらくhttp://router.example.com/myapp-router.

視覚的には、ここに問題があります。

これが基本的なアーキテクチャです。問題は、クライアントが にリクエストを送信しrouter.example.com/myapp-router、ルーターがそのリクエストをblue.example.com/myappまたはに転送することgreen.example.com/myappです。GWT (ここではRequestFactoryを使用しています) が、GWT アプリがクライアントにダウンロードされた後、blueまたはいずれかと通信することを最終的に認識するとは確信していません。green

だから私は尋ねます：これは可能ですか？特別な構成/コード/ライブラリ/テクニックなどはありますか?これを機能させるために利用する必要がありますか? 私が考えていない警告や落とし穴はありますか？前もって感謝します！

環境

• 本番環境で RavenDB インデックスを更新するための安定した一貫したアプローチを設計しようとしています
• 特にインデックス更新の話に焦点を当てています (つまり、私のセットアップが高可用性に完全に対応していないことを知っています)。
• これは架空のシナリオです (つまり、現在実稼働環境には何もありません)。
• ハードウェア/ソフトウェア/ネットワーク構成が柔軟であると仮定します (つまり、別の RavenDB インスタンスの追加、サーバーの追加、永続キャッシュなど)。

現在のホスティング シナリオ

• 2 つの Web サーバーがアクティブ/パッシブ構成で負荷分散され、それぞれが 1 つの Web アプリケーションを実行します
• RavenDB インスタンスを実行する 1 つのサーバー (最新の安定バージョン)

制約

• プロセス全体を通して高可用性を維持する必要がある
• 導入プロセスは完全に自動化されます
• 展開プロセスは、展開中の任意の時点でロールバックを開始する可能性があります
• インデックスの再構築には最大 1 分かかる場合があります。これほど長い間データを表示できないことは受け入れられません

  ---

考えられる解決策

2 つ目の RavenDB インスタンスを追加し、アクティブ/アクティブ構成で RavenDB をレプリケートする

• アクティブな Web サーバーがアクティブな RavenDB インスタンスと対話する
• パッシブ Web サーバーがパッシブ RavenDB インスタンスと対話する

展開は次のようになります。

• レプリケーションを停止する
• 新しい Web アプリケーション コードをパッシブ Web サーバーにデプロイする
• Web アプリケーションを起動し、RavenDB インスタンスのインデックス定義を自動更新します
• テスト
• ロード バランサーをパッシブ Web サーバーに切り替えて、アクティブにします
• (x 時間) 監視し、必要に応じてロールバックする
• レプリケーションを開始し、他の RavenDB インスタンスでインデックス定義とデータを更新します

ロールバックは次のようになります。

• ロード バランサーをパッシブ Web サーバーに切り替えて、アクティブにします

これを実装するためのより最適な方法はありますか?

カナリア リリースとは、スティッキー セッションがオンになっている本番ノードのサブセットへの部分的なリリースであると私は理解しています。そうすれば、悪いバグをリリースした場合に影響を受けるユーザー/顧客の数を制御および最小限に抑えることができます。

Blue/Green リリースについての私の理解では、2 つのミラー化された本番環境 ("blue" と "green") があり、変更を一度に blue または green のすべてのノードにプッシュし、ネットワーク マジックを使用して制御します。ユーザーが DNS 経由でルーティングされる環境。

ですから、始める前に、これまでに言ったことに誤りがある場合は、まず訂正してください。

私が多かれ少なかれ順調に進んでいると仮定すると、2 つの戦略に関するいくつかの質問があります。

• ブルー/グリーンよりもカナリアが好まれるシナリオ、またはその逆のシナリオはありますか?
• 展開モデルで両方の戦略を同時に実装できるシナリオはありますか?

ゼロ ダウンタイム デプロイのために CNAME スワッピングで Elastic Beanstalk を使用する場合、DNS キャッシング (クライアントが TTL を尊重しない) により、一部のクライアントが古い環境にトラフィックを送信し続けます (最大数日間)。

Elastic Beanstalk と Route53 エイリアスを使用してゼロ ダウンタイム デプロイを行う場合、DNS キャッシングは引き続き問題になりますか?

node.js アプリケーションの cloudfoundry での Blue/Green デプロイを自動化するツールはありますか? Cloudfoundry gradle プラグイン ( https://github.com/cloudfoundry/cf-java-client/tree/master/cloudfoundry-gradle-plugin ) を試しましたが、存在しない jar/war ファイルを含むファイル パラメーターが必要ですノードアプリ。Cloudfoundry でノード アプリのブルー/グリーン デプロイをどのように自動化しますか?

Blue/Green デプロイに関するこの記事を調べた後、さらにグーグルでカナリア リリースに関するこの記事を紹介されました。私はこのあいまいさを持っています: データベースはどうなりますか? それらをどのように同期させるべきですか？私は2つの可能なシナリオを念頭に置いています:

• 青がアクティブなときに環境ごとに 1 つずつ (緑と青) 2 つの別個のデータベースがあると想像してください
  。新しいレコードがそのデータベースに挿入され
  、トリガーのようなメカニズム (またはその他のメカニズム) を提供しない限り、緑はこれらの変更を認識しません。グリーンデータベースを更新します。
• 
  2 番目のシナリオは、2 つの環境間で下位互換性のあるデータベースを共有することを示唆していますが、データベースを扱う場合、下位互換性はそれほど簡単ではありません
  。アプリケーションを公開する前に、データベースの変更を公開する必要があります。

3 番目のシナリオとして、メインの Blue/Green デプロイメント内のデータベースに Blue/Green デプロイメントを実装する場合があります。

より良い解決策は何だと思いますか、またその理由は何ですか? 他のプラクティスやよく知られているパターンを提案しますか?

ありがとうございました

Spring Cloud を使用したマイクロサービスの開発中に、外部からマイクロサービスへの接続、および別のマイクロサービスに接続する必要があるマイクロサービスのプロキシとして Zuul の使用を開始しました。

しばらくして、Zuul はエッジ サービス (外部からマイクロサービスへのトラフィックのプロキシのみ) として設計されており、マイクロサービス間通信には使用すべきではないという結論に達しました。特に、Spring Cloud が eureka を使用して別のサービスに直接 (潜在的に負荷分散された) 接続を行うことを推奨している方法は、すべての間に Zuul を配置することに反対しました。

もちろん、すべてが期待どおりにうまく機能します (Spring Cloud では常にそうです) が、このセットアップで特定のユースケースを実行する方法についてはわかりません。

マイクロサービスの新しいバージョンをデプロイするときは、古いバージョンと新しいバージョンでブルー/グリーン デプロイを行いたいと考えています。ただし、マイクロサービス間に Zuul がないため、2 つの個別のサービス間の通信は、eureka から削除されるまで古いバージョンに進みます。

私たちはこれをどのように達成できるかを考えています。下の図では、オプションと思われるものを描きました。

図の最初の部分では、Zuul が eureka を呼び出してレジストリを取得し、ルートを作成します。また、サービス 1 は、レジストリを取得してサービス 2 にルーティングするために eureka を呼び出しています。サービス 2 は eureka レジストリにあるため、ルーティングは正常に行われます。

図の 2 番目の部分では、サービス 2 (サービス 2.1) の更新がデプロイされています。これは eureka にも登録され、サービス 1 がサービス 2 とサービス 2.1 の両方にルーティングされるようになります。これは、Blue/Green デプロイメントでは望ましくありません。

3 番目の部分では、この問題に対する潜在的な解決策が、この目的のためだけにデプロイされた eureka の別のインスタンスとともに紹介されます。このインスタンスはピア対応ではなく、最初の eureka インスタンスと同期しません。最初のインスタンスとは対照的に、このインスタンスの唯一の目的は、Blue/Green デプロイを容易にすることです。サービス 2.1 は 2 番目の eureka インスタンスに登録し、サービス 1 の構成は変更されて、最初からではなく 2 番目の eureka インスタンスからレジストリを取得します。

私たちが直面している主な問題は、これが実行可能な解決策であるかどうかです。Zuul のルーティングの柔軟性は、このシナリオにはない大きなプラスです。すべてのサービス間呼び出しを Zuul 経由でルーティングすることに戻すべきでしょうか、それともより適切な別のソリューション (おそらく何らかのリボン構成) がありますか? それとも、2 番目の eureka インスタンスは、このタイプの展開に最適なソリューションですか?

どんなフィードバックでも大歓迎です。

よろしく、アンドレアス