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
エンジニアに許された特別な時間の終わり
watany
106
240k
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
110
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
2
660
A brief & incomplete history of UX Design for the World Wide Web: 1989–2019
jct
1
340
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.1k
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.2k
Un-Boring Meetings
codingconduct
0
250
Agile that works and the tools we love
rasmusluckow
331
21k
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
5
780
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
49
9.9k
Technical Leadership for Architectural Decision Making
baasie
3
310
Odyssey Design
rkendrick25
PRO
2
560
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