はじめに
こんにちは。今回は、AWS CodePipeline を使って Amazon ECS に自動デプロイを構築する手順を紹介します。
手動でのデプロイ作業に煩わしさを感じていた方、CI/CDの導入に興味がある方に向けて、なるべくシンプルな構成でECSの自動デプロイ環境をお試しする手順になります。
CodePipeline とは
そもそもAWSにはCI/CDを構成するための4つの主要サービスがあり、開発者の間ではこれらを 「Code4兄弟」 と呼ぶことがあります。
| サービス名 | 役割 |
|---|---|
| CodeCommit(2025年5月現在廃止済み) | Gitリポジトリ（ソース管理） |
| CodeBuild | ビルド処理 |
| CodeDeploy | デプロイ処理 |
| CodePipeline | パイプライン管理 |
CodePipeline はこの4兄弟の中の1つで、コードのビルド、テスト、デプロイといった一連の流れを自動化できるサービスです。
主に以下のような特徴を持っています：
- 複数のステージで構成されたパイプラインが定義できる
- GitHubやGitLabとの連携が簡単
- CodeBuildやECS、Lambdaなどとの統合がスムーズ
今回はCodePipelineのみを使って、変更があるたびにECSへ自動デプロイする仕組みを実現していきますが、
AWS上でCI/CDを構築する場合、これらのサービスを組み合わせるのが基本パターンなので、それぞれの役割を理解しておくと他の場面でも応用が利きます。
AWS構成
CloudShellを利用してECRに対してイメージをプッシュし、それをトリガーとしてCodePipelineを実行し、ECSへデプロイをする流れになります。
実際に構築していく
準備
ECRの作成
アプリケーションのDockerイメージを格納するためのECRリポジトリを作成します。
Dockerイメージのビルドとプッシュ(CloudShell)
私が以前担当したプロジェクトではGitLabパイプラインにECRへプッシュする仕組みを作りましたが、
簡易化のためCloudShellを利用していきます。
AWS CloudShellを使えば、ローカル環境を用意せずに、ブラウザ上で簡単にDocker操作が可能です。
フォルダ構成
多分これが一番簡単だと思います。
※フォルダ名をECRリポジトリ名と合わせておくと、後述のコマンドをそのまま使用できます。
codepipeline-sample
├── Dockerfile
└── index.html
- Dockerfile：Nginxをベースにした簡易Webサーバー用Dockerイメージ定義ファイル
- index.html：ブラウザに表示されるシンプルな静的ページ
Dockerfileの内容
# ベースイメージとしてNginxを使用
FROM nginx:alpine
# デフォルトのHTMLを削除
RUN rm -rf /usr/share/nginx/html/*
# カスタムHTMLをコピー
COPY index.html /usr/share/nginx/html/
index.htmlの内容
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Hello from ECS!</title>
</head>
<body>
<h1>Hello from ECS + CodePipeline!</h1>
</body>
</html>
CloudShellを開いて、ECRに表示されているコマンドを叩いていきます。
ECS(Fargate)環境の作成
ECSクラスター
起動タイプFargateでクラスターを作成します。
タスク定義
コンテナ
利用するコンテナイメージを定義します。
それ以外の項目はそこまで意識しなくても大丈夫です。
ECSサービス
次にECSサービスを作成します。
ALBなどもここで作成することができますが、今回は直接ECSにアクセスするため不要です。
ここまでで準備完了です。
ECSタスクのIPアドレス(ECSのページから対象ECSタスクのパブリックIPから確認)にアクセスすると、
無事、ページが表示されました。
自動デプロイ構築
いよいよ自動デプロイを構築していきます。
S3
まずはS3バケットを作成します。
次にパイプラインとコンテナを紐づけるための定義ファイルを作成します。
ECSサービスは、どのコンテナイメージを使用すべきかを明示的に受け取る必要があります。
そのため、imagedefinitions.json というJSON形式のファイルを使って、対象のイメージURIをパイプライン経由でECSに伝える必要があります。
imagedefinition.jsonの内容
[
{
"name":"sample",
"imageUri":"{アカウントID}.dkr.ecr.ap-northeast-1.amazonaws.com/codepipeline-sample:latest"
}
]
作成した定義ファイルをzip化し、先ほど作成したバケットにアップロードします。
これでS3側の準備は完了です。
CodePipeline
まずはカテゴリーを選択します。
今回はカスタムパイプラインで作成していきます。
ソースステージではトリガーとなるECRを選択していきます。
実際にトリガーを検知するEventBridgeも自動作成されるので、必ずチェックを付けるようにしてください。
今回はビルドステージとテストステージは不要なのでスキップします。
デプロイステージでは、今までに構築したECSクラスター・サービス、イメージ定義ファイルを設定します。
ただし、今のままだとS3からイメージ定義ファイルを取得する設定になっていないので、この後設定します。
以上でCodePipelineの作成が完了しました。
次に、作成したパイプラインを編集し、S3からイメージ定義ファイルを取得する設定を追加します。
ソースステージにアクションを追加し、以下の設定を行います。
デプロイステージの入力アーティファクトも変更します。
これで自動デプロイの準備は完了です。
ECRにプッシュしてみる
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>Hello from ECS!</title>
</head>
<body>
<h1>Hello from ECS + CodePipeline!</h1>
<h1>自動デプロイ成功！</h1>
</body>
</html>
index.htmlを修正し、ECRにプッシュします。
すると、CodePipelineが作動するので処理完了まで待ちます。
処理が完了し、ECSタスクのIPアドレスにアクセスすると、
自動デプロイされ、静的ページの更新が確認できました。
最後に
今回は、CodePipelineを使ってAmazon ECSへ自動デプロイする環境を構築しました。CodeBuildやCodeDeployを使わず、あえてシンプルな構成にすることで、CI/CDの基本的な仕組みや流れをより明確に理解できたのではないでしょうか。
AWSのCodeシリーズ（通称：Code4兄弟）を組み合わせることで、複雑なCI/CDパイプラインも柔軟に設計できます。今回の構成はシンプルながら、実際の業務でも応用可能なベースになるはずです。
今後はビルドやテストステージの追加、GitHubとの連携、自動ロールバックなど、より高度な構成にもチャレンジしてみてください！