この記事では、AWSにおけるTerraform用CI/CD構築をTerraformによって構築する方法についてご紹介します。
実際の構築手順ベースの記事となっていますので、CI/CD構築未経験の方やTerraform初心者の方がハンズオンする際の参考になれば幸いです。
目次
- 前提条件と開発環境
- システムアーキテクチャ
- 構築①：tfstateとロック制御管理リソースの作成
- 構築②：AWS CodeCommit（SSH接続設定とリポジトリ作成）
- 構築③：CI/CDパイプラインと承認フローの統合（CodeBuild / CodePipeline）
- 構築④：メンション付きSlack通知の実装（EventBridge / Lambda / Amazon Q Developer）
- おわりに
1. 前提条件と開発環境
本記事では、以下の環境で動作を確認しています。
- OS: Windows (WSL2)
- Git: v2.43.0
- Terraform: v1.14.4
- AWS CLI: v2.33.7
- AWS Provider: v6.32.1
- 使用リージョン: ap-northeast-1 (東京)
2. システムアーキテクチャ
今回構築するシステム構成は以下の内容です。
構成のポイント
- AWSネイティブなCI/CD
AWS CodeCommit（以下、CodeCommit）、AWS CodeBuild（以下、CodeBuild）、AWS CodePipeline（以下、CodePipeline）の連携により、AWS上でCI/CDパイプラインを完結。 - 承認ベースのデプロイ
terraform plan結果を確認した後に手動承認を行うフロー。 - カスタム通知の実装
「特定ユーザーへのメンション」や「整形されたメッセージ」の通知設定をAmazon EventBridge（以下、EventBridge）、AWS Lambda（以下、Lambda）、Amazon SNS（以下、SNS）、Amazon Q Developer（旧称：AWS Chatbot、以下Chatbot）の連携で実現。
3. 構築①：tfstateとロック制御管理リソースの作成
Stateファイル管理のベストプラクティス
Terraformでインフラを管理する上で、Stateファイル（terraform.tfstate）の扱いは重要です。
AWSの公式ブログでは、以下の管理方法が推奨されています。
1. リモートバックエンドでの管理（S3）：StateファイルをローカルPCではなく、耐久性の高いS3バケットで集中管理することで、チーム間での共有を容易にし、紛失リスクを低減します。
2. 排他制御の実装（DynamoDB）：複数のユーザーやパイプラインが同時にterraform applyを実行してStateファイルが破損するのを防ぐため、DynamoDBを使用してStateファイルのロック管理を行います。
3. 機密情報の保護：Stateファイルにはリソースのパスワードなどが平文で含まれる場合があるため、S3の暗号化機能を有効にして保存します。
S3バケットとDynamoDBテーブルの作成
ディレクトリ構造
3章では以下のディレクトリを作成し、必要なファイルを配置していきます。
terraform-cicd └──backend_infra/ ├── main.tf # S3とDynamoDBのリソース定義 ├── variables.tf # バケット名などの変数 ├── output.tf # 作成したバケット名の出力 └── backend.tf # 最初は空、またはコメントアウト
リソースの定義
ここでは、検証のためバージョニング等の設定はせずにS3バケットとDynamoDBテーブルを定義します。
backend_infra/main.tf
provider "aws" {
region = var.region
}
--- State保存用のS3バケット ---
resource "aws_s3_bucket" "terraform_state" {
bucket = "${var.name}-tfstate" #グローバルで一意な名前にする
}
--- ロック制御用のDynamoDBテーブル ---
resource "aws_dynamodb_table" "terraform_locks" {
name = "${var.name}-tflock"
billing_mode = "PAY_PER_REQUEST"
hash_key = "LockID"
attribute {
name = "LockID"
type = "S"
}
}
backend_infra/variables.tf
variable "name" {
type = string
description = "プロジェクトの識別名"
default = "mytest" # 好きな識別名を定義
}
variable "region" {
type = string
default = "ap-northeast-1" # 構築するリージョンを定義
}
backend_infra/output.tf
output "state_bucket_name" {
value = aws_s3_bucket.terraform_state.id
}
output "dynamodb_table_name" {
value = aws_dynamodb_table.terraform_locks.name
}
上記の定義が完了したら、以下のコマンドでコードをAWS環境に適用します。
ここでは、まだS3バケットが存在しないため、まずはローカルにtfstateを置いた状態でリソースを作成します。
cd ~/terraform-cicd/backend_infra terraform init # Terraform初期化 terraform plan # 作成されるリソースを確認 terraform apply # AWS環境へのコード適用
バックエンド設定の追記
S3バケットとDynamoDBテーブルが作成されたら、それらをtfstateとロック管理の保存先として指定します。
backend_infra/backend.tf
terraform {
backend "s3" {
bucket = "mytest-tfstate" # main.tfで定義したバケット名
key = "backend/terraform.tfstate"
region = "ap-northeast-1"
dynamodb_table = "mytest-tflock" # main.tfで定義したテーブル名
encrypt = true
}
}
ステートファイル管理先の変更
-reconfigureを付けて初期化コマンドを実行し、ローカルのtfstateファイルをS3へ転送します。
terraform init -reconfigure
ここまでの手順で、State管理用のS3バケットとロック管理用DynamoDBテーブルの作成、およびリモートでのState管理の土台が完成しました。
次章では、CodeCommitリポジトリを作成していきます。
4. 構築②：AWS CodeCommit（SSH接続設定とリポジトリ作成）
CodeCommitリポジトリの作成
本章では、Terraformのソースコードを管理するためのリポジトリを作成します。
最終的には以下のディレクトリ構造となり、3つのリポジトリが必要となります。
今回は管理や修正を疎結合で行えるよう、それぞれ個別のリポジトリで管理するように構成します。
terraform-cicd/ # ルートディレクトリ ├── backend_infra # バックエンド用 ├── cicd # CI/CD用 └── app_infra # Terraformで実際に構築したいリソース定義用
リポジトリの定義
まず、cicd/ ディレクトリ配下に codecommit.tfを作成し、3つのリポジトリを定義します。
cicd/codecommit.tf
1. バックエンド構築用コードのリポジトリ
resource "aws_codecommit_repository" "backend_infra" { repository_name = "${var.name}-backend-infra" }2. CI/CD基盤自体のコードのリポジトリ
resource "aws_codecommit_repository" "cicd_infra" { repository_name = "${var.name}-cicd-infra" }3. Terraformで実際に構築したいインフラ用のリポジトリ（パイプラインの監視対象）
resource "aws_codecommit_repository" "app_infra" { repository_name = "${var.name}-app-infra" }
cicd/provider.tfを作成し、構築先リージョンを定義します。
cicd/provider.tf
provider "aws" {
region = var.region
}
cicd/variables.tfを作成し、変数を定義します。
cicd/variables.tf
variable "name" {
type = string
description = "プロジェクトの識別名"
default = "mytest" # 好きな識別名を定義
}
variable "region" {
type = string
default = "ap-northeast-1" # 構築先リージョン
}
後から確認しやすくするため、以下のようにリポジトリへの接続URLをcicd/output.tfに定義しておきます。
cicd/output.tf
output "codecommit_backend_clone_url_ssh" {
value = aws_codecommit_repository.backend_infra.clone_url_ssh
}
output "codecommit_cicd_clone_url_ssh" {
value = aws_codecommit_repository.cicd_infra.clone_url_ssh
}
output "codecommit_app_clone_url_ssh" {
value = aws_codecommit_repository.app_infra.clone_url_ssh
}
3章で作成したバックエンド管理先を指定するため、以下をcicd/backend.tfに定義します。
cicd/backend.tf
terraform {
backend "s3" {
bucket = "mytest-tfstate" # 3章で作成したバケット名
key = "cicd/terraform.tfstate" # backend_infra/backend.tfとは別のパスを指定
region = "ap-northeast-1"
dynamodb_table = "mytest-tflock" # 3章で作成したテーブル名
encrypt = true
}
}
ここまで定義できたら、以下のコマンドを実行してAWS上に3つの空リポジトリを作成します。
cd ~/terraform-cicd/cicd terraform init terraform plan terraform apply
SSHによるCodeCommit接続設定
CodeCommitへの接続にはHTTPSとSSHがありますが、今回は一度設定すれば接続時のユーザ名/パスワード入力の手間が省けるためSSH接続を使用します。
参考ドキュメント：https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/setting-up-ssh-unixes.html
Step1：SSHキーペアの作成（ローカルPC）
ターミナルで以下のコマンドを実行し、CodeCommit接続用のキーペアを生成します。
cd ~/.ssh ssh-keygen -t rsa -b 4096以下のようにオプションの設定値を聞かれるため、任意で設定してください。ここでは、キーペア名のみ設定しています。
Generating public/private rsa key pair. Enter file in which to save the key (/home/user-name/.ssh/id_rsa):codecommit_rsa Enter passphrase (empty for no passphrase): Enter same passphrase again:
Step2: IAMユーザーへの公開鍵登録
次のコマンドを使用して、公開鍵の内容を確認してコピーします。
cat ~/.ssh/codecommit_rsa.pub出力例
ssh-rsa EXAMPLE-AfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMCVVMxCzAJB gNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb2 5zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhc NMTEwNDI1MjA0NTIxWhcNMTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAw DgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDAS=EXAMPLE user-name@ip-192-0-2-137
AWSコンソールのIAM > ユーザー > [対象ユーザ] > セキュリティ認証情報 タブを開きます。
AWS CodeCommitのSSH公開キーセクションで、SSH公開キーのアップロードをクリックし、コピーした内容を貼り付けます。
アップロード後に表示されるSSHキーIDを控えておいてください。
Step3: ローカルのSSH設定ファイルの編集
~/.ssh/config ファイルを作成（または編集）し、接続情報を記述します。
~/.ssh/config
Host git-codecommit.*.amazonaws.com User [Step2で控えたSSHキーID] IdentityFile ~/.ssh/codecommit_rsa # Step2で作成した秘密鍵のパス
ファイルの権限を適切に設定します。
chmod 600 ~/.ssh/config
Step4: 接続確認
以下のコマンドを実行し、正常に認証されるか確認します。
ssh git-codecommit.ap-northeast-1.amazonaws.com
「You have successfully authenticated over SSH.~」というメッセージが表示されれば成功です。
リポジトリにコードをpushする
SSH接続が完了したので、先ほど作成した/backend_infraのコードをPushします。
pushするディレクトリへ移動
cd ~/terraform-cicd/backend_infraGitリポジトリの初期化
git init.gitignoreの作成
cat < .gitignore .terraform/ *.tfstate *.tfstate.backup .terraform.lock.hcl EOFファイルのステージングとコミット
git add . git commit -m "Initial commit: backend infrastructure"SSH形式のURLを指定して登録（リポジトリ名は自身の設定に合わせてください）
git remote add origin ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/mytest-backend-infraブランチ名をmainに変更してPush
git branch -m main git push -u origin main
ここまでの手順で、CodeCommitリポジトリの作成と3章で作成したバックエンド管理インフラのコードをCodeCommitにPushしました。
次章では、実際にCI/CDパイプラインをTerraformで構築していきます。
5. 構築③：CI/CDパイプラインと承認フローの統合（CodeBuild / CodePipeline）
本章では、CodeCommitにPushされたコードを検知し、自動でterraform planを実行し、手動で承認した時のみterraform applyが走る仕組みを構築します。
構成の概要
パイプラインは以下の４つのステージで構成します。
1. Source: CodeCommitのapp_infraリポジトリから最新コードを取得。
2. Build（Plan）: CodeBuildでterraform planを実行。
3. Approve: レビュー担当者による手動承認。
4. Deploy（Apply）: 承認されたらCodeBuildでterraform applyを実行。
BuildSpecファイルの作成
CodeBuildが実行する手順書として、2つのyamlファイルをapp_infra/に配置します。
/app_infra/buildspec_plan.yml
version: 0.2
phases:
install:
commands:
- tf_version="1.14.4" # 使用するバージョン
- wget https://releases.hashicorp.com/terraform/${tf_version}/terraform_${tf_version}_linux_amd64.zip
- unzip terraform_${tf_version}_linux_amd64.zip
- mv terraform /usr/local/bin/
pre_build:
commands:
- terraform init
build:
commands:
plan結果を 'tfplan' というファイル名で書き出す
- terraform plan -out=tfplan artifacts:
次のステージ（Apply）に引き継ぐファイルを指定
files: - tfplan - "*.tf" - buildspec_apply.yml/app_infra/buildspec_apply.yml
version: 0.2
phases:
install:
commands:
- tf_version="1.14.4" # Terraformバージョン
- wget https://releases.hashicorp.com/terraform/${tf_version}/terraform_${tf_version}_linux_amd64.zip
- unzip terraform_${tf_version}_linux_amd64.zip
- mv terraform /usr/local/bin/
pre_build:
commands:
- terraform init
build:
commands:
前のステージで作られた plan 結果をそのまま適用する
- terraform apply -auto-approve tfplan
権限の定義
次に
cicd/配下にリソースを定義していきます。
CI/CDの各リソースが操作を実行するための権限をcicd/iam.tfに定義します。
cicd/iam.tf--- CodePipeline用 IAMロール ---
resource "aws_iam_role" "codepipeline_role" { name = "${var.name}-pipeline-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "codepipeline.amazonaws.com" } }] }) } resource "aws_iam_role_policy" "codepipeline_policy" { name = "${var.name}-codepipeline_policy" role = aws_iam_role.codepipeline_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = ["s3:GetObject", "s3:PutObject", "s3:GetBucketVersioning"] Resource = [aws_s3_bucket.pipeline_artifacts.arn, "${aws_s3_bucket.pipeline_artifacts.arn}/"] Effect = "Allow" }, { Action = ["codebuild:BatchGetBuilds", "codebuild:StartBuild"] Resource = "" Effect = "Allow" }, { Action = ["codecommit:GetBranch", "codecommit:GetCommit", "codecommit:UploadArchive", "codecommit:GetUploadArchiveStatus", "codecommit:CancelUploadArchive"] Resource = "" # 本来はCodeCommitのリポジトリARNに絞るのがベストですが、検証のため""としています。 Effect = "Allow" } ] }) }--- CodeBuild用 IAMロール ---
resource "aws_iam_role" "codebuild_role" { name = "${var.name}-codebuild-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "codebuild.amazonaws.com" } }] }) } resource "aws_iam_role_policy" "codebuild_policy" { name = "${var.name}-codebuild_policy" role = aws_iam_role.codebuild_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"] Resource = "" Effect = "Allow" }, { Action = ["s3:GetObject", "s3:PutObject", "s3:GetBucketVersioning"] Resource = [aws_s3_bucket.pipeline_artifacts.arn, "${aws_s3_bucket.pipeline_artifacts.arn}/"] Effect = "Allow" },TerraformがStateファイルを読むためにbackend用S3へのアクセスも必要
{ Action = ["s3:ListBucket", "s3:GetObject", "s3:PutObject"] Resource = ["arn:aws:s3:::${var.name}-tfstate", "arn:aws:s3:::${var.name}-tfstate/"] Effect = "Allow" }, { Action = ["dynamodb:DescribeTable", "dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:DeleteItem"] Resource = "arn:aws:dynamodb:ap-northeast-1::table/${var.name}-tflock" Effect = "Allow" },↓ ここにTerraformで操作したいリソース（VPC等）の権限を追加
{ Action = [""] Resource = "" Effect = "Allow" } ] }) }EventBridge用IAM ロール
resource "aws_iam_role" "eventbridge_role" { name = "${var.name}-eventbridge-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "events.amazonaws.com" } }] }) } resource "aws_iam_role_policy" "event_bridge_policy" { name = "${var.name}-eventbridge-policy" role = aws_iam_role.eventbridge_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "codepipeline:StartPipelineExecution" Resource = aws_codepipeline.terraform_pipeline.arn Effect = "Allow" }] }) }自動起動用のEventBridgeの定義
CodeCommitへのPushを検知してパイプラインを起動させるため、
cicd/eventbridge.tfを定義します。
cicd/eventbridge.tfEventBridge ルール: CodeCommit の変更を検知
resource "aws_cloudwatch_event_rule" "pipeline_trigger" { name = "${var.name}-trigger-rule" description = "Trigger CodePipeline when code is pushed to CodeCommit main branch" event_pattern = jsonencode({ source = ["aws.codecommit"] detail-type = ["CodeCommit Repository State Change"] resources = [aws_codecommit_repository.app_infra.arn] detail = { event = ["referenceCreated", "referenceUpdated"] referenceType = ["branch"] referenceName = ["main"] } }) }EventBridge ターゲット: ルール検知時に CodePipeline を起動
resource "aws_cloudwatch_event_target" "pipeline_target" { rule = aws_cloudwatch_event_rule.pipeline_trigger.name target_id = "TriggerCodePipeline" arn = aws_codepipeline.terraform_pipeline.arn role_arn = aws_iam_role.eventbridge_role.arn }パイプライン用S3の定義
パイプラインの動作中に、データの受け渡しを行うため、
cicd/s3.tfを定義します。
cicd/s3.tfresource "aws_s3_bucket" "pipeline_artifacts" { bucket = "${var.name}-pipeline-artifacts" force_destroy = true }CodeBuildプロジェクトの定義
cicd/codebuild.tfを作成し、以下のように２つのCodeBuildプロジェクトを定義します。
cicd/codebuild.tf--- 共通の環境設定） ---
locals { builder_image = "aws/codebuild/amazonlinux2-x86_64-standard:5.0" }1. Terraform Plan用プロジェクト
resource "aws_codebuild_project" "terraform_plan" { name = "${var.name}-tf-plan" service_role = aws_iam_role.codebuild_role.arn artifacts { type = "CODEPIPELINE" } environment { compute_type = "BUILD_GENERAL1_SMALL" image = local.builder_image type = "LINUX_CONTAINER" privileged_mode = false } source { type = "CODEPIPELINE" buildspec = "buildspec_plan.yml" # 先ほど作成した実行手順書を指定 } }2. Terraform Apply用プロジェクト
resource "aws_codebuild_project" "terraform_apply" { name = "${var.name}-tf-apply" service_role = aws_iam_role.codebuild_role.arn artifacts { type = "CODEPIPELINE" } environment { compute_type = "BUILD_GENERAL1_SMALL" image = local.builder_image type = "LINUX_CONTAINER" privileged_mode = false } source { type = "CODEPIPELINE" buildspec = "buildspec_apply.yml" # 先ほど作成した実行手順書を指定 } }CodePipelineの定義
各ステージを繋ぎ合わせるためにCodePipelineを作成します。今回は手動承認ステージとしてApprovalステージを作成します。
cicd/codepipeline.tfresource "aws_codepipeline" "terraform_pipeline" { name = "${var.name}-pipeline" role_arn = aws_iam_role.codepipeline_role.arn artifact_store { location = aws_s3_bucket.pipeline_artifacts.bucket type = "S3" }--- Stage 1: Source (CodeCommitから取得) ---
stage { name = "Source" action { name = "Source" category = "Source" owner = "AWS" provider = "CodeCommit" version = "1" output_artifacts = ["source_output"] configuration = { RepositoryName = aws_codecommit_repository.app_infra.repository_name BranchName = "main"EventBridgeを使用して検知するためポーリングはオフにする
PollForSourceChanges = "false" } } }--- Stage 2: Plan (CodeBuildで実行) ---
stage { name = "Plan" action { name = "Terraform-Plan" category = "Build" owner = "AWS" provider = "CodeBuild" version = "1" input_artifacts = ["source_output"] output_artifacts = ["plan_output"] configuration = { ProjectName = aws_codebuild_project.terraform_plan.name } } }--- Stage 3: Approval (手動承認待ち) ---
stage { name = "Approval" action { name = "Terraform-Approval" category = "Approval" owner = "AWS" provider = "Manual" version = "1" } }--- Stage 4: Apply (CodeBuildで実行) ---
stage { name = "Apply" action { name = "Terraform-Apply" category = "Build" owner = "AWS" provider = "CodeBuild" version = "1" input_artifacts = ["plan_output"] configuration = { ProjectName = aws_codebuild_project.terraform_apply.name } } } }デプロイと動作確認
ここまでのコード作成が完了したら、CI/CDパイプラインをデプロイし、実際に実行されるかを確認します。
Step1: パイプライン基盤のデプロイ
cicd/ディレクトリで、定義したリソースをAWS上に構築します。cd ~/terraform-cicd/cicd terraform plan terraform apply
Step2: app_infraのバックエンド設定
次に、実際にパイプラインを使用して構築したいリソースを定義する
app_infra/の状態管理を、3章で作成したS3バケットおよびDynamoDBテーブルで行うように設定します。
app_infra/backend.tfterraform { backend "s3" { bucket = "mytest-tfstate" # 3章で作成したバケット名 key = "app-infra/terraform.tfstate" # backend_infraとは別のパスを指定 region = "ap-northeast-1" dynamodb_table = "mytest-tflock" # 3章で作成したテーブル名 encrypt = true } }Step3: テスト用リソースの追加とPush
app_infra/でも変数を使用できるよう、variables.tfを作成します。
app_infra/variables.tfvariable "name" { type = string description = "プロジェクトの識別名" default = "mytest" } variable "region" { type = string default = "ap-northeast-1" # 構築するリージョンを定義 }app_infra/provider.tfも以下のように定義します。
app_infra/provider.tfprovider "aws" { region = var.region }パイプラインの動作を確認するため、app_infraにテスト用リソースを追加してPushしてみます。
例えば、main.tfに以下のS3バケットを作成します。
app_infra/main.tfresource "aws_s3_bucket" "test_app_bucket" { bucket = "${var.name}-test-bucket" # グローバルでユニークな値 force_destroy = true tags = { Name = "TriggerTest" } }ローカルで
terraform planを確認したい場合
基本的にはgit pushすればCodeBuildが実行してくれますが、Pushする前にローカルでPlanして確認したい場合は、app_infraディレクトリでterraform initを実行すれば、ローカルでもterraform planが可能になります。
ただし、チームで開発する際には「ローカルではPlanまで」を実行し、「Applyはパイプライン」をルール化することが必要になります。ここまで準備ができたら、修正したファイルをCodeCommitへPushします。
cd ~/terraform-cicd/app_infra git init
4章と同様に.gitignoreを作成
cat < .gitignore .terraform/ *.tfstate *.tfstate.backup .terraform.lock.hcl EOF git add . git commit -m "Setup: app_infra with backend and test bucket" git remote add origin ssh://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/mytest-app-infra #4章で作成したリポジトリのURL git branch -m main git push -u origin mainAWSコンソールのCodePipeline画面を開き、以下の流れを確認します。
1. Source: Push検知により自動で起動
2. Build(Plan):terraform planが実行される
3. Approval: ステータスが「承認待ち」で停止するStep5: 手動承認と適用
Build(Plan)を実行したCodeBuildのログから、
terraform planの実行結果を確認します。
問題なければ、CodePipelineのApprovalステージを承認することでDeploy(Apply)が実行され、実際にS3バケットが作成されます。本章のまとめ
ここまでの作業で、app_infraにAWSリソースを定義し、コードをPushすることで自動でPlan→手動承認→Applyが実行されるパイプラインが完成しました。
しかし、現状ではコンソールを確認しないと承認待ちに気づけないという不便さがあります。
次章以降では、EventBridge、Lambda、SNS、ChatbotによるSlackへのメンション付きメッセージ送信の仕組みを構築していきます。
6. 構築④：メンション付きSlack通知の実装（EventBridge / Lambda / Chatbot）
構成の概要
- EventBridge: パイプラインが「承認待ち」になったイベントを検知。
- Lambda: イベント情報をメンションを含めた形に整形。
- SNS: 整形されたメッセージをChatbotへ中継。
- Chatbot: Slackの特定チャンネルへ通知。
IAMロールの定義
LambdaとChatbotが動作するために必要な権限を
cicd/iam.tfに追記します。
cicd/iam.tfLambda用ロール
resource "aws_iam_role" "lambda_notification_role" { name = "${var.name}-lambda-notification-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "lambda.amazonaws.com" } }] }) } resource "aws_iam_role_policy" "lambda_notification_policy" { name = "${var.name}-lambda-notification-policy" role = aws_iam_role.lambda_notification_role.id policy = jsonencode({ Version = "2012-10-17" Statement = [ { Action = "sns:Publish" Resource = aws_sns_topic.pipeline_notification.arn Effect = "Allow" }, { Action = ["logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents"] Resource = "*" Effect = "Allow" } ] }) }Chatbot用ロール
resource "aws_iam_role" "chatbot_role" { name = "${var.name}-chatbot-role" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "chatbot.amazonaws.com" } }] }) } resource "aws_iam_role_policy_attachment" "chatbot_read_only" { role = aws_iam_role.chatbot_role.name policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess" # Slackで状態を表示するために必要 }Lambdaの定義
メッセージ整形用のPythonコードと、Lambdaリソースを定義します。
cicd/lambda/message_formatting.pyを作成し、以下のコードを記述します。
cicd/lambda/message_formatting.pyimport json import boto3 import os sns = boto3.client('sns') def lambda_handler(event, context): raw_ids = os.environ.get('SLACK_MENTION_IDS', '') if raw_ids:
IDが複数あればリストにして渡す
mentions = [f"<@{i.strip()}>" for i in raw_ids.split(',')]スペース区切りで結合 ("<@U123> <@U456>")
mention_string = " ".join(mentions) else: mention_string = "" detail = event.get('detail', {}) pipeline_name = detail.get('pipeline', 'Unknown') stage = detail.get('stage', 'Unknown') state = detail.get('state', 'Unknown')Slackで表示したいテキスト（メンション込み）
main_text = f"{mention_string}n【Pipeline Notification】nPipeline: {pipeline_name}nStage: {stage}nStatus: {state}" if stage == "Approval": region = event.get('region', 'ap-northeast-1') link = f"https://{region}.console.aws.amazon.com/codesuite/codepipeline/pipelines/{pipeline_name}/view" main_text += f"n承認が必要です。確認してください: {link}"--- JSON構造を作成 ---
custom_message = { "version": "1.0", "source": "custom", "content": { "title": f"CodePipeline Approval: {pipeline_name}", "description": main_text } } try: response = sns.publish( TopicArn=os.environ['TARGET_SNS_ARN'],JSON文字列として送信
Message=json.dumps(custom_message) ) print(f"Response: {response}") except Exception as e: print(f"Error publishing to SNS: {str(e)}") raise ecicd/notifications.tfを作成し、以下のようにLambda関数を定義します。
cicd/notifications.tfdata "archive_file" "lambda_zip" { type = "zip" source_file = "${path.module}/lambda/message_formatting.py" output_path = "${path.module}/lambda/lambda_function.zip" } resource "aws_lambda_function" "approval_notification" { filename = data.archive_file.lambda_zip.output_path source_code_hash = data.archive_file.lambda_zip.output_base64sha256 function_name = "${var.name}-approval-notification" role = aws_iam_role.lambda_notification_role.arn handler = "message_formatting.lambda_handler" runtime = "python3.12" environment { variables = { TARGET_SNS_ARN = aws_sns_topic.pipeline_notification.arn SLACK_MENTION_IDS = join(",", var.slack_mention_ids) } } }メッセージに含めるメンション先ユーザーIDを変数として定義します。
cicd/variables.tfvariable "slack_mention_ids" { type = list(string) default = [ "UXXXXXXXXXX" # SlackのメンバーID（複数可） ] }EventBridgeの定義
承認ステージが開始されたタイミングでLambdaを起動するルールを追記します。
cicd/notifications.tfresource "aws_cloudwatch_event_rule" "approval_needed" { name = "${var.name}-approval-needed-rule" description = "Trigger Lambda when CodePipeline reaches Approval stage" event_pattern = jsonencode({ source = ["aws.codepipeline"] detail-type = ["CodePipeline Action Execution State Change"] detail = { pipeline = ["${var.name}-pipeline"] # パイプライン名を指定 stage = ["Approval"] state = ["STARTED"] } }) } resource "aws_cloudwatch_event_target" "lambda_target" { rule = aws_cloudwatch_event_rule.approval_needed.name target_id = "SendToLambda" arn = aws_lambda_function.approval_notification.arn } resource "aws_lambda_permission" "allow_eventbridge" { statement_id = "AllowExecutionFromEventBridge" action = "lambda:InvokeFunction" function_name = aws_lambda_function.approval_notification.function_name principal = "events.amazonaws.com" source_arn = aws_cloudwatch_event_rule.approval_needed.arn }SNS、Chatbotの定義
最後に、Slackへのメッセージ送信を行うSNSとChatbotを定義します。
cicd/notifications.tfresource "aws_sns_topic" "pipeline_notification" { name = "${var.name}-pipeline-notification" } resource "aws_sns_topic_policy" "pipeline_notification_sns_policy" { arn = aws_sns_topic.pipeline_notification.arn policy = jsonencode({ Version = "2012-10-17" Statement = [ { Sid = "AllowPublishFromLambda" Effect = "Allow" Principal = { AWS = aws_iam_role.lambda_notification_role.arn } Action = "SNS:Publish" Resource = aws_sns_topic.pipeline_notification.arn }, { Sid = "AllowChatbotToSubscribe" Effect = "Allow" Principal = { Service = "chatbot.amazonaws.com" } Action = [ "SNS:Subscribe", "SNS:Receive", "SNS:GetTopicAttributes" ] Resource = aws_sns_topic.pipeline_notification.arn } ] }) } resource "aws_chatbot_slack_channel_configuration" "slack" { configuration_name = "${var.name}-slack-config" iam_role_arn = aws_iam_role.chatbot_role.arn slack_channel_id = var.slack_channel_id # 通知先のSlackチャンネルID slack_team_id = var.slack_team_id # 通知先のSlackワークスペースID sns_topic_arns = [aws_sns_topic.pipeline_notification.arn] }cicd/variables.tf
variable "slack_channel_id" { type = string default = "CXXXXXXXXXX" # 通知先のSlackチャンネルID } variable "slack_team_id" { type = string default = "TXXXXXXXXXX" # 通知先のSlackワークスペースID }ここまででコードの実装は完了となります。
最後に、以下のコマンドで通知基盤をデプロイします。Terraformを実行する前に（または実行後に）、AWSコンソールの AWS Chatbot (Amazon Q Developer) 画面から、通知先の Slack ワークスペースを認証（クライアント設定） しておく必要があります。
cd ~/terraform-cicd/cicd terraform plan terraform apply
動作確認
通知基盤の実装は完了したため、
app_infra/のコードを変更してPushしてみましょう。
ここまで正しく設定されていれば、設定したSlackチャンネルにメンション付きでメッセージが送信されるはずです。
7. おわりに
この記事では、Terraformを用いたCI/CDパイプラインの構築方法をご紹介しました。
実際に構築してみると、開発者が複数人いる場合や大規模な構築において、CodeCommitでのバージョン管理や管理者によるレビューといったルールに沿ってCI/CDを実行できる点で優れていると感じました。
今回の構築経験を活かして、今後の業務でも活用していきたいと思います。
簡単30秒