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
99
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
重い腰を上げてECSのアップデートを触ってみた
rikukobayashi
0
150
AWS re:Postで毎日回答してたらポイント数世界一になった話
rikukobayashi
0
580
Featured
See All Featured
End of SEO as We Know It (SMX Advanced Version)
ipullrank
2
3.9k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
110
Designing Powerful Visuals for Engaging Learning
tmiket
0
200
Code Review Best Practice
trishagee
74
19k
First, design no harm
axbom
PRO
2
1.1k
Intergalactic Javascript Robots from Outer Space
tanoku
273
27k
[SF Ruby Conf 2025] Rails X
palkan
0
720
Lightning Talk: Beautiful Slides for Beginners
inesmontani
PRO
1
420
Beyond borders and beyond the search box: How to win the global "messy middle" with AI-driven SEO
davidcarrasco
1
41
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
150
Java REST API Framework Comparison - PWX 2021
mraible
34
9.1k
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
300
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