ECSサービスだけじゃない！ecschedule 管理されているECSタスク定義管理における ecspresso の使いどころ

ECSサービスだけじゃない！ ecschedule 管理されているECSタスク定義管理における ecspresso の使いどころ 2023.08.08 JAWS-UG コンテナ支部 #24 ecspresso MeetUp Kei IWASAKI (@laugh_k)

お前誰よ Kei IWASAKI 𝕏: @laugh_k GitHub: @laughk Fediverse: @laughk@fedibird.com @laughk@misskey.io Bluesky: @laughk.bsky.app コネヒト株式会社開発部プラットフォーム グループ インフラエンジニア

• https://x.com/laugh_k
• https://github.com/laughk
• https://fedibird.com/@laughk
• https://misskey.io/@laughk
• https://bsky.app/profile/laughk.bsky.social

以前一件バグ修正のPRを送ったことがあります

CM: コネヒトの紹介

https://connehito.com/

• https://connehito.com/

ECSサービスだけじゃない！ ecschedule 管理されているECSタスク定義管理における ecspresso の使いどころ 2023.08.08 JAWS-UG コンテナ支部 #24 ecspresso MeetUp 2023.08.08 Kei IWASAKI (@laugh_k)

ecspresso x ecschedule の話です

コネヒトでは定期実行バッチで ecschedule を使っています 参考資料: ECS Scheduled Task 上の定期実行バッチを ecschedule で GitOps 化した話 - Speaker Deck

• https://speakerdeck.com/laughk/a-story-about-a-scheduled-execution-batch-on-the-ecs-scheduled-task-converted-to-gitops-with-ecschedule

元々は定期実行バッチの ECSタスク定義の管理は生のJSON + awscli だった ECS Scheduled Task 上の定期実行バッチを ecschedule で GitOps 化した話 Speaker Deck

• https://speakerdeck.com/laughk/a-story-about-a-scheduled-execution-batch-on-the-ecs-scheduled-task-converted-to-gitops-with-ecschedule?slide=24

元々は定期実行バッチの ECSタスク定義の管理は生のJSON + awscli だった ecschedule 導入以前はコンパネから直接編集していた（Docker image タグの release を見る運用だったのも影響あり） Webアプリケーションのデプロイは ecs-deploy だったため、バッチに限らず社内 にECSタスク定義をコード管理している場所もなかった とはいえ何も無いのは困るので、ひとまず生のJSONを管理し、変更があれば awscli で register していた

元々は定期実行バッチの ECSタスク定義の管理は生のJSON + awscli だった

バッチ用共通タスク定義の更新

EC2の場合 aws ecs register-task-definition \ --requires-compatibilities EC2 \ --cli-input-json fileb://task-definition.json Fargateの場合 aws ecs register-task-definition \ --requires-compatibilities FARGATE \ --network-mode awsvpc \ --cli-input-json fileb://task-definition.json

正直タスク定義の更新はそこまでテコ入れしていない 状況であった

まあECSタスク定義の更新はそう頻繁には発生しない から大丈夫だろう...

そんな風に考えていた時期が僕にもありました

ecscheduleを運用開始するとECSタスク定義の管理が問題に 基本的にはreleaseタグのコンテナイメージを参照しているので更新は必須ではな い想定 ただし「環境変数を追加したのに動かない」→ 「バッチだけECSタスク定義を更新 していなかった」というパターンが思いのほか多く発生

ecscheduleを運用開始するとECSタスク定義の管理が問題に

そんな状況の中、しばらくの間だましだましの運用が 続いていた

転機

ecspresso が導入された ecschedule 導入から1年半後に ecspresso も本格導入 GitHub Actions & ecspresso を用いたデプロイフローの改善 - コネヒト開発者ブロ グ

• https://tech.connehito.com/entry/2022/09/13/094045

ecspresso が導入されたあとの話 ecspresso が導入されてECS関連のインフラリソースがコード管理されていること が当たり前になった デプロイやロールバックの仕組みにコードでコントリビュートしやすくなった

つまりこうなった

せっかくなので定期実行バッチのタスク定義も ecspresso に任せ ていくことを考えた ECSサービスのデプロイとは違うので「ecspresso deploy」「ecspresso rollback」ではいけない タスク定義の更新だけなら「ecspresso register」があるのでそれで行けそう デプロイ後に問題が発生したときのロールバックは「ecspresso deregister -revision='latest'」でOK ecschedule のルール設定を最新リビジョンを利用するようにしている事が前提 ECSタスク定義内容の Webアプリとの微妙な違いは jsonnet で吸収

バッチ用ECSタスク定義の更新: ecspresso register $ ecspresso register デプロイのたびに実行しておくけばOK EventBridge では常にタスク定義の最新のリビジョンを見ておく

バッチ用ECSタスク定義のロールバック: ecspresso deregister $ ecspresso deregister --revision="latest" ECSタスク定義の最新リビジョンの無効化（--revision="latest"） 実行すると最新リビジョンが一つ前にもどる EventBridge が参照しているリビジョンも自動的に一つ戻る

ロールバックのイメージ

実はfujiwaraさんにサポー トいただいていました しかも Issue を上げる前に --revision='latest' を実装し ていただいた

ECSタスク定義内容の Webアプリとの微妙な違いは jsonnet で吸 収 Webアプリ $ ecspresso --ext-str type=webapp deploy --config config.yaml 定期実行バッチ $ ecspresso --ext-str type=batch register --config config.yaml

最終的に出来た状況

ecschedule 用の ECS タスク管理も ecspresso でや ってみて嬉しいこと ECSタスク定義の設定が YAML/JSON/jsonnet で本当に設定が完結する ECSタスク定義のライフサイクルをWebアプリケーション等と揃えられるので、更 新漏れもない 安定したロールバックの実現

まとめ 定期実行バッチで ECS Scheduled Task を使っている場合は ecschedule はとても 便利 ecschedule が対応していないECSタスク定義関連も ecspresso にお任せできる エスプレスタック便利