以下のような環境を構築しました。コード管理しています。CIの流れCIの流れは以下のようになります。(buildspec.yamlの内容)CodePipelineとCodeBuildは、それぞれAWS内部リソースへアクセスするため、サービスロールという形で権限付与する必要があります。CodePipelineはパイプラインの各ステージ間で、ソースコードやビルド後の成果物を共有する際に(後段のステージに渡す際に)S3バケットを必要とします。CI環境を構築するCloudformationテンプレートと構築手順Cloudformationテンプレート上記の構成を実現するCloudformationテンプレートを作成しました。cloudformationテンプレートこのテンプレート使用したCI環境構築は後ほど説明します。buildspec.yamlbuildspecには以下のコマンドが記述されています。DockerイメージビルドのコマンドECRへイメージpushするコマンド<ECRレジストリURI>、<リポジトリ名>は、ECR作成後に取得して、追記が必要です。上記テンプレートを使用して、実際に構築する手順を紹介します。DockerイメージのGithubリポジトリを用意するDockerfileとbuildspec.yamlが含まれたGithubリポジトリを用意します。ファイル構成は以下です。既存のGithubリポジトリに適用する場合も、所定のDockerfileと、上記で説明したbuildspec.yamlを追加するだけです。Token」をクリック生成完了後、トークンが表示されるのはこの画面だけです。画面を移動する前にトークンをコピーしておきましょう。余談ですが、このトークンはセキュリティ上重要なもので、漏洩すると不正攻撃に利用されてしまいます。LastPassやOnePasswordなど、セキュア情報管理サービスを利用するなどして安全に保存するのがおすすめです。Githubリポジトリ内のコードへのハードコーディングは絶対にやめましょう。先ほど紹介したテンプレートを使用して、CI環境のAWSスタックを構築します。アップロード」を選択し、テンプレートファイルを指定するテンプレートファイルは、以下リポジトリよりダウンロードできます。cloudformationテンプレート本テンプレートは以下のパラメータを指定できます。Token例として、以下のように設定します。リソースが作成される場合があることを承認します。」にチェックを入れて、「作成」をクリックCloudformationに作成したスタックが表示されているはずです。作成には少し時間がかかります。以下のように「CREATE_COMPLETE」となれば完了です。GithubリポジトリへpushCodePipelineに作成したスタック名と同じpipelineが作成されています。SourceステージのGithubリポジトリからのPullが成功しているかを確認します。Tokenに誤りがないかなど確認しましょう。このままでもpipelineは起動しますが、buildspec.yamlにECRリポジトリURLを記述していないため、ビルドに失敗します。DockerイメージのGithubリポジトリを用意する」で用意したGithubリポジトリのbuildspwc.yamlの<リポジトリURL>と<リポジトリ名>を埋めて、pushしましょう。これらはECRの画面から確認できます。リポジトリ名とURI欄をコピーして、それぞれbuildspec.yamlにペーストします。追記したbuildspec.yamlをpushすると、ビルドも成功するはずです。ECRにも、Dockerイメージがpushされています。本手順の注意点Githubリポジトリの変更検出方式がポーリングである本記事で紹介している方式では、「CodePipelineはGithubの変更によってトリガーされて起動する」ような書き方をしています。これはイメージ的にわかり易くするためですが、実際にはトリガーされるのではなく、「CodePipelineがGithubリポジトリをポーリング」しています。以前はこの方式しかなかったのですが、2018年5月にGithubのWebhookイベントに対応し、本当にGithubからCodePipelineをトリガーすることができるようになりました。https://aws.amazon.com/jp/about-aws/whats-new/2018/05/aws-codepipeline-supports-push-events-from-github-via-webhooks/Webhookに対応するやり方は、改めてまとめたいと思います。https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/pipelines-webhooks-migration.htmlCI環境を構築する度にS3バケットと各種サービスロールが作成されるこれには2つ問題があります。作成されるリソースが多くなるため管理が煩雑化アカウント毎に作成可能なリソース上限に引っかかる一つ目は特に説明は不要かと思いますし、それほど大きな問題でもないですが、二つ目に関しては結構重大な問題になる場合があります。100個までしか作成できません。https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/BucketRestrictions.htmlCodePipelineには、アーティファクトバケット(Githubからpullしたコードなどを各ステージへ受け渡すための保存用のバケット)が必要です。本記事で紹介したテンプレートを使用してスタックを構築する度に、S3バケットが増えていくことになります。他の要因で大量のバケットが存在している場合や、100を超えるCI環境を構築したい場合には、アーティファクトバケットをパラメータで指定するなどの工夫が必要です。Roleについても同じことが言えます。こちらはAWSアカウント毎に1000オブジェクトまで作成可能なので、S3バケットほどすぐには問題になりませんが、管理煩雑化を低減するためにも、S3と同様の対策をしておいたほうが良さそうです。https://docs.aws.amazon.com/jajp/IAM/latest/UserGuide/referenceiam-limits.html本問題について、対策したものは改めてまとめたいと思います。まとめ「DockerイメージをECRへデプロイするCI環境」を構築するCloudformationテンプレートと構築手順を紹介しました。Dockerは、今後使われていく機会が増えていくと思いますので、単にECRへのデプロイを自動化するCI環境も、サクッと構築したい場合に参考になるかと思います。CodePipelineは、ECSへのデプロイにも対応しており、ECRへのDockerイメージpushと同時にECSへのデプロイも自動化したCICD環境を作ることも可能です。この環境についても、改めてまとめたいと思います。本手順の注意点Githubリポジトリの変更検出方式がポーリングであるCI環境を構築する度にS3バケットと各種サービスロールが作成されるまとめ。