jaws.pdf

Transcript

1. インフラとソースコードの管理境界 を意識したECSデプロイパイプライン の構築 2026年4月 株式会社ギフティ 大類 有紀子
2. ©2019 giftee Inc. all rights reserved 2 自己紹介 ⚫ 名前: 大類 (おおるい) 有紀子 ⚫ 所属: 株式会社ギフティ 技術本部 ⚫ 職種: エンジニア (新卒3年目) ⚫ 仕事 ⚫ 受託開発メインです。 ⚫ 大手飲食チェーン (クライアント) に向 けて開発をしています。
3. ©2019 giftee Inc. all rights reserved 3 前提 チームで運用しているシステムのEB→ECS化案件を実施 ⚫ このシステムの特徴として、インフラ/ソースコードに以下の管理境界があ る ⚫ ECS化対応後もこの境界を変更しないために、IaCをリポジトリで管理する 方針は基本とらない インフラ ソースコード 置き場 クライアントの管理する AWSアカウント 弊社の管理するgithubリ ポジトリ 役割分担 クライアントがAWSマネー ジドコンソールから変更 弊社が自動CIの実行によ り変更を反映
4. ©2019 giftee Inc. all rights reserved 4 前提 CIのデプロイワークフロー 1. DockerイメージをECRにプッシュ 2. 1のdocker imageを指定して、タスク定義を更新 3. ECSサービスが、更新後のタスク定義のバージョンを指定してタスクをデプロイ これの実現方法を何通りか検討したのでご紹介します
5. ©2019 giftee Inc. all rights reserved 5 方法1: AWS CLIを使う CIの流れ 1. 既存のタスク定義をdescribe-task-definitionコマンドで取得 (json形式) 2. 取得したタスク定義をjqコマンドを使用して書き換える 3. register-task-definitionコマンドで、新しいリビジョンを作成する メリデメ 管理境界 (クライアント: インフラ / 弊社: ソースコード) が明確 CI破損リスクがある ⚫ jqのハードコードにより、タスク定義の構造が変わった場合にCIが破損する危 険がある
6. ©2019 giftee Inc. all rights reserved 6 方法2: ecspressoを使用する ecspressoとは ⚫ ECSのデプロイにフォーカスしたツール ⚫ タスク定義、サービス定義をコード管理する CIの流れ 1. リポジトリに管理しているタスク定義、サービスを更新して書き換える 2. ecspresso diff コマンドで、AWS上の設定と差分を確認 3. ecspresso deployコマンドでデプロイを実行する ⚫ タスク定義の更新/ECSサービスへのデプロイを行う メリデメ 方法1よりCIが壊れるリスクは少ない 方法1より管理境界 (クライアント: インフラ / 弊社: ソースコード) が曖昧 ⚫ タスク定義/サービス定義の設定更新が発生した場合、お客さんから依頼を受け て弊社側で行う必要がある
7. ©2019 giftee Inc. all rights reserved 7 方法3: aws-actionsを使用する aws-actionsとは ⚫ AWSが公式に提供しているGitHub Actions 用のライブラリ CIの流れ 1. amazon-ecs-render-task-definitionで最新のタスク定義をダウンロード 2. タスク定義を書き換える 3. amazon-ecs-deploy-task-definitionでデプロイの実行 ⚫ タスク定義の更新/ECSサービスへのデプロイを行う メリデメ 方法1よりCIが壊れるリスクは少ない 方法2より管理境界 (クライアント: インフラ / 弊社: ソースコード ) が明確 →最終的にこの方法を採用
8. ©2019 giftee Inc. all rights reserved 8 まとめ ⚫ ECS化案件にてCIの構築をしていた ⚫ 該当のシステムは「クライアント: インフラ / 弊社: ソースコード」で管理 境界を分けたかった ⚫ タスク定義を更新において、3つの方法を管理境界の明確さ/CI破損リスク の軸で検討した結果、「aws-actionsを使用した方法」を採用する判断に 至った 方法1: AWS CLIを 使う 方法2: ecspressoを 使用する 方法3: aws-actions を使用する 管理境界の 明確さ ◦ △ ◦ CI破損リスク △ ◦ ◦