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