CodePipelineを使用してGitHubにコードをプッシュするとECSにデプロイされるように自動化する
はじめに
今回は下記のプロジェクトをCodepipelineを使用してGitHubにコードをプッシュしたら、ECSにデプロイされるようにしたいと思います。
ビルドの仕様ファイルの作成
CodeBuildで使用されるビルドの仕様を記述したファイルであるbuildspec.ymlを作成します。
DockerHubからPullして使用しているイメージがあったため、ダウンロードの制限に引っかかり以下のような表示が出てしまいましたので、DockerHubへのログイン処理を追加しています。
Too Many Requests - Server message: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading:
version: 0.2
# ビルド実行時にCodeBuildが実行するコマンド
phases:
pre_build:
commands:
# ECRにログイン
- echo Logging in to Amazon ECR...
- aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
# DockerHub への個別ユーザでのログイン処理
- echo Logging in to Docker Hub...
- echo ${DOCKERHUB_PASS} | docker login -u ${DOCKERHUB_USER} --password-stdin
build:
commands:
# Composerのインストール
- php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
- php composer-setup.php
- php -r "unlink('composer-setup.php');"
- mv composer.phar /usr/local/bin/composer
# Composerを使って依存関係をインストール
- composer install
# .env ファイルがない場合は、.env.example をコピーして生成
- if [ ! -f .env ]; then cp .env.example .env; fi
# Laravelアプリケーションの鍵を生成
- php artisan key:generate
# イメージをビルドしてECRにプッシュ
- echo Building the Nginx Docker image...
- docker build --no-cache --platform linux/amd64 -t $ECR_NGINX -f ./docker/nginx/Dockerfile .
- docker tag $ECR_NGINX $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_NGINX
- docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_NGINX
- echo Building the PHP Docker image...
- docker build --no-cache --platform linux/amd64 -t $ECR_PHP -f ./docker/php/Dockerfile .
- docker tag $ECR_PHP $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_PHP
- docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_PHP
post_build:
commands:
# コンテナイメージの情報をimagedefinitions.jsonファイルに書き込む
- echo Writing image definitions file...
# "%s"はプレイスホルダー
- printf '[{"name":"nginx","imageUri":"%s"}]' $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_NGINX > imagedefinitions.json
- printf ',\n{"name":"app","imageUri":"%s"}' $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_PHP >> imagedefinitions.json
artifacts:
files: imagedefinitions.json
パイプラインの作成
パイプラインを作成するを選択、

パイプライン名を入力します。今回はECSAutoDeployPipelineとしました。
パイプラインタイプはV2を選択してください。
ロール名が自動で入力されていることを確認したら、次にを選択してください。

ソースプロバイダーは、GitHubとAWS CodePipelineの連携を改善するために導入されたバージョンのようなので、GitHub(バージョン2)を選択、

GitHubに接続するを選択、

今回は接続名にConnect with GitHubと入力し、GitHubに接続するを選択、

新しいアプリをインストールするを選択、

ログインして認可を行ってください。

AWS Connector for GitHubをどこにインストールするか選択してください。

またはOnly select repositoriesのSelect repositoriesで使用したいリポジトリを個別に設定してください。

今回はAll repositoriesを選択してSaveを押します。
下の画面にリダイレクトされると思うので接続を選択してください。

リポジトリ名を選択し、ランチ名はmainを選択して、次にを押してください。

次回以降は検索で出てくるようになります。

AWS CodeBuildを選択し、

プロジェクトを作成するを選択してください。

プロジェクト名は今回はECSAutoDeployBuildと入力し、
環境イメージはマネージド型イメージ
オペレーティングシステムはAmazon Linux
ランタイムはStandard
イメージはaws/codebuild/amazonlinux2-x86_64-standard:5.0をそれぞれ選択、
イメージのバージョンはそのままにします。
特権付与にチェックを入れます。

CloudWatchのグループ名にはECSAutoDeployBuildと入力し、次にを選択してください。

このページを離れるを選択

元の画面にリダイレクトされると思うので、次のような表示を確認したら、次にを選択してください。

Amazon ECSを選択、

クラスター名でサービスを実行するクラスタとサービス名を選択して、次へを選択

下までスクロールしたら、パイプラインを作成するを選択してください。

ECR権限CodeBuildロールに追加する
IAMからロールを選択します。
検索ボックスにcodebuild-と入力し、CodePipelineを作成したときに自動で作成されたロールを選択します。

許可ポリシーからアクセス許可のポリシーをアタッチを選択

AmazonEC2ContainerRegistryPowerUserを選択し、ポリシーをアタッチを押下します。

環境変数の追加
CodeBuildからビルドプロジェクトを選択、

環境変数を追加したいプロジェクトを選択します。

編集の環境を選択、

追加設定を選択、

環境変数を入力してください。

環境の更新を選択して環境変数の追加を完了させてください。

下記の記事でSSMを使用した環境変数の設定についても記述しています。
動作確認
試しにtest.mdを作成し、コミット&プッシュしてみます。

デプロイまで実行できました。

接続の削除方法
左メニューの設定の接続から行うことができます。

ECSでタスクが停止しても再開される場合
Auto Scalingの設定: ECSはAuto Scalingを使用して、指定されたリソース使用率や他のメトリクスに基づいてタスクを自動的にスケールアップまたはダウンさせることができます。タスクが停止されても、Auto Scalingによって必要に応じて新しいタスクが起動される可能性があります。
サービスの設定: ECSサービスは、常に指定された数のタスクを実行し続けるように設定できます。タスクが停止しても、サービスが自動的に新しいタスクを起動してタスク数を維持しようとします。
タスクの状態: タスクが停止している場合でも、再起動されることがあるかもしれません。これは、タスクの再起動ポリシーやエラーの回復メカニズムに関連しています。タスクが停止した原因によっては、自動的に再起動されるように設定できます。
タスク定義の設定: タスク定義には、再試行ポリシーや最大再試行回数などの設定が含まれることがあります。これらの設定に基づいて、タスクが停止しても再試行されることがあります。
参考にさせていただきました
終わりに
何かありましたらお気軽にコメント等いただけると助かります。
ここまでお読みいただきありがとうございます🎉
Discussion