Terraformを扱うCodePipelineの最小構成テンプレートを作りました
terraformを扱うCICDパイプラインを考える中で、「検討のベースとなる基本テンプレート」が欲しくなってきたので作りました。
ハマりポイントも所々あったので、のちの方へのバトンとしてシェアしておきます。
Architecture
今回作成したのは、
- CodePipeline
- CodeCommit
- CodeBuild
- S3
- KMS
を組み合わせたCICD用のパイプライン。terraformでアプリケーションをデプロイすることが目的なので、ステージ構成は、
- Source
- PlanAndFmt
- Approval
- Apply
としています。Plan結果を目視確認したうえで、手動Approvalする想定です。
設計思想
パイプラインに求める機能は、開発チームによりけりなので、ここでは最小構成にとどめています。
例えば、Git push契機で動かすトリガーの設定や結果通知が欲しくなるかと思いますが、ケースバイケースのため今回はあえて実装していません。その分カスタマイズしやすくなっていますので、こちらをベースに拡張ください。
権限設定
各リソースの権限設定は(運用がめんどうにならない範囲で)最小権限としてます。後述しますが、各stageのactionごとにIAM Roleを細かく分割した応用型です。
また、IAM Roleやリソースポリシーを混在させるととっつきにくくなる(カスタマイズしづらくなる)ため、今回は全権限設定をIAM Roleのみで実施しています。
Code structure
カスタマイズ性を加味して、一式をひとつのmoduleに押し込んでいます。
terraform
├── envs
│ └── example
│ ├── aws.tf
│ └── main.tf
└── module
└── codepipeline
├── artifact_store.tf
├── buildspec_action_apply.yml
├── buildspec_action_plan_fmt.yml
├── codebuild_action_apply.tf
├── codebuild_action_plan_fmt.tf
├── codepipeline.tf
└── variables.tf
カスタマイズ例
例えば、以下のような設定を追加してもらうとよいかと！
- Git pushでトリガーする
- Plan結果をSlackに通知
- Apply結果をSlackに通知
- S3, KMSにリソースポリシーを設定して、より堅牢に
- CodeDeployを追加して、Blue/Greenデプロイに対応させる
- CodeBuild用のterraformコンテナのimage取得先を変更する(初期値はDockerHubから認証無しで取得する設定になっているため、pull数制限にたびたび引っかかります)
ハマりポイント
CodePipelineに付与するIAM Role
CodePipelineには、パイプライン実行時に利用するIAM Roleを付与する必要があるのですが、実はこれ付与の仕方が2種類あります。
- 基本型: CodePipelineに、単一のIAM RoleをService Roleとして付与。全アクションでこのロールを利用するパターン
- 応用型: CodePipelineの各アクションで使うIAM Roleを追加で定義。Service RoleからAssume Roleして利用するパターン
応用型のほうが、細かく権限を設定できるため、強すぎる権限を持ったCodePipelineが生まれにくいです。
どこまで気にするかですが、特にクロスアカウントでパイプラインを運用する場合etcの場合は、細かく権限を設定したほうがよいかと思います。
Artifact storeへのアクセス権
今回の構成の場合には、
- CdodePipelineに付与する「Source stage」のAction role
- CodeBuildプロジェクトに付与するService Role
のみ、Artifact store(S3, KMS)へのアクセスが必要です。
その他のRoleに付与する必要はないため、ご注意ください。
もしまちがいや不足があれば、お気軽にGitHubのissueにあげていただけると嬉しいです。
Discussion