CodePipelineを用いたECS on EC2での Blue/Greenデプロイメント Future Tech Night #19 AWS 勉強会 渡邉 光

ECS初心者の方でデプロイメントの種類を知りたい方 ターゲット CodeBuildやCodeDeployで使用する設定ファイルの内容を知りたい方 パイプライン実行の流れを知りたい方

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

自己紹介 渡邉 光 Hikaru Watanabe フューチャーアーキテクト株式会社 ITコンサルティング事業部所属 Future歴3年目 趣味:筋トレ、テニス、バイク AWS歴: 1年半 資格:

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

ECSについて OS/ライブラリ ECS on EC2 仮想サーバ上でコンテナを動作 コンテナエージェント ホストのスケーリング コンテナ コンテナ Fargate コンテナ コンテナ ECS (Elastic Container Service) はAWSが提供するフルマネージドコンテナオーケストレーションサービスであり、 コンテナの起動停止や、デプロイ、スケーリング等を管理してくれる。 PJ要件上、ECS on EC2を採用。 ECS on Fargate サーバレスでコンテナを動作 ■特徴 ・カスタマイズできる ・OSアップデート等運用面が大変 ■特徴 ・インフラ運用管理からの解放 ・ホストにsshできない、カスタマイズできない AWSが管理 ユーザが管理

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

ECSデプロイメントの種類 ①Rolling Update ②Blue/Green ③外部デプロイ 機能 稼働中のタスクをグループごとに更新し、 新しいタスクを順にデプロイ 稼働している現環境と同じ台数の新環 境を作成し、最新のモジュールで動作 後、デプロイ サードパーティー制のデプロイコントローラ を使用したデプロイ メリット ・デプロイ時間が短い ・ロールバックが可能 (ECSデプロイメン トサーキットブレーカー) ・ロールバックが可能 ・トラフィックを切り替える前に新環境で アプリのテストが可能 ・jenkinsをサポートしているため、既存 のjenkins環境を使用することができる デメリット ・一時的に既存のコンテナに負荷が集 中する可能性がある ・ダウンタイムが発生する ・現環境と同等の新環境を用意するた め、リソース(EC2インスタンス、ENI)を 消費する ・独自実装のため、コストがかかる 制約 ・特になし ・Capacity Providerがサポート (2021/3/31) ・DEAMONスケジューリング戦略をサ ポートしていない ・サービスAuto Scalingがサポートされ ていない ・ALB/NLBのみ使用可能 ・DEAMONスケジューリング戦略をサ ポートしていない デプロイ時に最新モジュールで動作確認が行えること、問題発生時にはロールバックして、切り戻しが行える ことからCodeDeployを使用したBlue/Greenデプロイメントを採用

ローリングアップデート(1/5) ECSタスクを指定した数ずつ順番に更新していくデプロイ方法。 - デプロイ中に新旧バージョンが混在する状態になるため、アプリケーションの処理によっては予期せぬ動作が起きる。 - ECSデプロイメントサーキットブレイカーによるロールバックが可能に。(2020/12) desiredCount (タスクの必要数): 2 minimumHealthyPercent (デプロイ中のタスク数の下限をタスクの必要数の割合で表したもの) : 50 maximumPercent (デプロイ中のタスク数の上限をタスクの必要数の割合で表したもの) : 100 初期構成 Version 1 Listener Production Port HTTP:80 Target Group Target Group A ALB ELB ECS EC2 Version 1

ローリングアップデート(2/5) Version 1タスクの停止を行う。 minimumHealthyPercent (デプロイ中のタスク数の下限をタスクの必要数の割合で表したもの) を50%に 設定しているため、 ローリングアップデート中のタスク数の下限値はdesiredCount (タスクの必要数): 2の50% で1つになる。 STEP1 Listener Production Port HTTP:80 Target Group Target Group A ALB ELB ECS EC2 Version 1 Version 1タスクの停止

ローリングアップデート(3/5) STEP2 Listener Production Port HTTP:80 Target Group Target Group A ALB ELB ECS EC2 Version 1 Version 2タスクの起動 Version ２ Version 2のタスクを起動。 maximumPercent (デプロイ中のタスク数の上限をタスクの必要数の割合で表したもの) を100%に設定しているため、 ローリングアップデート中のタスク数の上限値はdesiredCount (タスクの必要数): 2の100%で2つになる。

ローリングアップデート(4/5) STEP3 Listener Production Port HTTP:80 Target Group Target Group A ALB ELB ECS EC2 Version 1タスクの停止 Version ２ 残りのVersion 1のタスクを停止。 minimumHealthyPercent (デプロイ中のタスク数の下限をタスクの必要数の割合で表したもの) を50%に 設定しているため、 ローリングアップデート中のタスク数の下限値はdesiredCount (タスクの必要数): 2の50% で1つになる。

ローリングアップデート(5/5) STEP4 Listener Production Port HTTP:80 Target Group Target Group A ALB ELB ECS EC2 Version 2 Version 2タスクの起動 Version ２ 最後のVersion 2のタスクを起動。 maximumPercent (デプロイ中のタスク数の上限をタスクの必要数の割合で表したもの) を100%に設定しているため、 ローリングアップデート中のタスク数の上限値はdesiredCount (タスクの必要数): 2の100%で2つになる。

Blue/Greenデプロイメント(1/6) Blue 稼働している現ECSタスクと同じ台数の新ECSタスクを作成し、最新のモジュールで動作確認後、デプロイ - Greenタスクに本番トラフィックを流す前にテストを実施することができる。 - ロールバックがボタン一つで動作可能 - Test用Listner、Target Groupが必要になる Listener Production Port HTTP:80 Target Group Target Group A Target Group B 初期構成 Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group

Blue/Greenデプロイメント(2/6) Blue ALBに対して、Production用のListnerとtarget groupとTest用のListnerとtarget groupが存在する。 通常は、Test用のListnerも本番用target groupに向いており、トラフィックを流すが、Blue/Greenデプロイ時に target Groupを切り替え、テスト環境に接続できるようにする。 Listener Production Port HTTP:80 Target Group Target Group A Target Group B STEP1 Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group

Blue/Greenデプロイメント(3/6) Blue CodeDeployにより、現ECSタスクと同じ台数の新ECSタスクを作成する。CodeDeployへロードバランサ情報、 タスク定義、コンテナ情報の提供は「appspec.yaml」を使用する。appspec.yamlの情報をもとに、新ECSタスクを デプロイします。 Listener Production Port HTTP:80 Target Group Target Group A Target Group B Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group Green Greenタスクの作成 STEP2

Blue/Greenデプロイメント(4/6) Blue CodeDeployがALBのTestポートのトラフィックを新ECSタスクに流れるようにListenerとTargetGroupの切り替えを 行う。新ECSタスクにトラフィックを切り替えるまでの待機時間を設定することができ、その時間にTestポートへアクセス することで新ECSタスクのテストを行うことができる。問題があればロールバック、なければトラフィックを切り替えることが できる。 Listener Production Port HTTP:80 Target Group Target Group A Target Group B Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group Green Target Groupの切り替え STEP3

Blue/Greenデプロイメント(5/6) Blue Testポートへアクセスして新ECSタスクに問題がなければ本番用Listenerを切り替え、新ECSタスクに本番トラフィックを 流します。「元のタスクセットの残す時間」を設定することができ、この時間は現タスクは残ります。本番トラフィックを切り替えた 後に不具合があった場合にロールバックすることが可能です。 Listener Production Port HTTP:80 Target Group Target Group A Target Group B Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group Green STEP3 本番用トラフィックの切り替え

Blue/Greenデプロイメント(6/6) 新ECSコンテナに問題がなければ、現ECSタスクを終了してBlue/Greenデプロイメント終了。 Listener Production Port HTTP:80 Target Group Target Group A Target Group B Test Port HTTP:8000 ALB ELB ECS EC2 CodeDeploy Deploy Group Green STEP3 現ECSタスクを終了

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

・ソースコード等はPJ都合上SVN管理 ・EC2のスケーリングの運用負荷を低減するためにcapacityproviderを使用 ・サービスオートスケーリングを有効化 ・ネットワークはAWSVPCモードを使用 ・サンプルアプリ（nginx + spring boot）で検証 パイプライン構成：前提

パイプライン構成 ECS CodeDeploy CodeBuild S3 Jenkinsサーバ Subversion trunk（検証稼働モジュール） docker ECR S3アップロードジョブ CodePipeline ①SVNチェックアウト ②ZIP化 application.zip Docker資材 デプロイスクリプト Dockerビルド実行 ③S3アップロード ECR Push Blue/Greenデプロイ Artifacts出力 S3 Artifacts ④ソースステージ ⑤ビルドステージ ⑥デプロイステージ Blue Green JekninsとCodepipelineを利用した実行環境・フローとする。 ➢ S3へのDockerfile等の資材のアップロードをトリガーにして、CodeBuild、CodeDeployを利用したBlue/Greenデプロイを行 う。

ソースステージ CodePipelineのソースステージにはS3を使用する。 ➢ 所属プロジェクトではソースコードはgit管理ではなく、SVNで管理しており、CodePipelineのソースステージでは、SVNはサ ポートされていないため。 ➢ Jenkinsサーバ上に必要な資材をSVNチェックアウトし、zip化してS3にアップロードする。 ➢ CodePipelineで使用するソースステージのS3バケットには、バージョニング設定が必要なので、設定を行う。 S3 Jenkinsサーバ Subversion trunk（検証稼働モジュール） docker ZIP化、S3アップロードジョブ ①SVNチェックアウト ②ZIP化 application.zip Docker資材 デプロイスクリプト ③S3アップロード ※要バージョニング ※要ZIP化

ソースステージ s3://test-bucket-source-for-technight application.zip taskdef.json appspec.yaml S3、zipファイル構成 nginx app buildspec.yaml CodeBuildで使用する「buildspec.yaml」、CodeDeployで使用する「appspec.yaml」はルートディレクトリに 配置しないとエラーになる。

ビルドステージ CodePipelineのビルドステージにはCodeBuildを使用する。 ➢ 所属プロジェクトでは以前、jenkinsサーバ上でdockerbuild、ECRプッシュを行っていたがdocker image等などで、 jenkinsサーバ上のディスク容量が切迫してしまったためCodebuildに移行。 S3 application.zip Docker資材 デプロイスクリプト Codebuild ECRログイン Dockerビルド実行 ECR Push Artifacts出力 S3 Artifacts ECR リポジトリ

デプロイステージ CodePipelineのデプロイステージには、CodeDeployを設定する。 ➢ Blue/greenデプロイ実行時には、blueタスクとgreenタスクが起動しタスク数が2倍になりENIのリソース切迫が懸念さ れることから、AWSVPCTrunkingを有効化 Blue ECS EC2 Green CodeDeploy Deploy Group

AWSVPC Trunking制限緩和申請 AWSVPC Trunking制限緩和設定 インスタンスタイプ デフォルト設定 制限緩和後 c5.large 2 10 c5.xlarge 3 20 c5.2xlarge 3 40 ECSでAWSVPCモードを利用する場合は、タスクごとにENIがアタッチされるため、EC2インスタンスで許容されて いるENI数に注意する必要があります。許容されているENI数を超えてしまった場合は、リソース不足でタスクが起 動しなくなるためAWSVPC Trunking制限緩和申請は行いましょう。

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

buildspec.yml ECRのログイン方法には get-login-passwordコマンドを使用する。 ➢ 以前は get-loginコマンドが使用されていたが、認証情報がshellのhistoryやログファイル等に残ってしまう。また、コマン ドレファレンスにも現在非推奨であることが記載されている。 https://docs.aws.amazon.com/cli/latest/reference/ecr/get-login.html ➢ --password-stdinオプションを使用すると、パスワードを標準入力から読み込ませることが可能。 IMAGE_TAGにはSVNリビジョン番号を使用。 ➢ ソースステージにgitリポジトリを使用している場合は、ソースコードのリポジトリのコミットIDが格納される環境変数 ${CODEBUILD_RESOLVED_SOURCE_VERSION}が利用できる。今回はSVNリポジトリを使用しているため、 Jenkinsサーバ上でdocker資材zip化 S3アップロードジョブ内で、最新リビジョン番号で書き換える。

ビルドステージでは、nginxとアプリケーションコンテナのdocker buildを実行。 イメージをpullする際にDockerHubの代わりに、ECR Publicを使用する。 ➢ CodeBuildでビルドする際に、イメージpull時に以下のエラーが発生。 ➢ 「error pulling image configuration: toomanyrequests: Too Many Requests. Please see https://docs.docker.com/docker-hub/download-rate-limit/」 ➢ Docker HubのDownload rate limit制限によって、Docker Hubのユーザ認証なしだとイメージpull制限回数に 引っかかってしまう。 ⇒ECR Publicを採用して回避。 buildspec.yml

Postビルドステージでは、nginxとアプリケーションコンテナのdocker imageをECRにPush。 taskdef.jsonを最新のイメージ、appspec.yamlをcodebuildに設定している環境変数で上書きする。 公式ドキュメントにはBlue/Greenデプロイメントには imageDetail.jsonを使用すると記載があるが、タスク定 義にコンテナを２つ使用しているため、sedコマンドでイメージURLを書き換える。 buildspec.yml

artifactsステージでは、最新のイメージや環境変数で最新化したtaskdef.json、appspec.yamlを指定して、 デプロイステージに出力アーティファクトとして引き継ぐ。 buildspec.yml

appspec.yaml は、CodeDeploy実行時に、自動的に最新のtaskdefinitionのARNに書き換わる。 「CapacityProviderStrategy」を、記載しないとBlue/Greenデプロイ時にCapacityProviderStrategyの 設定が消えてしまう。（タスクがAZごとにリバランスされず、偏ってしまった。） Blue/Greenデプロイメント実行時に、サービスAutoScalingがサポートされないため、CodeDeployの前後にサー ビスAutoScalingの停止と再開を行うlambdaを実行。

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

パイプラインの流れ 作成したCodePipeline全体像

パイプラインの流れ CodePipelineのソースステージに指定したS3バケットに対して、dockerfileやデプロイ資材をzip化した 「application.zip」がアップロード

パイプラインの流れ S3にapplication.zipがアップロードされたことで、パイプラインがスタート S3にアップロードされた時点でソースステージは成功し、ビルドステージがスタート

パイプラインの流れ buildspec.yamlに記載した処理がCodebuildで実行され、dockerのビルド、push処理、taskdef.json、 appspec.yamlの修正がエラーなく正常終了したらビルドステージは成功。 ビルドステージが成功したことで、デプロイステージのCodeDeployによるBlue/Greenデプロイが実行される。

パイプラインの流れ 置き換えタスクセットのデプロイで、GreenタスクをECSクラスタに作成する。 テストトラフィックルーティングのセットアップでテスト用のALBリスナー、ターゲットグループがGreenタスクに紐づく。

パイプラインの流れ テスト用リスナーにアクセスし、新しいアプリケーションがデプロイされていることを確認する。 本番用リスナーにアクセス テスト用リスナーにアクセス

テストが完了したら、CodeDeployの画面から「トラフィックの再ルーティング」をクリックして、本番トラフィックをGreen タスクに切り替える。 パイプラインの流れ

パイプラインの流れ ロールバックの必要がなければ、CodeDeployの画面から「元のタスクセットの終了」をクリックして、Blueタスクを完 全に削除する。ロールバックが必要なら「デプロイを停止してロールバック」をクリックする。

パイプラインの流れ デプロイが終了して、本番リスナーにアクセスしても、Greenタスクへアクセスされることを確認する。 本番用リスナーにアクセス

目次 ・自己紹介 ・ECSについて ・ECSデプロイメントの種類 ・パイプライン構成 ・各specファイルの解説 ・パイプラインの流れ ・まとめ

【登壇内容について】 ECS on EC2でのBlue/Greenデプロイメントについて解説させていただきました。 ECSのデプロイメント方法は非常に奥深く、ローリングアップデートとBlue/Greenデプロイメント以外にも - ecs-copilot - ecs-cli - ecspresso など様々なデプロイツールや方法がありますが、使ってことがないので検証してアウトプットしていきたいと思います。 【勉強会登壇してみて】 ・初めての外部勉強会登壇でめちゃめちゃ緊張しましたが、やりきることができてよかったです。（アウトプット楽しい。。。） ・改めて知識の整理をすることができた。 ・ちょっとでも今回の登壇内容が役に立っていただけると嬉しいです。 まとめ