ようこそ、クラウド・アーキテクチャの深淵へ。私はあなたのガイドを務めるシニアSREエンジニアです。
これからあなたが踏み出す一歩は、単なる「自動化」ではありません。それは、インフラを「ソフトウェア」として扱い、職人の勘に頼っていた作業を「再現可能で、堅牢で、誰がやっても同じ結果が得られる」芸術へと昇華させるプロセスです。
手元のPCから`terraform apply`を叩くのは今日で終わりにしましょう。誰かがコマンドを打ち間違えたり、State（状態管理ファイル）が壊れたりする恐怖から解放される時が来ました。
今回は、GitHub Actionsを使って、Terraformの「計画（Plan）」と「適用（Apply）」を完璧に自動化する方法を伝授します。これができれば、あなたのチームの開発速度は劇的に向上し、インフラの信頼性は鉄壁のものになりますよ。
—
1. なぜ「手動Apply」は危険なのか？
プロフェッショナルな現場では、個人のPCから直接インフラを変更することは「禁忌」に近い行為です。
- Stateの不整合: AさんのPCとBさんのPCで、Terraformのバージョンや環境変数が違えば、インフラは一瞬で壊れます。
- 証跡の欠如: 「誰が、いつ、なぜこの変更をしたのか」がGitHubの履歴（プルリクエスト）に残らないと、トラブル時の復旧が不可能です。
- 権限管理の甘さ: 全員が管理者権限（Administrator）を持ち歩くのは、セキュリティ上の大きなリスクです。
これらを解決するのが、GitHub ActionsによるCI/CDパイプラインです。
—
2. 準備：信頼の基盤を作る
自動化の前に、プロとして絶対に外せない準備が2つあります。
① S3 + DynamoDB による「Stateの保護」
Terraformの状態管理ファイル（tfstate）は、必ずクラウド上の共有バケットに置きましょう。DynamoDBを組み合わせることで「排他制御（ロック）」をかけ、同時に二人以上が変更してStateが壊れるのを防ぎます。
backend.tf
terraform {
backend “s3” {
bucket = “my-terraform-state-bucket” # 事前に作成したS3バケット
key = “network/terraform.tfstate”
region = “ap-northeast-1”
dynamodb_table = “terraform-lock-table” # 排他制御用のDynamoDB
encrypt = true
}
}
② OIDCによる「パスワードレス認証」
GitHub ActionsにAWSやGoogle Cloudのアクセスキーを直接持たせるのは、古くて危険なやり方です。現在はOIDC（OpenID Connect）を使い、GitHub Actionsに対して「一時的な権限」を安全に貸し出すのが世界標準です。
—
3. 【実践】GitHub Actions ワークフローの実装
それでは、魂を込めたYAMLコードを解説します。このワークフローは、以下の2段階で動作します。
1. Planフェーズ: プルリクエスト（PR）を作ると、自動で差分を計算し、結果をPRのコメントに書き込みます。
2. Applyフェーズ: PRをメインブランチにマージすると、本番環境へ変更を適用します。
`.github/workflows/terraform.yml`
name: “Terraform Cloud Automation”
on:
push:
branches:
- main # mainブランチにマージされたらApply
pull_request: # PRが作成・更新されたらPlan
permissions:
id-token: write # OIDC認証に必要
contents: read # リポジトリ読み取り権限
pull-requests: write # PRにコメントを書き込む権限
jobs:
terraform:
name: “Terraform Workflow”
runs-on: ubuntu-latest
env:
TF_VERSION: “1.5.0” # バージョンを固定するのがプロの鉄則
steps:
# 1. コードのチェックアウト
- name: Checkout
uses: actions/checkout@v3
# 2. クラウドへの認証 (AWSを例にOIDCを使用)
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v2
with:
role-to-assume: arn:aws:iam::123456789012:role/github-actions-role
aws-region: ap-northeast-1
# 3. Terraform環境のセットアップ
- name: Setup Terraform
uses: hashicorp/setup-terraform@v2
with:
terraform_version: ${{ env.TF_VERSION }}
# 4. 初期化 (backendの接続確認)
- name: Terraform Init
run: terraform init
# 5. 書式チェック (汚いコードはマージさせない)
- name: Terraform Format Check
run: terraform fmt -check
# 6. 計画 (Plan) – PR時のみ実行
- name: Terraform Plan
id: plan
if: github.event_name == ‘pull_request’
run: terraform plan -no-color -input=false
continue-on-error: true # 失敗してもコメントを残すために続行
# 7. PRに結果をコメントする (レビューを楽にする魔法)
- name: Update Pull Request
uses: actions/github-script@v6
if: github.event_name == ‘pull_request’
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
const output = `
Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
Terraform Plan 📖\`${{ steps.plan.outcome }}\`
Show Plan Result
\`\`\`terraform
${{ steps.plan.outputs.stdout }}
\`\`\`
`;
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: output
})
# 8. 適用 (Apply) – mainブランチへのプッシュ（マージ）時のみ
- name: Terraform Apply
if: github.ref == ‘refs/heads/main’ && github.event_name == ‘push’
run: terraform apply -auto-approve -input=false
—
4. この設計の「極限の知見」ポイント
ただ動くだけのコードなら誰でも書けます。このワークフローに込めた、現場で差が出るポイントを解説しましょう。
1. `terraform fmt -check` の強制:
インフラコードがバラバラなフォーマットで書かれているのは、メンテナンスの地獄への入り口です。CIで書式をチェックし、美しくないコードは弾く。これが「割れ窓理論」を防ぐ第一歩です。
2. `-auto-approve` の扱い:
Applyフェーズでは対話的な入力ができないため、このフラグが必要です。しかし、それを許容するのは「PRでPlanの結果を人間がレビューした」というプロセスがあるからです。マージは慎重に行いましょう。
3. `continue-on-error` とコメント:
Planが失敗したときにジョブを止めるのではなく、あえて「どこが間違っているか」をPRにコメントさせるようにしています。これにより、開発者はログを探しに行く手間が省け、PR画面だけでデバッグを完結できます。
—
5. 動作確認：HelloWorldを越えて
さあ、この設定をリポジトリにコミットしたら、簡単なS3バケットを作るコードをPRで出してみてください。
1. PRを作成する: 数秒後にGitHub Actionsが動き出し、Botが「インフラの差分（Plan）」をPRに書き込んでくれます。
2. レビューする: 差分を見て「よし、意図通りだ」と確信したら、Approveしてマージします。
3. 自動Apply: マージされた瞬間に、本番環境へのデプロイが始まります。
これで、あなたは「指先一つで、世界中のデータセンターを安全に操る能力」を手に入れました。
最後に
TerraformとCI/CDの連携は、IaCの完成形です。最初は難しく感じるかもしれませんが、一度この快適さを知ると、もう二度と手動運用には戻れません。
「インフラはコードであり、コードは常にパイプラインを通ってデプロイされるべきである」。この原則を胸に、素晴らしい自動化ライフを楽しんでください。何かわからないことがあれば、いつでも聞いてくださいね。応援していますよ！