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
120
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
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
AWS DevOps Agent使ってみて結構いいかもと思った話
rikukobayashi
2
190
Kiro CLIで始めるECS構築
rikukobayashi
1
130
重い腰を上げてECSのアップデートを触ってみた
rikukobayashi
1
210
AWS re:Postで毎日回答してたらポイント数世界一になった話
rikukobayashi
0
740
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
230
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.4k
GraphQLとの向き合い方2022年版
quramy
50
15k
Accessibility Awareness
sabderemane
1
150
世界の人気アプリ100個を分析して見えたペイウォール設計の心得
akihiro_kokubo
PRO
72
40k
VelocityConf: Rendering Performance Case Studies
addyosmani
333
25k
KATA
mclloyd
PRO
35
15k
Git: the NoSQL Database
bkeepers
PRO
432
67k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
How to Think Like a Performance Engineer
csswizardry
28
2.7k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
220
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