Terraform を学ぶ初心者がよく犯す最大の間違いのひとつは、自分のローカルマシンをデプロイサーバーとして扱うことです。

典型的なワークフローは次のようになります。

terraform init
terraform plan
terraform apply

Enter fullscreen mode Exit fullscreen mode

このアプローチは学習目的としては完全に問題ありませんが、複数のエンジニアが関わる実務プロジェクトではすぐに問題が生じます。

次の点を考えてみてください。

  • 誰がインフラをデプロイしたのか？
  • デプロイ前にインフラはレビューされたのか？
  • 他の誰かが同じデプロイを再現できるか？
  • エンジニアのノートPC が紛失したり設定ミスしたりしたらどうなるか？
  • 実際に何が変更されたのか正確に把握できるか？

これらは、プロフェッショナルな環境で Infrastructure as Code (IaC) がほぼ必ず Continuous Integration / Continuous Deployment (CI/CD) パイプラインと統合される理由です。

本記事では、GitHub Actions を用いてシンプルな Terraform CI/CD パイプラインを構築します。YAML 構文に焦点を当てるだけでなく、各ステージがなぜ存在し、安全で再現可能なインフラデプロイを実現するためにどのように連携するのかを最初に理解します。

Terraform CI/CD とは？

Terraform CI/CD とは、Terraform コードに変更が加えられたときに、インフラの検証・計画・デプロイを自動化するプロセスです。

開発者のノートPC から手動で Terraform コマンドを実行する代わりに、CI/CD プラットフォームが制御された環境でそれらのコマンドを自動実行します。

ワークフローは通常次のようになります。

Developer
      │
      ▼
Git Push
      │
      ▼
GitHub Repository
      │
      ▼
GitHub Actions
      │
      ▼
Terraform Init
      │
      ▼
Terraform Validate
      │
      ▼
Terraform Plan
      │
      ▼
Manual Approval
      │
      ▼
Terraform Apply
      │
      ▼
AWS Infrastructure

Enter fullscreen mode Exit fullscreen mode

このアプローチにより、一貫性・可視性・セキュリティが向上し、人為的ミスの可能性を低減できます。

Terraform を手動で実行しない理由

ノートPC から Terraform を実行するのは個人プロジェクトでは問題ありませんが、チーム環境ではいくつかのリスクが生じます。

手動デプロイ CI/CD デプロイ
すべてのコマンドを記憶する必要がある 自動で実行される
検証をスキップしやすい 検証が強制される
デプロイの追跡が難しい すべてのデプロイがログに記録される
認証情報が開発者のノートPC に残る シークレットは安全に保管される
マシンごとに Terraform のバージョンが異なる 一貫した実行環境が提供される

自動化により、誰が変更を行ったかに関わらず、すべてのインフラ変更が同じプロセスに従うようになります。

作成するもの

目標は、2 つの独立した GitHub Actions ワークフローを作成することです。

ワークフロー 1 – Continuous Integration (CI)

このワークフローは、Terraform コードの品質を次のコマンドでチェックします。

  • terraform fmt
  • terraform init
  • terraform validate
  • terraform plan

このワークフローはインフラを作成しません。

その役割は、提案された変更が安全かつ有効であるかどうかを判断することだけです。

ワークフロー 2 – Deployment

デプロイワークフローはインフラの作成または更新を担当します。

Terraform plan が受け入れ可能であると判断した後にのみ実行されます。

この分離は重要なベストプラクティスです。インフラ変更のレビューは、アプリケーショコードのレビューと同様に重要だからです。

プロジェクト構造

リポジトリは次のようになります。

terraform-github-actions/
│
├── .github/
│   └── workflows/
│       ├── terraform-ci.yml
│       └── terraform-deploy.yml
│
├── main.tf
├── variables.tf
├── outputs.tf

Enter fullscreen mode Exit fullscreen mode

CI とデプロイのワークフローを分離しておくことで、プロジェクトの成長に伴う理解・保守・拡張が容易になります。

CI パイプラインの理解

CI ワークフローは次の 1 つの質問に答える責任を負います。

「この Terraform コードはデプロイ可能か？」

この質問に答えるために、いくつかのチェックを実行します。

手順 1: フォーマットの確認

Terraform は一貫したコーディングスタイルを強制します。

次のコマンドを実行します。

terraform fmt -check

Enter fullscreen mode Exit fullscreen mode

これにより、すべてのコントリビューターが同じフォーマット基準に従うことを保証できます。

手順 2: Terraform の初期化

Terraform がインフラを検証または計画するには、必要なプロバイダーをダウンロードし、作業ディレクトリを初期化する必要があります。

これは次のコマンドで行います。

terraform init

Enter fullscreen mode Exit fullscreen mode

手順 3: 構成の検証

次に、Terraform は構成が構文的に正しいことを確認します。

terraform validate

Enter fullscreen mode Exit fullscreen mode

これにより、デプロイ前に欠落した引数、無効な参照、その他の構成の問題を検出できます。

手順 4: 実行計画の生成

最後に、Terraform は実行計画を生成します。

terraform plan

Enter fullscreen mode Exit fullscreen mode

計画は、変更を加えることなく Terraform が実行しようとしている内容を正確に示します。

例：

  • 作成されるリソース
  • 更新されるリソース
  • 破棄されるリソース

この出力をレビューすることは、Infrastructure as Code ワークフローにおける最も重要な作業の 1 つです。

CI とデプロイの分離

学生からよく寄せられる質問のひとつに次のようなものがあります。

「CI ワークフローがすでに terraform plan を実行しているのに、なぜ別のデプロイワークフローが必要なのか？」

答えはシンプルです。

CI ワークフローはインフラを検証するために設計されています。

デプロイワークフローはインフラを変更するために設計されています。

これらの責任を分離することで、チームはデプロイのタイミングをより細かく制御できます。

典型的なプロセスは次のようになります。

Push Code
     │
     ▼
CI Pipeline
     │
     ▼
Plan Generated
     │
     ▼
Engineer Reviews Changes
     │
     ▼
Deployment Triggered
     │
     ▼
Terraform Apply

Enter fullscreen mode Exit fullscreen mode

このアプローチにより、偶発的なデプロイを防ぎ、適切な変更レビューの実施を促します。

AWS 認証情報の安全な管理

初心者がよく犯す間違いの 1 つは、AWS の認証情報を Terraform コードや GitHub ワークフローにハードコードすることです。

決して行わないでください。

代わりに、GitHub は暗号化されたリポジトリシークレットを提供しており、ワークフロー実行中に安全にアクセスできます。

これにより、機密情報がソースコードやバージョン履歴に残ることを防げます。

今後の記事では、長期間有効な AWS アクセスキーを GitHub の OpenID Connect (OIDC) 統合に置き換え、AWS 認証情報を一切保存する必要をなくす方法をさらに詳しく説明します。

次回予告

本記事では、Terraform CI/CD の概念と、検証とデプロイを分離することがより安全なインフラ自動化につながる理由について解説しました。

次回の記事では、最初の GitHub Actions ワークフローをゼロから構築し、YAML ファイルの各行を理解し、AWS プロジェクト向けの Terraform 検証と計画を自動化します。

本シリーズの最終回までには、GitHub Actions と Terraform を用いてインフラを安全にデプロイできる、本番環境対応のパイプラインが完成します。

最後に

Terraform を学ぶことは、単に .tf ファイルを書くことだけではありません。

プロフェッショナルな Infrastructure as Code は、再現可能なプロセス、コードレビュー、安全な認証情報管理、および自動デプロイの上に構築されます。

GitHub Actions はこれらのプラクティスを実装するためのツールを提供し、Terraform はインフラをコードとして記述するための基盤を提供します。

この 2 つを組み合わせることで、チームは信頼性が高く、スケーラブルで、監査可能なクラウドインフラを構築できます。

DevOps の道を歩み始めたばかりの方にとって、このワークフローを習得することは最高の投資の 1 つとなるでしょう。

本記事で使用した完全なサンプルは、GitHub リポジトリで確認できます。

github repo