CloudFrontを使用したBlue / Greenデプロイ
CloudFront を使用してBlue/Greenデプロイメントを行う方法を探しています。
あるCloudFrontディストリビューションから別のディストリビューションに移動するための良い解決策はありますか？それとも、誰もが本当に自分のディストリビューションを作成してから、二度とそれに触れることはありませんか？
私のCloudFrontディストリビューションは、静的コンテンツ（javascriptなど）の1つのS3 Origin と、AWS ELBを指すカスタムOriginで構成されています。
CloudFrontに変更はありません
通常の状況では、CloudFrontディストリビューションに変更を加えることはありません。 S3の静的コンテンツファイルの名前を変更してS3オリジンの静的コンテンツをバージョン管理し、Elastic Load Balancer（ELB）の下でEC2インスタンスにローリングデプロイを行います。ただし、CloudFrontディストリビューション自体をテストして変更する必要がある場合や、環境に十分な変更を加えて、新しい環境の新しいELBを指す必要がある場合があります。
2つのCloudFrontディストリビューション
私が試みた最初のオプションは、2つの個別のCloudFront Web Distributions を使用することでした。1つは現在の（A）環境用で、もう1つは新しい（B）環境用です。 Route53 重み付けルーティングポリシー を使用しようとしましたが、www.domain.com Route53レコードに2つのレコードを追加しました。1つは重み1のCloudFrontディストリビューションAを指し、もう1つはCloudFrontディストリビューションBを指します。ウェイトAが0です。プランは、ディストリビューションAからディストリビューションBに移動するときにウェイトを変更することになります。ただし、www.domain.comを持つことができるのは一度に1つのCloudFrontディストリビューションのみです 代替ドメイン名（CNAME） 登録するか、次のエラーが発生します。
com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: ef84a5f0-44e7-11e5-9315-0ba167bb108a)
1つのCloudFrontディストリビューション
2番目のオプションは、1つのCloudFrontウェブディストリビューションを保持することです。 AとBの両方の環境を指すS3とカスタムのオリジンがあり、ある環境から別の環境に移動したいときに、CloudFront Cache Behavior を更新して、他のオリジンを指すようにしますこれらの更新には15〜60分かかるため、これは非常に厄介です。更新の進行状況を確認できず、変更の性質によっては CloudFront Invalidation でフォローアップする必要がある場合があります。古いコンテンツのキャッシュされたコンテンツを新しいコンテンツとともに提供していません。
アドバイスありがとうございます！
2つのCloudfrontディストリビューション
AWSでは、同じAWSアカウントのワイルドカード代替CNAME間のオーバーラップが許可されているため、次の方法で2つのCloudfrontディストリビューションを切り替えることができます。
- Prodディストリビューションの代替CNAMEとしてwww.domain.comを使用します1
- * .domain.comを製品版の代替CNAMEとして使用2
- CNAME DNS www.domain.comがディストリビューション1またはディストリビューション2（* .cloudfront.net）を指すようにします。
- もうコンテンツを提供したくないディストリビューションから代替CNAMEを削除します。
ただし、2つの異なる配布DNS（* .cloudfront.net）が同じEdgeノードを指す場合があります。つまり、コンテンツが提供される方法は、cloudfront.net CNAMEを、それを提供するEdgeノードと照合し、次に一致することです。ホスト名。この場合、両方のディストリビューションが同じEdgeノードを使用している場合（たとえば、Digで確認できます）、カットはクリーンではありません。
例えば両方のディストリビューションが1つ以上のエッジノードを共有する場合、CNAMEがすべてのエッジノードのディストリビューション1構成から削除されるまで、Alt CNAME www.domain.comを含むディストリビューション1は、より一般的な* .domain.comを含むディストリビューション2より優先されます。そのため、移行期間中に、1つのリクエストから取得したバージョンが他のリクエストと異なる場合があります。
ここのゲームの少し遅いが、これを探している他の人にとって。これはlambda @ Edgeを使用して実行できると思います。 A/Bテストに似ています。 https://docs.aws.Amazon.com/lambda/latest/dg/lambda-Edge.html 。ユーザーがURLをリクエストしたときにトリガーされるラムダ関数を実装できます。異なるオリジンまたはURLプレフィックスから青/緑のコンテンツを提供することを選択します。 Cookieの値によって、提供される展開が決まります。最初のリクエストが到着すると（Cookieなし）、Cookieはランダムに95％青、5％緑と設定します。
ヒップから撮影すると、クラウドフロントディストリビューション内でオリジンを切り替えるのにどのくらい時間がかかりますか？ 1）ELBの背後に新しいコードをデプロイし、ウォームアップします。2）古いOriginを削除しながら、このELBを新しいOriginとしてクラウドフロントディストリビューションに追加します。3）カットオーバーしたら、古いELBの背後にある古いコードを破棄します。
CloudFront更新またはDNS更新に関連する遅延を回避するために、ELBの背後にある自動スケールグループを交換できます。 1）新しいASGに新しいコードをデプロイし、ウォームアップします。2）この新しいASGで既存のELBを登録します。3）ELBから古いASGを登録解除します。4）カットオーバー後、古いASGを破棄します。
私はこのトピックについても調査しており、回避策があります（以下を参照）。
背景：
CloudFrontでは、ディストリビューション構成のCNAMEがアカウント全体で一意である必要があります。したがって、異なるディストリビューションへのDNSを介した青/緑の制御は機能しません。ワイルドカードを使用するハッキングが行われていますが、正しいファイルが提供される保証はありません。 DNSおよびCloudFrontを介して青/緑を制御することはできません。
さらに、CloudFront（CNAMEを含む）で構成を変更すると、変更がエッジサーバーに伝達されるまで15〜60分待機します。また、理想的なセットアップではありません。
回避策：
シングルページアプリの場合、トリックを実行する可能性があるこの構成：
- アプリのURL：app.mydomain.com/app
- S3構造：
- app /（ライブサイト）
- app2 /（それほどライブではないサイト）
次に、バケットを使用してファイルを提供するようにCloudFrontを構成します。この時点で、すべてがキャッシュ設定に影響します。 CloudFrontには時間がかかるため、S3オブジェクトにCacheControlヘッダーを設定します。 index.htmlの場合、5分、それ以外はすべて1日を使用します。切り替えるときに、S3ディレクトリ名を入れ替えます。 5分以内に、アプリはすべての目的と目的でライブになります。
すでに実行されているアプリの場合、ビルドバージョンがコードに組み込まれ、アプリのルートにビルド構成jsonファイルが含まれています。次に、アプリがjsonファイルをときどき要求し、バージョンを確認します。古い場合は、更新を要求します。
制限
ソークテストをうまく実行できません。 TTLを数時間または数日（必要に応じて）に増やすことができると思います。これにより、ローカルキャッシュの有効期限が切れたときにクライアントが新しいバージョンを確実に取得できるようになります。
このブログ投稿 で、著者はAWSドキュメントのコードに基づいて動作するLambda @ Edgeを介してabテストを実装します（これらの例はここで確認できます： https://docs.aws.Amazon .com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html ）。
基本的には、2つの異なるオリジンを指す単一のCloudfrontディストリビューションを作成します。次に、Lambda @ Edgeを使用してトラフィックをいずれかのOrigin（Cookies経由）に転送します。もちろん、Lambdaを介して、トラフィックの重み付けやフリップなどの他の機能を実装できます。さらにOriginとロジックを追加することも簡単です。 。