こんにちは。
弁護士ドットコムでSREをやっている @t2ynkmr です。
この記事は 弁護士ドットコム Advent Calendar 2020 の9日目の記事です。
TL;DR
- CodePipeline を使った ECS への自動デプロイをやめた
- CodePipeline のデプロイステージで行われている処理の一部をビルドステージで実行させた
- CodeDeploy にリビジョン登録する際にコミットハッシュをタグにしたイメージを紐付けることで latest タグ運用から卒業した
- いろいろやったけど1から作れるなら ecspresso でやるのがよさげ
はじめに
みなさん、ECS で動かすコンテナは latest タグを使わずにに運用していますか？
去年の7月には ECR でイミュータブルなコンテナタグがサポートされ、クラスメソッドさんのブロクでも ECS デプロイのアンチパターンとして紹介されています。
私が主に担当しているクラウドサインというサービスでもばっちり latest タグ運用をやってました…
これは ECS のデプロイ方法の見直しに合わせて latest タグ運用を脱却し、コミットハッシュをタグに使ったイメージを指定してデプロイできるようにした記録です。
ECS デプロイの見直し
クラウドサインではサービスのコンテナ化と ECS への移行を進めています。
その際に terraform で作成した構成は以下のようになっています。
リポジトリへの操作をトリガーにして CloudWatchEvents で CodePipeline を動かして latest タグでイメージを更新し ECS へのデプロイまで自動で行うものでした。
これはこれで便利だったのですが ECS を運用していく中でエンジニアから要望が上がってきました
- 今動いているイメージがどの時点でビルドされたのか把握したい
- エラーが発生したらなるべく早く切り戻したいので過去のコミットハッシュを指定したデプロイを行いたい
- revert コミットでの対応ではエラー発生時間が伸びてしまう
- 任意のタイミングでデプロイをしたい
ごもっともです。みんなえらい。
ECS のデプロイ方法を見直してこれらの要望を実現できないか検討することにしました。
やること/やらないこと
デプロイの見直しにあたりまずは状況を整理します。
やること
要望にもあったとおり以下ですね。
- デプロイされたイメージがいつの時点でビルドされたものか表示
- 過去のコミットハッシュを指定したデプロイ
- 任意のタイミングでデプロイ
やらないこと
やらないことも整理しておきます。
- コンテナオーケストレーションサービスの変更
- k8s なら…等も頭をよぎりましたが、解決したい課題に対して影響範囲が大きいので ECS のままいい感じにできる方法を模索します
- ECS のデプロイタイプの変更
- ECS ではデプロイタイプとしてローリングデプロイではなく Blue/Green デプロイを利用しています。これはこれでツラミがあるのですがデプロイタイプの見直しも今回は行いません
- 3rd Party のデプロイツールの利用
- 既存の EC2 のデプロイにて CodeDeploy を利用しています。デプロイツールが乱立するのもツラいのでひとまずは既存の資産を活かせる形での変更を模索します
見直しの前に引き続き既存のデプロイでやっている処理を整理します。
既存のデプロイについて
EC2
EC2 へのデプロイはリポジトリへの操作をトリガーにして CI で CodeDeploy にリビジョンを登録しています。
リビジョンの description に git show HEAD --oneline | head -n1 を登録することで、リビジョンを一覧表示した際にコミットハッシュで絞り込めるようにしてあります。
デプロイをする際は slack から bot 経由で CodeDeploy を操作して登録されたリビジョンの確認やデプロイを実施しています。
リビジョンの表示によりデプロイされたアプリケーションがいつビルドされたのか確認可能です。
操作感的にはこれと同様な仕組みができればエンジニアが新しいデプロイ方法を学ぶことなくやりたいことが実現できそうです。
ECS
前述したとおり ECS への自動デプロイはリポジトリへの操作をトリガーにして CodePipeline 経由で実行されます。
ビルドステージで CodeBuild によるイメージのビルド、デプロイステージで CodeDeploy によるデプロイが行われています。
デプロイの見直し方針
CodePipeline が実行しているデプロイステージを読み解いてやれば EC2 へのデプロイのように任意のタイミングでのデプロイが実現できそうです。
デプロイステージで行われる CodeDeploy を使った Blue/Green デプロイの処理をもう少し細かく見てみます。
調査
デプロイステージの設定としてアプリケーション名やデプロイメントグループだけでなく以下を設定しています。
- ECS のタスク定義
- CodeDeploy の AppSpec ファイル
CodeDeploy にこれらを渡して create-deployment で終わり＼(^o^)／
と思いきやそんなに簡単ではありませんでした…。
create-deployment のオプションではリビジョンが指定可能ですがタスク定義は指定できません。
ECS の場合 appspec.yml がリビジョンにあたることは記載されていますが、単純にこの2つを設定することは難しそうです。
デプロイステージで設定されるタスク定義と AppSpec で何が行われているのか確認してみます。
デプロイステージに設定するタスク定義
CodePipeline のチュートリアルを確認するとプレースホルダーを含んだタスク定義を設定しています。
{
"executionRoleArn": "arn:aws:iam::account_ID:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"name": "sample-website",
"image": "<IMAGE1_NAME>",
"essential": true,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
]
}
],
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"cpu": "256",
"memory": "512",
"family": "ecs-demo"
}
プレースホルダーを利用したタスク定義を設定することで、イメージ名を動的に更新したタスク定義を生成し、タスク定義を更新（新しいリビジョンを発行）しているようです。
ちなみにプレースホルダーは imageDetail.json というファイルに記載されたイメージ名が参照されます。
自動的に作成される場合もありますが、ビルドステージでイメージをビルドするような場合には作成してやる必要があります。 1
デプロイステージに設定する AppSpec
同じく CodePipeline のチュートリアルを確認するとこちらもプレースホルダーを含んだ AppSpec ファイルを設定しています。
version: 0.0
Resources:
- TargetService:
Type: AWS::ECS::Service
Properties:
TaskDefinition: <TASK_DEFINITION>
LoadBalancerInfo:
ContainerName: "sample-website"
ContainerPort: 80
CodeDeploy で ECS へデプロイする場合は AppSpec ファイルがリビジョンとして登録されます。
プレースホルダーを利用して前述の json を利用して発行されたリビジョンのタスク定義の ARN を動的に設定して、CodeDeploy が利用するリビジョンとして登録しているようです。
デプロイステージでの処理
デプロイステージでは CodeDeploy の実行だけではなく CodePipeline により以下のような CodeDeploy 実行前段階の処理が行われていました。
- ビルドしたイメージを指定したタスク定義の更新
- タスク定義を反映した AppSpec の作成
- CodeDeploy へのリビジョン登録
そもそもこのデプロイステージでの設定を適切に実施してやることでコミットハッシュをタグにしたイメージをデプロイすることができます。
デプロイされたイメージがいつの時点でビルドされたものか表示 という部分は解決しそうです。
見直し方針策定
デプロイステージの仕組みを準備してやることで CodeDeploy でのデプロイ前の状態を再現できることがわかりました。
次のような方針でやりたいことが実現できそうです。
- デプロイタイミングの制御のために CodePipeline でデプロイステージは設定しない
- デプロイステージで行われている CodeDeploy の前段階の処理はビルドステージで設定
- デプロイステージで行われている CodeDeploy 自体の処理は既存の EC2 のデプロイ処理を使いまわす
具体的には以下の様に設定します。
- リポジトリへの操作をトリガーに CodePipeline のソースステージが実行される
- CodePipeline のビルドステージで CodeBuild を実行する
- コミットハッシュをタグにしたイメージをビルドして ECR にプッシュ
- コミットハッシュをタグにしたイメージを参照するタスク定義を作成して ECS に登録
- ECS に登録したタスク定義を利用する appspec.yml をリビジョンとして CodeDeploy に登録
- CodePipeline 完了後に slackbot から CodeDeploy の情報を参照してデプロイを行う
これで複数人がリポジトリを更新していても 1〜2 の処理が自動で行われ、最終的に任意のタイミングでデプロイできるようになりそうです。
デプロイ見直し結果
見直し方針を踏まえて CodePipeline のステージ設定を変更し以下のような構成になりました。
ビルドステージまでで CodeBuild でのイメージビルド、CodeDeploy へのリビジョン登録のみ実施し、デプロイ自体は CodeDeploy に登録されたリビジョンの情報を利用して任意のタイミングで行います。
設定としては buildspec.yml を以下の様に更新してアプリケーションのリポジトリに登録しました。
(前提として ECS のクラスター、サービスが作成されていること（タスク定義が存在していること）が必要です)
version: 0.2
env:
variables:
AWS_DEFAULT_REGION: ap-northeast-1
AWS_ECR_URL: 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com
CONTAINER_NAME: app
CONTAINER_PORT: 9999
DOCKER_BUILDKIT: 1
phases:
pre_build:
commands:
- COMMIT_SHORT_SHA=$(git rev-parse --short HEAD)
- DESC_REVISION=$(git show HEAD --oneline | head -n1)
- aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin 426005763013.dkr.ecr.ap-northeast-1.amazonaws.com
build:
commands:
# コミットハッシュをタグにしたイメージをビルドして ECR にプッシュ
- docker build -t ${AWS_ECR_URL}/${CONTAINER_NAME}:${COMMIT_SHORT_SHA} .
- docker push ${AWS_ECR_URL}/${CONTAINER_NAME}:${COMMIT_SHORT_SHA}
post_build:
commands:
# コミットハッシュをタグにしたイメージを利用するタスク定義を作成して ECS に登録
## タスク定義を取得
- |-
aws ecs describe-task-definition \
--task-definition ${CONTAINER_NAME} | \
jq '.taskDefinition | { family: .family, taskRoleArn: .taskRoleArn, executionRoleArn: .executionRoleArn, networkMode: .networkMode, containerDefinitions: .containerDefinitions, volumes: .volumes, requiresCompatibilities: .requiresCompatibilities, cpu: .cpu, memory: .memory }' \
> ./taskdef.json
- sed -i -e "s#\"${AWS_ECR_URL}/${CONTAINER_NAME}:.*\"#\"${AWS_ECR_URL}/${CONTAINER_NAME}:${COMMIT_SHORT_SHA}\"#" ./taskdef.json
## タスク定義を更新
- aws ecs register-task-definition --cli-input-json file://$(pwd)/taskdef.json
# ECS に登録したタスク定義を利用する appspec.yml をリビジョンとして CodeDeploy に登録
## タスク定義の ARN を取得
- |-
TASK_DEFINITION_ARN=$(aws ecs describe-task-definition \
--task-definition ${CONTAINER_NAME} | \
jq -r '.taskDefinition.taskDefinitionArn')
## CodeDeploy のリビジョンを作成する
- |-
cat << EOF > revision.json
{
"applicationName": "${CONTAINER_NAME}",
"description": "${DESC_REVISION}",
"revision": {
"revisionType": "AppSpecContent",
"appSpecContent": {
"content": "{\"version\": 1,\"Resources\": [{\"TargetService\": {\"Type\": \"AWS::ECS::Service\",\"Properties\": {\"TaskDefinition\": \"${TASK_DEFINITION_ARN}\",\"LoadBalancerInfo\": {\"ContainerName\": \"${CONTAINER_NAME}\",\"ContainerPort\": ${CONTAINER_PORT}},\"PlatformVersion\": \"1.4.0\"}}}]}"
}
}
}
EOF
- aws deploy register-application-revision --cli-input-json file://$(pwd)/revision.json
これでリポジトリへの操作をトリガーに CodeDeploy にコミットハッシュ単位でリビジョンが登録されます。
あとは slack から呼び出す bot の処理に ECS のアプリケーション情報を追加してやれば既存のデプロイ処理と同様にリビジョンを呼び出してデプロイできそうです。
bot 自体の説明は割愛しますがこのような感じで動いています。
-
デプロイできるリビジョンの確認
CodeDeploy の list-application-revisions と get-application-revision で取得した情報をregisterTimeでソートして整形して表示しています。 -
デプロイしたリビジョンの確認
CodeDeploy のlist-application-revisionsとget-application-revisionで取得した情報をlastUsedTimeでソートして整形して表示しています。 -
リビジョンを指定したデプロイ
リビジョンのlastUsedTimeが更新されました
いい感じです。これでやりたかったことが実現できました。
開発者もデプロイへの抵抗を感じることがなく、作業できそうです。
おわりに
回りくどいことをしたような気もしていますが、既存のデプロイと使用感をあわせて ECS にもデプロイできるようにできたので開発者フレンドリーな方法を採用できたのではないでしょうか。
また既存のデプロイへの影響を考慮し 3rdParty ツールを使わないという決意の元で実施したのですが、調べた限りでは ecspresso を利用すれば同じことがもっとシンプルにできそうでした。
1からデプロイの仕組みをつくるならこっちかな…。
ともあれAWS上のサービスを利用してデプロイしたい状況とコンテナのタグ運用の見直しの参考になれば幸いです。
明日は弁護士ドットコムの技術顧問である @koriym さんです。お楽しみに 