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
Kobayashi-Riku
October 30, 2025
1
84
ECS FargateへのデプロイにCI/CDを導入してデプロイ工数を削減してみた
【AWS】AWS10分LT会 - vol.7の登壇資料
https://aws-likers.connpass.com/event/370773/
Kobayashi-Riku
October 30, 2025
Tweet
Share
More Decks by Kobayashi-Riku
See All by Kobayashi-Riku
AWS re:Postで毎日回答してたらポイント数世界一になった話
rikukobayashi
0
540
Featured
See All Featured
How GitHub (no longer) Works
holman
315
140k
Rails Girls Zürich Keynote
gr2m
95
14k
4 Signs Your Business is Dying
shpigford
186
22k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
46
7.8k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
24
1.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.2k
Speed Design
sergeychernyshev
32
1.2k
Docker and Python
trallard
46
3.6k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
310
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1k
KATA
mclloyd
PRO
32
15k
Building a Scalable Design System with Sketch
lauravandoore
463
33k
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