CodeDeploy でのデプロイ設定について解説します。
【AWS】CodeDeployとAuto Scaling＋ALBを組み合わせる環境の構築手順
【AWS】DevOps（CI/CD）の導入手順（Spring Tools、Git、CodePipeline、CodeCommit、CodeBuild、CodeDeploy）
【AWS】DevOps（CI/CD）の導入手順（CodePipeline、CodeCommit、CodeBuild、CodeDeploy）
【AWS】DevOps（CI/CD）の導入手順（Angular、Git、CodePipeline、CodeCommit、CodeBuild、CodeDeploy、Auto Scaling、ALB の組み合わせ）
CodeDeploy でデプロイエラーになった場合は以下の記事を参考にしてください。
【AWS】CodePipeline での CodeDeploy でのデプロイでエラーになった場合のトラブル対応手順
デプロイ設定の図解
Blackbelt の CodeDeploy の説明が分かりやすいです。
■デプロイ設定 EC2/オンプレミス
インプレースデプロイ（In-Place）All-At-Once Deployment
「インプレースデプロイ」且つ「AllAtOnce」デプロイは CodeDeploy のデフォルトの設定です。
一度に可能な限り多くのインスタンスへアプリケーションリビジョンをデプロイするよう試みます。
アプリケーションリビジョンが 1 つ以上のインスタンスにデプロイされる場合、デプロイ全体のステータスは Succeeded として表示されます。
アプリケーションリビジョンがいずれのインスタンスにもデプロイされない場合、デプロイ全体のステータスは Failed として表示されます。
9 つのインスタンスの例を使い、CodeDeployDefault.AllAtOnce は、一度に 9 つのインスタンスすべてにデプロイするよう試みます。
インスタンスへのデプロイが 1 つでも成功すると、デプロイ全体は成功します。
9 つすべてのインスタンスへのデプロイが失敗した場合に限り失敗します。
動作について
Auto Scalingのターゲットグループには2つのEC2インスタンスが設定されている状態です。
ここでソースコードを改修してデプロイをしてみます。
BuildとDeployの移行を「Enable」から「Disable」にして一旦パイプラインを止めます。
その後「Enable」にしてパイプラインを進めて動作を確認します。
AWS 管理画面より Deploy Status で動きを確認します。
■デプロイライフサイクルイベント
BlockTrafficのステータスでロードバランサーより両方のEC2インスタンスが登録を解除されます。
AWS CodeDeploy ユーザーガイド
BlockTraffic
このデプロイライフサイクルイベント中は、現在トラフィックの処理中であるインスタンスに対する
インターネットトラフィックのアクセスがブロックされます。
このイベントは CodeDeploy 用に予約されていて、スクリプトを実行するために使用することはできません。
このタイミングでロードバランサーのターゲットグループのEC2インスタンスのステータスを確認してみます。
2台のEC2インスタンスは両方とも「draining」の状態になっています。
draining はターゲットグループから EC2インスタンスの登録を解除する際の初期状態です。
つまり、現在登録を解除している最中ということになります。
登録解除の遅延タイムアウトの期限が切れると、ターゲットは unused 状態に移行します。
このステータスは、ロードバランサーはトラフィックを送らないので、当然サイトは見えない状態になります。
ただしすでにあるコネクションを許可をしてグレースフル（graceful）に登録を解除します。
つまり、既存のトラフィックは許可するけど、新規のトラフィックはブロックするということになります。
最終的に EC2 インスタンスが登録を解除されたら、ロードバランサーの下に何もEC2インスタンスが存在しないことになるので
サイトは閲覧できなくなります。
この状態でDeploy Status のイベントを確認するとまだ「BeforeBlockTraffic」か「BlockTraffic」の状態であることが多いです。
CodeDeployがロードバランサーからの情報を待っているからエベントの進みが遅れているように感じます。
この状態から「AllowTraffic」の状態になると、ようやくロードバランサーのターゲットグループにEC2インスタンスが登録されるようになります。
しばらくするとターゲットグループのEC2インスタンスのステータスが「healthy」になります。
この状態になるとサイトは復旧します。（再び使用できるようになります。）
ただし AllowTraffic のステータスは、BlockTraffic と同様、ロードバランサーに登録されてから「Successful」になるので
少々ステータスの変更に時間が掛かります。
この時間はヘルスチェックの設定に依存します。
インプレースデプロイ（In-Place）での All-At-Once Deployment はデプロイは一番早く終わります。
理由はすべての EC2 インスタンスを並行して一気に全部デプロイするからです。
シリアルではなくパラレル（並行）でデプロイされます。
スケールアウト（Scale Out）した場合
もし Auto Scaling グループがスケールアウトした場合はすぐに新しいEC2インスタンスにアプリケーションがデプロイされます。
Auto Scaling グループでスケールアウトをした場合はどうなるか？
Auto Scaling グループでスケールアウトをした場合はどうなるでしょうか？
CodeDeploy と Auto Scaling は連携されていて、Auto Scalling グループの設定でグループサイズを変更すると、自動的に EC2 インスタンスが起動し、アプリケーションもデプロイされます。
デプロイされるアプリケーションは直近で成功したアプリケーションのバージョンとなります。
注意点はAuto Scalling グループと Deploymento グループを1対1で合わせることです。
これが複数のグループと結びついているとコンフリクトが発生し「Unhealthy」になります。
手動でデプロイする必要はありません。
グループサイズのキャパシティの変更手順
「編集」ボタンをクリックします。
「グループサイズ」で以下のキャパシティを変更します。
3つに変更します。
グループサイズを変更すると自動的にインスタンスが起動しアプリケーションがデプロイされます。
ブルー/グリーンデプロイ（Blue/Greenデプロイ）手順
Auto Scaling とロードランサー環境での Blue-Green デプロイメントについて解説します。
■Blue/Greenデプロイの構成
上記構成を確認するとBlue/Greenデプロイメントは、一旦v1とv2の2セットを作ります。
例えば Auto Scaling グループで EC2インスタンスが3台のセットの構成の場合は、一旦 6台の EC2インスタンスが起動することになります。
そして V1 から v2 に切り替えて v1 のグループを終了させます。
IAM ロールの設定
最初に IAM ロールの設定をします。
CodeDeploy の Blue/Greenデプロイメントの場合は、以下の権限が必要になります。
■CodeDeploy の Blue/Green デプロイメントに必要なポリシー
|
{ |
■参考サイト
https://h2ik.co/2019/02/28/aws-codedeploy-blue-green/
================================================
This is what AWS Support came back with:
Hello,
Thank you for contacting Amazon Web Services Support. I understand that you are running into issues when using an AutoScaling Group (ASG) with a launch template for your CodeDeploy Blue/Green deployments. To clarify, launch templates are supported with Blue/Green deployments; however, there are additional permissions that are needed for the CodeDeploy role in order for this feature to work. When using launch templates the role must have the following permissions added:
- ec2:RunInstance
- ec2:CreateTags
- iam:PassRole
Currently, this information is missing from the AWS CodeDeploy documentation; there is an open feature request to update the documentation as well as to add these required permissions to the managed CodeDeploy policy so that users will not need to manually add these permissions. At the moment, this feature is still being reviewed so I do not have any timeline or ETA for this but at the very least, the documentation will be updated to reflect the extra permissions required for using launch templates.
================================================
Google翻訳
こんにちは、
アマゾンウェブサービスサポートにお問い合わせいただきありがとうございます。
CodeDeploy Blue / Greenデプロイメントの起動テンプレートでAutoScalingGroup（ASG）を使用すると、問題が発生することを理解しています。
明確にするために、起動テンプレートはBlue / Greenデプロイメントでサポートされています。
ただし、この機能を機能させるには、CodeDeployロールに必要な追加の権限があります。
起動テンプレートを使用する場合、ロールには次の権限が追加されている必要があります。
ec2：RunInstance
ec2：CreateTags
iam：PassRole
現在、この情報はAWSCodeDeployのドキュメントから欠落しています。
ドキュメントを更新し、これらの必要なアクセス許可をマネージドCodeDeployポリシーに追加して、ユーザーがこれらのアクセス許可を手動で追加する必要がないようにするためのオープン機能リクエストがあります。
現時点では、この機能はまだレビュー中であるため、このためのタイムラインやETAはありませんが、少なくとも、起動テンプレートの使用に必要な追加の権限を反映するようにドキュメントが更新されます。
================================================
つまり、起動テンプレートを使用する場合、CodeDeploy ロールに以下の 3つの権限が必要になります。
- ec2：RunInstance
- ec2：CreateTags
- iam：PassRole
新しいポリシーを作成します。
■CodeDeploy の Blue/Green デプロイメントに必要なポリシー
|
{ |
作成したポリシーを現在 CodeDeploy で利用している IAM ロールにアタッチします。
Blue/Greenデプロイメント設定手順
CodeDeploy のアプリケーションから「デプロイグループ」へ移動し「編集」ボタンをクリックします。
以下のように設定して下にスクロールします。
- デプロイタイプ ← Blue/Green を選択します。
- 環境設定 ← Amazon EC2 Auto Scaling グループの自動コピー
- Amazon EC2 Auto Scaling グループ ← 現在利用している Auto Scaling グループを選択します。
以下のように設定して下にスクロールします。
- デプロイ設定 ← CodeDeployDefault.AllAtOnce を選択します。
「変更の保存」ボタンをクリックします。
ブルー/グリーンデプロイ（Blue/Greenデプロイ）の流れ
再度Blue/Greenデプロイを試してみます。
もう1セット分の EC2インスタンスが起動します。
Auto Scaling グループがもう1セットできます。
この間サイトをアクセスするとタイミングによっては既存バージョンの場合と新規バージョンの場合の画面が表示されます。
ここで新旧バージョンの動作確認ができます。
ステップ3の状態になるとブルー（オリジナル）とグリーン（置換）が 2 と 2 の状態になります。
新バージョンのデプロイが進行中であることが分かります。
ステップ4の状態になるとグリーン（置換）の方が 2でブルー（オリジナル）が 0になります。
ブルー/グリーンデプロイ（Blue/Greenデプロイ）で失敗した場合どうなるか
上記のブルー/グリーンデプロイ（Blue/Greenデプロイ）で失敗した場合どうなりますでしょうか？
ステップ1で最初に Auto Scaling グループが作成され、グリーン（置換）がデプロイされます。
ステップ2で EC2インスタンスが起動され、アプリケーションがデプロイされますが、ここでエラーになった場合はFailedでデプロイが終了されます。
ステップ2で終了し、ステップ3まで行かないので、ブルー（オリジナル）のままです。
つまりサイトにとっては何の影響もないことになりまる。
また、ロールバックも行われないので、その影響もありません。
CodePipelineはFailedで完了します。
コメント