Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ECS FargateへのデプロイにCI/CDを導入してデプロイ工数を削減してみた
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Kobayashi-Riku
October 30, 2025
110
1
Share
ECS FargateへのデプロイにCI/CDを導入してデプロイ工数を削減してみた
【AWS】AWS10分LT会 - vol.7の登壇資料
https://aws-likers.connpass.com/event/370773/
Kobayashi-Riku
October 30, 2025
More Decks by Kobayashi-Riku
See All by Kobayashi-Riku
重い腰を上げてECSのアップデートを触ってみた
rikukobayashi
1
170
AWS re:Postで毎日回答してたらポイント数世界一になった話
rikukobayashi
0
620
Featured
See All Featured
Efficient Content Optimization with Google Search Console & Apps Script
katarinadahlin
PRO
1
470
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
120
For a Future-Friendly Web
brad_frost
183
10k
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
450
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
240
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
110
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
1.9k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
200
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.4k
Technical Leadership for Architectural Decision Making
baasie
3
310
Testing 201, or: Great Expectations
jmmastey
46
8.1k
Transcript
ECS FargateへのデプロイにCI/CDを導入して デプロイ工数を削減してみた 2025/10/30 AWS10分LT会 - vol.7 小林 陸
自己紹介 • Name:小林 陸 (Kobayashi Riku) • 所属 ◦ 11月に転職します
• 経歴 ◦ ネットワークエンジニア → AWSエンジニア • 好きなAWSサービス ◦ AWS Lambda, Amazon EventBridge • 実績 ◦ AWS Community Builder 2023~ • その他 ◦ X (@Riku0_Kobayashi) ◦ AWS re:Post ポイント数世界1位 2
目次 • AWS構成の簡易説明 • CI/CD導入前の状態 • 導入後の構成 • 導入した効果 •
プロジェクトのどのフェーズで導入するのがよいのか • さいごに 3
AWS構成の簡易説明 • コンテナ内のPythonコードからSaaSのAPIを実行してデータを取得し加工後にS3 へ保管するシステム ◦ EventBridge Scheduler → ECS →
S3といった流れ 4
CI/CD導入前の状態 • 導入前はCloudShellでコンテナイメージのビルドを行っていてデプロイの作業時間 に1時間近くかかっていた ◦ セキュリティ上の理由でローカル PCでDockerなどを入れるのが大変だった ◦ DockerやAWSに慣れていないため手順を用意しても操作に時間がかかってしまう ◦
CloudShellのホームディレクトリのサイズ制限の 1GBがあるため何度かコンテナイメージの作成を やり直すとビルドコマンドが失敗する • テストコードを手動実行していた ◦ 手順として抜けることがあるとやり直しになる 5
導入後の構成 (1) • CI/CDにはGitHub Actionsを使用 ◦ コードの管理にGitHubを利用していたためそのまま利用 • ワークフローでpytestの実行とコンテナイメージのビルドを実行 ◦
pytest実行後にコンテナイメージのビルドを行い ECRへプッシュする • Environments 機能を使用してデプロイ前に承認フェーズを設定 ◦ https://docs.github.com/ja/actions/how-tos/deploy/configure-and-manage-deployments/manag e-environments 6
導入後の構成 (2) • ワークフローファイル ◦ コンテナイメージの作成部分 aws-actions/configure-aws-credentials@v4で AWS認証情報を設定 aws-actions/amazon-ecr-login@v2でECRへログイ ン
docker build, docker pushでコンテナイメージの作 成とプッシュを実行 7
導入した効果 • 開発環境に入れた結果5分程度で動作確認まで行えるようになった ◦ 本番環境はまだ入れられていないが手順としては mainブランチへのマージで動作するためかなり の工数削減に繋がる想定 • 人の手が入る箇所が減ったため単純にミスが減った ◦
GitHub Actionsを使用する前は手動手順が多かったためコマンドの実行ミスなどがあり無駄な時間 を過ごすことが多かった 8
プロジェクトのどのフェーズで導入するのがよいのか • プロジェクト初期のインフラ構築フェーズで導入をお勧めしたい ◦ CDの部分だけでも本番リリース前に入れられるとベスト ◦ 本番リリース後だと環境に対して設定の追加などに神経を使う必要がある ▪ 今回の場合はIAMの設定追加くらいではあるが環境によっては導入が大変な可能性あり •
CI (テストのみ) 部分は後からでも最悪よいと思う ◦ CDのみ開発フェーズから入れられると開発サイクルの高速化に繋がる ◦ テストコードなどは最初からあった方がよいが最悪後からの導入でもよいと思う 9
さいごに • CI/CDは利用できるアプリケーションや環境であれば導入した方がよい • なるべくプロジェクトの初期フェーズで導入をお勧め 10