複数のマイクロサービスを使用したBlue Greenの展開

Question

私は内部で呼び出している8つのスプリングブートマイクロサービスを持っています。他のマイクロサービスの呼び出し元のDNSは、各サービスのapplication.propertiesファイルで定義します。

と仮定、マイクロサービスAは、によって表す - > a.mydns.comとB-> b.mydns.comなど

したがって、基本的に各マイクロサービスはELB二HAプロキシから成る（で を配布2つのゾーン）と4つのAppサーバー（2つのゾーンに分散）があります。

現在、私は新しいグリーンサーバー（アプリケーションサーバーのみ）を作成し、ライブトラフィックをHAプロキシレベルから切り替えます。この場合、新しいバージョンのマイクロサービスがテストされている間に、ライブの顧客にも公開されます。

理想的には、アプローチは、、マイクロサービスごとにELBとHAのプロキシを含むサーバー構造全体を作成する必要がありますか？

しかし、どのように私はテストDNSでそれをテストするという難題に直面しますか？ ELBをテストDNSにマップできます。 それでは、外部のマイクロサービスDNSは、application.propertiesファイルの内側にハードコードされていますか？

このようなシナリオでは、どのようなアプローチが必要でしょうか？

Answer 1

理想的には、マイクロサービスごとにELBおよびHAプロキシを含むサーバー構造全体を作成するのが理想的です。

これは必ずしも真実ではありません。デプロイメント（展開戦略が何であっても、青緑またはカナリアン）は、コンシューマ（あなたの場合は他の7つのマイクロサービス）にtransparentである必要があります。つまり、他のサービスがやりとりするサービスのDNS名（またはIP）は同じままでなければなりません。 IMHO、マイクロサービスの導入の場合、あなたが契約の一部を維持している限り、生態系の他のサービスについて考える必要はありません。結局のところ、それは "マイクロ"サービスの全体的なポイントです。他のSOERが指摘しているように、他のサービスに変更を加えずに1つのマイクロサービスを配備できない場合、これはマイクロサービスではなく、httpを介して話す単なるモノです。

私はあなたがロード・バランサを介してコンテンツを提供している場合、私はELB

の後ろに、ここで

複数のEC2インスタンスを関連部分を引用しています。この記事 https://www.thoughtworks.com/insights/blog/implementing-blue-green-deployments-aws

を読むことをお勧めします、 Elastic IPを ELBに関連付けることができないため、同じ 技術が動作しません。このシナリオでは、現在の青い環境はEC2 インスタンスのプールであり、ロードバランサは要求をプール内の正常な インスタンスにルーティングします。同一の ロードバランサの背後で青緑色のスイッチを実行するには、プール全体を、新しいバージョンのソフトウェアを含む EC2インスタンスの新しいセットに置き換える必要があります。一連のAPI呼び出しを自動化するか、 自動スケーリンググループを使用するという2通りの方法があります。 があります。

Route53を使用する代わりに、あなたの ユーザーに弾性IPアドレスまたは長いELBのホスト名をさらすこれも

DNSリダイレクションのような他のクリエイティブの方法がありますが、あなたがのためにドメイン名を持つことができますすべての一般公開URL AWSの外では、DNSの CNAMEレコードを変更することで青緑色のスイッチを実行できます。 AWSでは、Route53を使用して同じ の結果を得ることができます。 Route53を使用すると、ホストされたゾーンを作成し、リソース レコードセットを定義して、ドメイン名システムにそのドメイン のトラフィックのルーティング方法を通知します。

他の質問にお答えします。

しかし、 をapplication.propertiesファイルにハードコードした外部マイクロサービスDNSはどうですか？

これを行う場合は、12factorアプリを読むことをお勧めします。特にconfig部分です。まだサービス検索オプションがない場合は、サービス検索オプションも参照してください。

私はあなたがここにいるのは、あまりマイクロサービスではないスパゲッティだと感じています。グリーンフィールドのプロジェクトでタイムラインの予算が許せば、インフラストラクチャー（1つの単語：Dockerizing）とともにアプリケーションをコンテナ化し、kubernetes、Docker swarm、AWS ECSなどのコンテナオーケストレーション技術を使用することをお勧めします（あなたがAWS上にいれば、すべての中で最も簡単です）、私はこれがこの質問の範囲外であることを知っています。

Answer 2

私はあなたのマイクロサービスを（スプリングブートで）簡単にドッキングし、ECS（Elastic Container Service）とELB（Elastic Load Balancer）をアプリケーションロードバランサで使用することをお勧めします。 （内部、またはインターネットに直面することができます）。

ECSとELBは、新しいバージョンを導入するときに、マイクロサービス/healthエンドポイントを使用します。

次に、スプ​​リングブートでより洗練されたHealthIndicatorを実装して、アプリケーションが正常であるかどうかを判断することができます（したがって、要求を受け取る準備ができています）。新しいアプリケーションが正常な場合にのみ、サービスに入れられ、古いアプリケーションはスリープ状態になります。

test environmentですべてのビジネスロジックをテストしてください.Dockerのおかげで、すべての環境で全く同じイメージが実行されているため、運用に展開するときにテストを実行する必要はありません。 （これはすでにテスト済みで、起動していれば、あなたはうまくいく）。

Answer 3

通常、B/Gテストでは、新しい機能に異なるdnsは使用しませんが、100番目ごとに新しい機能に送信されるか、特定の地域またはオフィスからのipsだけ新しい機能性など

AWSを使用していると仮定すると、ELBの前にELBのコンテキストベースルーティングを作成して、ルーティングルールをBまたはGのいずれかに定義できる必要があります。この場合、独立して機能する環境を分離する必要があります（ただし、同じDBを使用する可能性もあります）。

より複雑なルールの場合は、leanplumやomnitureなどのツールをスプリングブートアプリケーションの中で使用できます。このアプローチでは、古い機能と新しい機能をホストする1つの単一の環境があり、後で旧式のコードを削除します。

Answer 4

緑の配置のテストDNSエントリを使用すると、緑の配置が良好であることを完全に検証したときに、実際のDNSエントリに対してスワップアウトされるより簡単なルートになります。

だから私はこれで何を意味しています：

• a.mydns.com
• b.mydns.com

：

はあなたがあなたのライブの展開には、次のDNSエントリを持っていると述べています

各マイクロサービス展開でもテストDNSエントリが取得されるパターンを作成することをお勧めします。

• test.a.mydns.com
• test.b.mydns.com

あなたのマイクロサービスの "グリーン" バージョンを展開、あなたは（ELBを含む）すべてとマップを展開しますELBのCNAMEをRoute 53のテストDNSエントリに追加します。これは、緑色のバージョンをそのまま使用できますが、実際のアプリケーションでは使用されていないことを意味します。グリーンバージョンは独自のDNSエントリを持っているので、test.a.mydns.comドメインに対して完全なテストスイートを実行できます。

テストスイートが合格する場合に限り、a.mydns.comのCNAMEエントリを緑色の配備の一部として作成されたELBに置き換えます。つまり、既存のマイクロサービスは、DNSが伝播すると簡単にグリーン展開に着手します。問題がある場合は、DNS更新を古いCNAMEエントリに戻して、完全にロールバックします。

ここで少し調整が必要ですが、JenkinsやAWS CLIのようなものですべてを自動化できるはずです。