GitHubとCodePipelineを組み合わせたときに、CodePipeline単独でできないこと4選 in 2021
※個人ブログからのバックアップ用に転記
各種ブログや公式ドキュメントなどで、CodePipeline でできることが記載されていることは多いのですが、CodePipeline 単独では現在の仕様上対応できていないこともあります。
GitHub や ECR と組み合わせて CodePipeline のパイプライン設計を行う際、このあたりの制限を意識しておかないと、後からハマる可能性がありそうだと思ったので備忘録がてら書いておきます。
1. Source ステージの注意点
1-1. branch push 以外のイベント(e.g. tag push など)では、CodePipeline の GitHub アクションが起動しない
- GitHub connections(AWS 公式ドキュメント)
https://docs.aws.amazon.com/codepipeline/latest/userguide/connections-github.html
In Repository, enter the name of your repository. In Branch name, choose the branch where you want your pipeline to detect source changes.
これは CodePipeline がブランチを指定する仕様のため、仕方ないかなと。
もしどうしてもブランチ以外でのイベントで CodePipeline を起動させたいのであれば、下記のブログのように、Webhook を使った迂回路を準備する方法を検討する必要があります。
GitHub の push 以外の WebHook イベントから CodePipeline を発火させる(Qiita)
1-2. 正規表現を使ったブランチ指定では、CodePipeline の GitHub アクションが起動しない
上記のスクリーンショットは、develop-*という Sorce ステージの設定で、devevelop-hogeといったブランチのイベントをキックさせようとしたときのエラー画面になります。
CI/CD のパイプラインを構築しようとした場合、ブランチ名に正規表現を使ってパイプラインを起動させたいときがありそうなので、このあたりはパイプライン設計の際に意識しておいた方がよさそうです。
- Multi-branch CodePipeline strategy with event-driven architecture
https://aws.amazon.com/jp/blogs/devops/multi-branch-codepipeline-strategy-with-event-driven-architecture/
一応、上記のブログで CloudFormation や Lambda を使った複数ブランチ戦略の例が紹介されてますが、CodePipeline 単独よりも結構作り込みが必要になりそうです。
2. Deploy ステージの注意点
2-1. ECR イメージをクロスアカウントでレプリケーションしたときに、CodePipeline の ECR アクションはそのイベントを検知できない
AWS ECR には、イメージのクロスアカウントレプリケーション機能がありますが、下記のように staging の AWS アカウントに push した ECR のコンテナイメージを production の AWS アカウントにレプリケーションした後で CodePipeline を起動させたくても現状できません。
一応、下記のような GitHub Issue でこの機能への要望はあがっている模様。
クロスアカウントレプリケーションで使われる EventBridge で CodePipeline がイベントを検知できないため、CodePipeline の ECR アクションがトリガーとして機能しないとのこと。
- [ECR] [Replication]: EventBridge events that fire when an image is replicated
https://github.com/aws/containers-roadmap/issues/1194
2-2. ECS デプロイと ECS の blue/green デプロイは、同じ設定内容で起動できない
- Image definitions file reference(AWS 公式ドキュメント)
https://docs.aws.amazon.com/codepipeline/latest/userguide/file-reference.html#pipelines-create-image-definitions
ECS のデプロイは、上記のドキュメントの通り imagedefinitions.json で定義されます。
設定項目は、
- name
- imageUri
の 2 種類のみ。
一方の ECS blue/green デプロイについては、ECS デプロイという文言ではありますが、実質 CodeDeploy を起動させるというアクションになるので、CodeDeploy を起動させる appspec.yml が必要となります。この Configuration Parameters を最低限揃えるだけで、
- ApplicationName
- DeploymentGroupName
- TaskDefinitionTemplateArtifact
- AppSpecTemplateArtifact
の設定項目が必要となります。
CodePipeline のユーザーは、この両者のデプロイ方法が違うのを意識してパイプライン設計を行う必要があります。
【参考】
- Amazon Elastic Container Service and CodeDeploy Blue-Green(AWS 公式ドキュメント)
https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-ECSbluegreen.html - CodeDeploy AppSpec File reference
https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html
3. まとめ
本記事は 2021/12/31 時点で CodePipeline 単独でできないことを 4 つほど紹介させていただきました。
記事の途中にある他ブログのように、Lambda や CloudFormation を組み合わせると、もう少し複雑なパイプライン設計はできると思われます。
個人的には、CircleCI や GitHub Actions などとはパイプラインの設定方法が大きく異なるため、
CodePipeline はあくまで AWS リソースへのデプロイを行うパイプラインということを意識しておくと、CodePipeline のパイプライン設計の際に迷わないかなと感じました。
GitHub と CodePipeline の連携はよくあるユースケースだと思うので、どなたかの参考になれば。
Discussion