CloudFrontを使用したブルー/グリーン展開

CloudFrontでブルー/グリーン展開を行う方法を探しています。

あるCloudFrontディストリビューションから別のCloudFrontディストリビューションに移行するための優れたソリューションを持っている人はいますか？

私のCloudFrontディストリビューションは、静的コンテンツ（javascriptなど）の1つのS3 オリジンと、AWS ELBを指すカスタムオリジンで構成されています。

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つは重みが0のCloudFrontディストリビューションBを指します。ディストリビューションAからディストリビューションBに移動するときに重みを変更する計画です。ただし、www.domain.com 代替ドメイン名（CNAME）を登録できるCloudFrontディストリビューションは一度に1つのみです。そうしないと、次のエラーが発生します。

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 キャッシュ動作を他のオリジンを指すように更新します。これらの更新には15〜60分かかり、更新の進行状況が見えないため、これは非常に面倒です。変更の性質によっては、キャッシュされたコンテンツを提供しないようにCloudFront無効化を追跡する必要がある場合があります新しいコンテンツとともに古い環境から。

助言ありがとう！

2つのCloudfrontディストリビューション

AWSでは、同じAWSアカウントのワイルドカード代替CNAME間のオーバーラップが許可されているため、次の方法で2つのCloudfrontディストリビューションを切り替えることができます。

• 製品の配布の代替CNAMEとしてwww.domain.comを使用します1
• 製品配布2の代替CNAMEとして* .domain.comを使用します
• CNAME DNS www.domain.comをディストリビューション1またはディストリビューション2に向けます（* .cloudfront.net）。
• コンテンツを提供したくない代替CNAMEをディストリビューションから削除します。

ただし、2つの異なるディストリビューションDNS（* .cloudfront.net）は同じエッジノードを指す場合があります。つまり、コンテンツの配信方法は、cloudfront.net CNAMEをそれを提供するエッジノードに一致させてから、ホスト名。この場合、両方の分布が同じエッジノードを使用している場合（たとえばで確認できますdig）、カットはクリーンになりません。

たとえば、両方のディストリビューションが1つ以上のエッジノードを共有する場合、Alt CNAME www.domain.comのディストリビューション1は、すべてのエッジノードのディストリビューション1構成からCNAMEが削除されるまで、より一般的な* .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）古いELBを削除しながら、このELBをクラウドフロントディストリビューションに新しいオリジンとして追加します。

CloudFront更新またはDNS更新に関連する遅延から逃れるために、ELBの背後で自動スケールグループを交換できます。1）新しいASGに新しいコードをデプロイし、ウォームアップします2）既存のELBをこの新しいASGに登録します3）古いASGをELBから登録解除します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ファイルを要求し、バージョンを確認します。バージョンが古い場合は、更新を求めます。

制限事項

浸漬テストを非常にうまく実行することはできません。index.htmlのTTLを（必要に応じて）数時間または数日まで増やすことができると思います。これにより、ローカルキャッシュの有効期限が切れたときにクライアントが新しいバージョンを取得できるようになります。

で、このブログの投稿：ABはAWSのドキュメント内のコードのオフ作業エッジ@ラムダを経由してテストする作者の実装を（あなたはここでその例を見ることができますhttps://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda- examples.html）。

基本的には、2つの異なるオリジンを指す単一のCloudfrontディストリビューションを作成します。次に、Lambda @ Edgeを使用して、トラフィックをいずれかのオリジンに（Cookieを介して）転送できます。もちろん、トラフィックの重み付けや反転など、Lambdaを介して他のことを実装することもできます。 。