NICOA

Terraformを扱うCodePipelineの最小構成テンプレート

Terraformを扱うCodePipelineの最小構成テンプレート
どんな記事?

  • Terraformで作るCodePipelineサンプルコードの紹介記事
  • terraformコマンドを実行するための最小構成テンプレート
  • 最小権限に拘った実装パターンとしています

terraformを扱うCICDパイプラインを考える中で、**「検討のベースとなる基本テンプレート」**が欲しくなってきたので作りました。

ハマりポイントも所々あったので、のちの方へのバトンとしてシェアしておきます。

GitHub - Donngi/terraform-example-codepipeline-execute-terraform: Minimum example of CodePipeline which executes terraform commands.
GitHub - Donngi/terraform-example-codepipeline-execute-terraform: Minimum example of CodePipeline which executes terraform commands.
GitHubGitHub
スポンサーリンク

Architecture

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種類あります。

  1. 基本型: CodePipelineに、単一のIAM RoleをService Roleとして付与。全アクションでこのロールを利用するパターン
  2. 応用型: CodePipelineの各アクションで使うIAM Roleを追加で定義。Service RoleからAssume Roleして利用するパターン

応用型のほうが、細かく権限を設定できるため、強すぎる権限を持ったCodePipelineが生まれにくいです。

どこまで気にするかですが、特にクロスアカウントでパイプラインを運用する場合etcの場合は、細かく権限を設定したほうがよいかと思います。

Artifact storeへのアクセス権

今回の構成の場合には、

  • CdodePipelineに付与する「Source stage」のAction role
  • CodeBuildプロジェクトに付与するService Role

のみ、Artifact store(S3, KMS)へのアクセスが必要です。

その他のRoleに付与する必要はないため、ご注意ください。

あとがき

次はCodeDeploy組み込んだパイプラインに挑戦したい!

もしまちがいや不足があれば、お気軽にGitHubのissueにあげていただけると嬉しいです。

GitHub - Donngi/terraform-example-codepipeline-execute-terraform: Minimum example of CodePipeline which executes terraform commands.
GitHub - Donngi/terraform-example-codepipeline-execute-terraform: Minimum example of CodePipeline which executes terraform commands.
GitHubGitHub

最後までご覧いただきありがとうございました。
Jimon(@Jimon_s)でした。