【図解】Terraformとは？使い始める前に知っておくべきこと

By /

【図解】Terraformとは？使い始める前に知っておくべきこと

はじめに：インフラ構築・管理の進化とIaCの台頭

現代のITシステムは、クラウドコンピューティングの普及により、より柔軟かつスケーラブルなインフラストラクチャの上で稼働しています。AWS、Azure、GCPといったパブリッククラウドや、Kubernetesのようなコンテナオーケストレーション基盤、VMwareのようなプライベートクラウドなど、多様なインフラが利用されています。

これらのインフラ環境を効率的に構築・管理することは、システム開発や運用において極めて重要な課題となっています。かつては、サーバーのセットアップやネットワーク構成、ミドルウェアのインストールなどを手動で行うのが一般的でした。しかし、この手法には多くの課題がありました。

  1. 手動作業によるミス: 人為的なミスが発生しやすく、設定漏れや誤りによる障害のリスクが高まります。
  2. 属人化: 特定の担当者しか環境構築の手順を知らず、知識やスキルが共有されにくい状況が生まれます。
  3. 再現性の低さ: 同じ環境を複数構築したり、開発・ステージング・本番といった異なる環境間で設定の整合性を保つのが困難です。
  4. 構築・変更に時間がかかる: 環境構築や変更のたびに手動で作業が必要となり、迅速な対応が難しくなります。
  5. 変更履歴の管理が困難: いつ、誰が、どのような変更を行ったかを追跡・管理するのが難しいです。

これらの課題を解決するために登場したのが、「Infrastructure as Code（IaC）」という考え方です。

【図解】IaC (Infrastructure as Code) とは？

IaCとは、インフラストラクチャ（サーバー、ネットワーク、ストレージ、アプリケーション設定など）をコードとして定義し、管理する手法のことです。これにより、ソフトウェア開発で当たり前になっているバージョン管理、自動テスト、CI/CDといったプラクティスをインフラ管理にも適用できるようになります。

図1：IaCがない場合とある場合の比較

  • IaCがない場合:

    • インフラ状態が「ドキュメントや担当者の頭の中」に散在。
    • 構築・変更は「手動作業」または「シェルスクリプトなどの簡易な自動化」。
    • 結果：「環境間の差異」「再現性の低さ」「変更の追跡困難」「属人化」「構築・変更に時間」。

  • IaCがある場合:

    • インフラ状態が「コードファイル」に集約され、バージョン管理システム（Gitなど）で管理。
    • 構築・変更は「IaCツールによる自動実行」。
    • 結果：「環境の統一性」「高い再現性」「変更履歴の追跡容易性」「属人化の解消」「迅速な構築・変更」。

IaCが解決する具体的な課題

  • 再現性の確保: コード化された定義ファイルを実行すれば、いつでも全く同じ環境を再現できます。これは、開発・テスト・本番環境の構築や、災害復旧（Disaster Recovery）において非常に重要です。
  • 効率化と迅速化: 手動作業が不要になるため、インフラの構築や変更にかかる時間を大幅に短縮できます。これにより、より頻繁に、より安全にインフラをアップデートすることが可能になります。
  • バージョン管理と変更履歴: コードとして管理されるため、Gitなどのバージョン管理システムを使って変更履歴を記録できます。これにより、誰がいつ何を変更したのかが明確になり、問題発生時の原因特定やロールバックが容易になります。
  • 属人化の解消と標準化: インフラ構成がコードとして共有されるため、特定の担当者に依存せず、組織全体でインフラ管理の知識やベストプラクティスを共有できます。また、コードレビューを通じて品質を向上させることも可能です。
  • テストと検証の容易化: コードなので、自動テストを導入して構成の妥当性を検証したり、一度構築した環境を破棄して再度構築するといったテストサイクルを素早く回せます。

IaCを実現するツール群

IaCツールには様々な種類があり、大きく分けて以下のカテゴリに分類できます。

  1. プロビジョニングツール: インフラリソース（仮想マシン、ネットワーク、ストレージ、データベースなど）を作成、設定、管理することを目的とします。Terraform、AWS CloudFormation、Azure Resource Manager、Google Cloud Deployment Managerなどがあります。これらは宣言的（Declarative）なアプローチを取ることが多いです。「最終的にどういう状態になっていてほしいか」を記述し、ツールがその状態を実現するための手順を考え実行します。
  2. 構成管理ツール: 既に存在するサーバー上で、OSの設定、ソフトウェアのインストール、サービスの起動設定など、サーバー内部の状態を管理することを目的とします。Ansible、Chef、Puppetなどがあります。これらは命令的（Imperative）なアプローチを取ることもあります。「この順序でこのコマンドを実行せよ」のように、状態に至るための具体的な手順を記述します。

Terraformは、前者のプロビジョニングツールに分類されます。そして、その最大の特長はマルチクラウド対応であることです。

【図解】Terraformとは？ – 基本概念

Terraformは、HashiCorp社が開発したオープンソースのIaCツールです。インフラストラクチャをコードとして定義し、様々なクラウドプロバイダーやサービス上にリソースを安全かつ効率的に構築、変更、バージョン管理できます。

図2：Terraformの基本概念とワークフロー

  • ユーザーがConfiguration Files (HCL) を記述する。
  • Configuration FilesはTerraform Coreによって読み込まれる。
  • Terraform Coreは、記述されたリソースと、State Fileに記録された現在の状態を比較する。
  • Terraform Coreは、必要な変更（作成、更新、削除）を特定し、Provider Pluginを介して各インフラプロバイダー（AWS, Azure, GCPなど）のAPIを呼び出す。
  • インフラプロバイダー上でリソースが操作される。
  • 操作結果がState Fileに反映される。

この図解をより詳細に掘り下げてみましょう。Terraformを理解する上で核となる概念は以下の通りです。

1. 宣言的なアプローチ (Declarative Approach)

Terraformは基本的に宣言的なアプローチを採用しています。これは、「最終的にどのような状態のインフラを構築したいか」をコードで記述するということです。Terraformは、その記述された状態（目標状態）と、現在のインフラの状態（現状）を比較し、目標状態に一致させるために必要な操作（リソースの作成、変更、削除）を自動的に判断して実行します。

対照的に、命令的なアプローチは、「目標状態に至るためにどのような手順を実行すべきか」を記述します。例えば、「まずサーバーAを作成し、次にIPアドレスを割り当て、その後にWebサーバーをインストールして起動する」といった具体的なステップを記述します。

宣言的なアプローチの利点は、記述がシンプルになりがちなこと、そしてツールが最適な実行順序や依存関係を自動的に解決してくれることです。

2. プロバイダー (Provider)

Terraformが様々なインフラサービスと連携できるのは、「プロバイダー」という仕組みのおかげです。プロバイダーは、特定のインフラストラクチャのAPIとTerraform Coreの間を取り持つプラグインのようなものです。

図3：Providerの役割

  • Terraform Core (HCLを解釈し、Stateを管理)
  • <–> Provider Plugin (特定のサービスAPIとの通信を抽象化)
  • <–> 各インフラサービスAPI (AWS EC2 API, Azure VM API, Google Cloud Storage APIなど)

プロバイダーは、そのサービスで利用可能なリソースタイプ（例: aws_instance, azurerm_virtual_machine, google_storage_bucket）やデータソースを定義しています。Terraformユーザーは、使用したいサービスのプロバイダーをConfiguration Filesで指定し、そのプロバイダーが提供するリソースを記述することで、インフラを定義します。

Terraform Registryには、公式、パートナー、コミュニティが開発した数千ものプロバイダーが登録されており、AWS、Azure、GCPといった主要なパブリッククラウドだけでなく、Kubernetes、Docker、Datadog、Cloudflare、GitHubなど、非常に幅広いサービスに対応しています。

3. リソース (Resource)

リソースは、Terraformで管理するインフラストラクチャの個々の構成要素です。例えば、AWSのEC2インスタンス、VPC、S3バケット、Azureの仮想マシン、仮想ネットワーク、ストレージアカウント、GCPのCompute Engineインスタンス、VPCネットワーク、Cloud Storageバケットなどがリソースにあたります。

Configuration Filesでは、使用するプロバイダーが提供するリソースタイプを指定し、そのリソースの desired state (あるべき状態) を属性値として記述します。

HCL (HashiCorp Configuration Language)

TerraformのConfiguration Filesは、HCLという独自言語で記述されます。HCLは人間が読み書きしやすく、かつ機械的なパースも容易になるように設計されています。基本的な構造はブロックで構成され、リソース定義は典型的なブロックの一つです。

“`hcl

AWS Provider を設定

provider “aws” {
region = “ap-northeast-1” # 利用するリージョン
}

S3 バケットというリソースを定義

resource “aws_s3_bucket” “my_bucket” {
# リソースタイプ “aws_s3_bucket” と ローカル名 “my_bucket” を指定
bucket = “my-unique-bucket-name-xxxxxxxx” # 実際のバケット名はグローバルにユニークである必要あり
acl = “private”

tags = {
Name = “MyTerraformBucket”
Environment = “Dev”
}
}
“`

この例では、providerブロックでAWSプロバイダーを設定し、resourceブロックでAWSのS3バケットを作成することを定義しています。"aws_s3_bucket"がリソースタイプ、"my_bucket"はこのConfigurationファイル内でのリソースの論理的な名前（ローカル名）です。その中に、bucketやacl、tagsといったリソースの属性値を記述します。

4. ステート (State) ファイル

Terraformの最も重要な概念の一つが「ステートファイル」です。Terraformは、インフラの現在の状態をterraform.tfstateというJSON形式のファイルに記録します。このファイルは、Terraformが管理する実際のリソースとConfiguration Filesの間のマッピングを保持しています。

図4：State Fileの重要性

  • Configuration Files: ユーザーが定義した「あるべき状態」。
  • State File: Terraformが把握している「現在のインフラの状態」（どのリソースが、どのようなIDで存在するか）。
  • 実際のリソース: クラウドプロバイダー上に存在する物理的/論理的なリソース。

Terraformは、applyやplanコマンドを実行する際に、Configuration Filesの定義とState Fileに記録された情報を比較します。

  • State Fileに存在しないリソースがConfiguration Filesにあれば、それは「新規作成」として計画されます。
  • State Fileに存在するリソースの属性値がConfiguration Filesの定義と異なれば、それは「更新」として計画されます。
  • State Fileに存在するがConfiguration Filesに定義がなければ、それはデフォルトでは「削除」として計画されます（terraform destroyの場合）。

State Fileの役割

  • リソースのマッピング: Configuration Filesで定義された論理名（例: aws_s3_bucket.my_bucket）と、実際のリソースID（例: AWSのバケット名）を関連付けます。
  • リソース属性のキャッシュ: リソースの属性値（例: 作成されたEC2インスタンスのPublic IPなど）をキャッシュしています。これにより、他のリソースがその情報を参照する際に、毎回プロバイダーAPIを問い合わせる必要がなくなります。
  • 依存関係の管理: リソース間の暗黙的および明示的な依存関係を理解し、正しい順序で操作を実行するために利用されます。
  • メタデータの記録: プロバイダーのバージョンやTerraformのバージョンなど、管理に必要な情報が記録されます。

State Fileはインフラの現在のスナップショットであり、Terraformが正しく動作するために不可欠です。State Fileを失うと、Terraformは自分がどのリソースを管理しているのか分からなくなり、Configuration Filesとの乖離が発生してしまいます。 したがって、State Fileの管理は非常に重要です。

5. モジュール (Module)

モジュールは、関連する複数のリソースをまとめた再利用可能な単位です。例えば、Webサーバー、データベース、ロードバランサーといった複数のリソースで構成される一般的なアプリケーションスタックを一つのモジュールとして定義しておけば、それを複数のプロジェクトや環境で簡単に再利用できます。

図5：Moduleによるコードの構造化と再利用

  • ルートモジュール (プロジェクトのメイン構成ファイル群)
    • main.tf
    • variables.tf
    • outputs.tf
  • ルートモジュールから参照される子モジュール
    • module "webserver" -> ./modules/webserver ディレクトリ または Terraform Registry
    • module "database" -> ./modules/database ディレクトリ または Terraform Registry

モジュールを使うことのメリット：

  • コードの再利用性: 同じ構成パターンを何度も記述する必要がなくなります。
  • コードの抽象化: 詳細な実装を隠蔽し、モジュールのインターフェース（入力変数と出力値）を通じてのみやり取りすることで、構成ファイルをシンプルに保てます。
  • コードの管理性: 大きなプロジェクトを論理的な単位に分割し、管理しやすくします。
  • 標準化: 組織内で定義されたベストプラクティスをモジュールとして共有することで、インフラ構成の標準化を促進できます。

モジュールは、ローカルディレクトリ、Terraform Registry、GitHubなどのバージョン管理システム、S3やGCSなどのオブジェクトストレージなど、様々な場所から参照できます。

6. ワークスペース (Workspace)

ワークスペースは、同じConfiguration Filesを使って、異なるState Fileを管理するための機能です。これにより、開発環境、ステージング環境、本番環境など、環境ごとに異なるインフラ構成を管理できます。

図6：Workspaceによる環境分離

  • 一つのConfiguration Filesセット (main.tf, variables.tf など)
  • terraform workspace new dev -> terraform.tfstate.d/dev/terraform.tfstate を生成
  • terraform workspace new staging -> terraform.tfstate.d/staging/terraform.tfstate を生成
  • terraform workspace new prod -> terraform.tfstate.d/prod/terraform.tfstate を生成
  • 各ワークスペースは独立したState Fileを持つ。

ワークスペースを使うことで、例えば変数ファイル（variables.tf）で環境ごとの設定値（インスタンスサイズ、レプリカ数など）を定義しておき、ワークスペースを切り替えるだけで異なる環境に同じConfiguration Filesを適用できます。

デフォルトでは、defaultというワークスペースが作成されます。

7. コアワークフロー (init, plan, apply, destroy)

Terraformの基本的な操作は、以下のコマンドを使ったワークフローで行われます。

図7：Terraform コアワークフロー

  1. terraform init: プロジェクトの初期化。Configuration Filesを読み込み、必要なプロバイダープラグインをダウンロードし、バックエンド（State Fileの保存場所）を設定します。Terraformプロジェクトを開始する際に最初に実行するコマンドです。
  2. terraform validate: Configuration Filesの構文と基本的な整合性をチェックします。
  3. terraform fmt: Configuration Filesを標準的なフォーマットに整形します。可読性を高めるために実行を推奨します。
  4. terraform plan: 現在のConfiguration FilesとState Fileを比較し、目標状態を実現するためにどのような変更（作成、更新、削除）が必要かの実行計画を作成し表示します。このコマンドは実際には何も変更しないため、applyを実行する前に必ず確認することが重要です。
  5. terraform apply: planで表示された実行計画に基づいて、実際のリソース操作を行います。実行前に計画内容が表示され、確認を求められます。承認すると、TerraformはプロバイダーAPIを呼び出してインフラに変更を加えます。操作が完了すると、State Fileが更新されます。
  6. terraform destroy: Configuration Filesで定義された、State Fileに記録されているすべてのリソースを削除します。テスト環境の後片付けなどに使用します。実行前に削除されるリソースの計画が表示され、確認を求められます。

これらのコマンドを繰り返し実行することで、インフラをコードで管理し、状態を意図した通りに維持していきます。

【図解】Terraformのアーキテクチャ

Terraformは、以下の主要なコンポーネントで構成されています。

図8：Terraform アーキテクチャ

  • User Interface (CLI): ユーザーがTerraformコマンド（init, plan, applyなど）を実行するインターフェースです。
  • Terraform Core: Terraformの核となるエンジンです。
    • Configuration Files (.tf) の読み込みとパース
    • State File の管理 (読み込み、書き込み、ロック)
    • Execution Plan (実行計画) の生成 (Configuration と State の比較)
    • Resource Graph の構築 (リソース間の依存関係解決)
    • Provider Plugin との連携
  • Provider Plugin: 各インフラサービス固有のロジックをカプセル化したプラグインです。
    • Terraform Core からのリクエストを受け付け
    • 各インフラサービスのAPIと通信し、リソースの作成、読み取り、更新、削除 (CRUD: Create, Read, Update, Delete) を実行
    • リソースの現在の状態をTerraform Core に報告
  • State Backend: State File を保存する場所です。
    • Local Filesystem (デフォルト)
    • Remote Backends (S3, Azure Blob Storage, GCS, Terraform Cloud/Enterpriseなど)
  • Configuration Files: HCLで記述された、ユーザーが定義するインフラのコード (.tfファイル)。

Terraform apply 実行時の内部的な流れ (図解的な説明)

  1. ユーザーが terraform apply コマンドを実行。
  2. Terraform Core は State Backend から現在の State File を読み込む。
  3. Terraform Core は Configuration Files (.tfファイル) を読み込み、パースする。
  4. Terraform Core は Configuration Files の定義と State File の状態を比較し、変更が必要なリソースを特定する。
  5. Terraform Core はリソース間の依存関係を解決し、安全な実行順序を決定する (Resource Graph)。
  6. Terraform Core は Provider Plugin と通信し、各リソースに対して必要な操作 (作成、更新、削除) を指示する。
  7. Provider Plugin は、対応するインフラサービスのAPIを呼び出す。
  8. インフラサービス上で実際のリソース操作が行われる。
  9. Provider Plugin は操作結果とリソースの最終的な状態を Terraform Core に報告する。
  10. Terraform Core は、報告された情報に基づいて State File を更新し、State Backend に書き込む。

このアーキテクチャにより、Terraformは様々な種類のインフラを統一的な方法で管理できるのです。

Terraformを使うメリット

Terraformが広く普及しているのは、以下のような多くのメリットがあるからです。

  1. マルチクラウド/マルチサービス対応: AWS、Azure、GCPといった主要クラウドから、Kubernetes、Docker、SaaSまで、数千種類のプロバイダーに対応しています。特定のベンダーにロックインされずに、様々なインフラを統一的に管理できます。
  2. 宣言的な構文: HCLは直感的で学習しやすく、「どういう状態になってほしいか」をシンプルに記述できます。これにより、コードの可読性が高まります。
  3. 実行計画 (Plan) による変更前の確認: terraform plan コマンドにより、実際にインフラに変更を加える前に、どのような操作が行われるかを正確に把握できます。これは予期せぬ変更を防ぎ、安全なデプロイを実現する上で非常に重要です。
  4. ステート管理による確実な変更管理: ステートファイルが現在のインフラ状態を正確に把握しているため、TerraformはConfiguration Filesとの差分を検知し、必要な変更のみを行います。これにより、冪等性（何度実行しても同じ結果になる性質）が確保されやすくなります。
  5. モジュールの再利用性: 共通のインフラパターンをモジュール化し、複数のプロジェクトや環境で再利用できます。これにより、コード量が削減され、メンテナンス性が向上します。
  6. 強力なコミュニティと豊富なエコシステム: Terraformは非常に人気があり、活発なコミュニティがあります。多くの情報源、公開モジュール、ツールが利用可能であり、問題解決や学習がしやすい環境です。Terraform Registryには、すぐに使える多数のプロバイダーやモジュールが登録されています。
  7. 破壊と再構築の容易さ: テスト環境などで、環境を完全に破棄してゼロから再構築することが容易に行えます。これは、環境のクリーンさを保ち、テストの再現性を高める上で役立ちます。
  8. Graphing機能: terraform graph コマンドを使うと、リソース間の依存関係を可視化できます。複雑な構成を理解するのに役立ちます。

Terraformを使うデメリット・注意点

Terraformにも注意すべき点やデメリットは存在します。

  1. ステートファイル管理の重要性とリスク: State Fileはインフラの現在の状態を示す唯一の情報源です。これを誤って操作したり、失ったりすると、Terraformがインフラの状態を正確に把握できなくなり、最悪の場合、意図しないリソースの削除や変更につながる可能性があります。特にチーム開発においては、リモートState BackendとState Lockingが必須になります。
  2. HCL言語の習得: 宣言的な構文であるHCLは比較的学習しやすいですが、複雑なロジックや条件分岐を記述しようとすると限界があります。データ構造（リスト、マップ）の扱い、変数、出力値、ループ処理（count, for_each）などを理解する必要があります。
  3. 構成管理との違い: Terraformはプロビジョニングツールであり、サーバー内部の細かい設定（OS設定、パッケージインストールなど）は得意ではありません。このような用途には、Ansibleなどの構成管理ツールと組み合わせて使用することが一般的です。（例: TerraformでEC2インスタンスを作成し、Ansibleでそのインスタンスにソフトウェアをインストールする）
  4. 計画外の変更 (Out-of-band changes) への対応: Terraformを使わずに手動でインフラに変更を加えると、その変更はState Fileに反映されません。その結果、Configuration Filesと実際のインフラ、そしてState Fileの間で乖離が発生し、次回Terraformを実行した際に予期せぬ動作を引き起こす可能性があります。これを避けるためには、インフラに対する全ての変更はTerraform経由で行うという運用ルールを徹底する必要があります。どうしても手動変更が必要な場合は、terraform importコマンドを使ってState Fileに取り込むなどの対応が必要です。
  5. 学習コスト: 基本的な概念はシンプルですが、State Fileの適切な管理、モジュールの設計、複雑なリソース間の依存関係の解決、エラーハンドリングなど、より高度な使い方には一定の学習と経験が必要です。特にチーム開発における運用ベストプラクティスを理解することが重要です。
  6. 削除操作の不可逆性: terraform destroy コマンドはState File内の全てのリソースをデフォルトで削除しようとします。本番環境などで誤って実行しないよう、十分な注意が必要です。また、prevent_destroy = true のようなライフサイクル設定を適切に利用することが推奨されます。

Terraformの始め方（実践的なステップ）

ここでは、ローカル環境でTerraformをインストールし、簡単なAWSリソースを作成するまでの基本的なステップを紹介します。（AWSアカウントが前提となりますが、他のクラウドでも基本的な流れは同じです）

1. Terraformのインストール

Terraformは様々なOSに対応しています。HashiCorpの公式サイトからバイナリをダウンロードするか、各OSのパッケージマネージャーを使ってインストールできます。

  • macOS (Homebrew):
    bash
    brew tap hashicorp/tap
    brew install hashicorp/tap/terraform
  • Windows (Chocolatey):
    bash
    choco install terraform
  • Linux (apt/yumなど): 公式サイトの手順を参照。多くの場合、HashiCorpのリポジトリを追加してインストールします。

インストール後、バージョンを確認します。

bash
terraform version

2. AWS認証設定

TerraformがAWSリソースを操作するためには、AWSの認証情報が必要です。以下のいずれかの方法で設定します。

  • 環境変数:
    bash
    export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
    export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"
    # オプション: 利用するリージョン
    export AWS_DEFAULT_REGION="ap-northeast-1"
  • AWS CLIの設定ファイル: ~/.aws/credentials および ~/.aws/config ファイルに設定。これが最も推奨される方法です。

注意: 本番環境やチーム開発では、IAMロールを利用し、一時的な認証情報を使用するのがセキュリティベストプラクティスです。

3. 最初のConfiguration File作成

新しいディレクトリを作成し、その中にConfiguration Filesを作成します。例えば、aws-s3-exampleというディレクトリを作り、その中にmain.tfというファイルを作成します。

bash
mkdir aws-s3-example
cd aws-s3-example
touch main.tf

main.tfをエディタで開き、以下の内容を記述します。

“`hcl

main.tf

Terraform のバージョン要件と、使用するプロバイダーを指定

terraform {
required_providers {
aws = {
source = “hashicorp/aws”
version = “~> 5.0” # 使用するAWSプロバイダーのバージョンを指定
}
}
}

プロバイダーを設定 (AWS)

provider “aws” {
region = “ap-northeast-1” # 利用するリージョン
}

S3 バケット リソースを定義

ローカル名: my_bucket

resource “aws_s3_bucket” “my_bucket” {
# 実際のバケット名。グローバルにユニークである必要があるため、適宜変更してください。
# 例: my-unique-bucket-name-YYYYMMDDHHMMSS
bucket = “my-terraform-example-bucket-20231027100000”

acl = “private”

tags = {
Name = “MyTerraformBucket”
Environment = “Development”
}
}

S3 バケットの public access block を設定するリソースを定義

S3バケット作成とは別に設定が必要なリソースタイプです

resource “aws_s3_bucket_public_access_block” “my_bucket_public_access_block” {
bucket = aws_s3_bucket.my_bucket.id # 上で定義したS3バケットのIDを参照

block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}

作成されたS3バケットの名前を出力として定義

output “bucket_name” {
description = “Name of the S3 bucket”
value = aws_s3_bucket.my_bucket.bucket
}
“`

コードの解説:

  • terraformブロック: Terraform自身の振る舞いを設定します。ここでは、使用するプロバイダー（hashicorp/aws）とそのバージョンを指定しています。~> 5.0は、「5.0以上かつ6.0未満の最新バージョン」という意味です。
  • provider "aws"ブロック: AWSプロバイダーの設定です。どのリージョンを使用するかを指定します。
  • resource "aws_s3_bucket" "my_bucket"ブロック: AWSのS3バケットリソースを定義しています。"aws_s3_bucket"がリソースタイプ、"my_bucket"がこのConfigurationファイル内での論理名です。bucket, acl, tagsは、このリソースの属性です。bucket属性の値はグローバルにユニークである必要があるため、適切な名前に変更してください。
  • resource "aws_s3_bucket_public_access_block" "my_bucket_public_access_block"ブロック: S3バケットのパブリックアクセス設定をブロックするリソースです。S3バケット自体とは別のリソースタイプとして定義します。bucket属性で、先ほど定義したS3バケット（aws_s3_bucket.my_bucket）のIDを参照しています。これは、この設定がどのバケットに適用されるかを指定するためのリソース参照です。Terraformはこのような参照からリソース間の依存関係を自動的に解決し、S3バケットが作成された後にこの設定が適用されるように実行順序を決定します。
  • output "bucket_name"ブロック: terraform apply 完了後に表示される出力値を定義します。ここでは、作成されたS3バケットの名前（aws_s3_bucket.my_bucket.bucket）を出力しています。

4. プロジェクトの初期化

Configuration Filesを作成したら、そのディレクトリで以下のコマンドを実行します。

bash
terraform init

このコマンドは、.tfファイルを読み込み、terraformブロックで指定されたプロバイダープラグイン（ここではAWSプロバイダー）をダウンロードします。成功すると、.terraformという隠しディレクトリが作成され、その中にプロバイダープラグインなどが配置されます。

5. Configuration Filesのフォーマットと検証

コードの整形と構文チェックを行います。

bash
terraform fmt # コード整形
terraform validate # 構文チェックと基本的な整合性チェック

エラーがなければ、次のステップに進みます。

6. 実行計画の確認

実際にリソースを作成する前に、どのような変更が行われるかを確認します。

bash
terraform plan

このコマンドを実行すると、Terraformは現在のState File（最初は存在しないか空の状態）とConfiguration Filesを比較し、AWSに対してどのようなAPIコールを実行するか（つまり、何を作成、変更、削除するか）を詳細に表示します。「Plan: 2 to add, 0 to change, 0 to destroy.」のようなサマリーが表示され、その下に各リソースに対する操作（+ createなど）の詳細が表示されます。

表示される計画内容を必ず確認してください。意図しないリソースが削除される計画になっていないか、必要なリソースが作成されるかなどをチェックします。

7. リソースの作成 (Apply)

計画内容に問題がなければ、実際にインフラを作成します。

bash
terraform apply

planコマンドと同様に、実行計画が再度表示され、「Do you want to perform these actions?」と確認を求められます。問題がなければ、yesと入力してEnterを押します。

TerraformはプロバイダーAPIを呼び出し、AWS上にS3バケットとパブリックアクセスブロックを作成します。リソースの作成には時間がかかる場合があります。

実行が完了すると、作成されたリソースの情報や、定義したOutput値（ここではバケット名）が表示されます。

このディレクトリには、terraform.tfstateというファイルが作成されます。これが、Terraformが管理するリソースの状態を記録したState Fileです。

8. ステートファイルの確認

State Fileの内容を確認できます。

bash
terraform show

これにより、State Fileに記録されているリソースの詳細（ID、属性値など）が表示されます。

9. リソースの変更

Configuration Filesを編集することで、リソースを変更できます。例えば、S3バケットに別のタグを追加してみましょう。main.tfを編集します。

“`hcl

main.tf (変更箇所のみ)

resource “aws_s3_bucket” “my_bucket” {
bucket = “my-terraform-example-bucket-20231027100000”

acl = “private”

tags = {
Name = “MyTerraformBucket”
Environment = “Development”
Project = “TerraformGuide” # 新しいタグを追加
}
}
“`

ファイルを保存し、再度planとapplyを実行します。

bash
terraform plan

planの出力を見ると、S3バケットリソースが~ update in-place（インプレース更新）される計画が表示されるはずです。タグが一つ追加される旨も表示されます。

bash
terraform apply

確認を求められたらyesと入力します。Terraformは既存のS3バケットに対してタグを追加するAPIコールを実行し、State Fileを更新します。

10. リソースの削除 (Destroy)

作成したリソースを削除する場合（例えばテスト環境を破棄する場合）は、以下のコマンドを実行します。

bash
terraform destroy

planやapplyと同様に、削除されるリソースの計画が表示され、確認を求められます。「Plan: 0 to add, 0 to change, 2 to destroy.」のようなサマリーが表示されます。

問題がなければ、yesと入力してEnterを押します。TerraformはAWSに対してリソースを削除するAPIコールを実行します。操作が完了すると、State Fileから削除されたリソースの情報が消去されます。

ローカルState Fileの注意点

上で実行した手順では、State File (terraform.tfstate) はローカルのファイルシステムに保存されます。これは単独で学習する場合や、ローカル環境のリソースを管理する場合には問題ありませんが、チームで開発する場合や、CI/CDパイプラインで利用する場合には不向きです。

  • チーム開発: 複数のメンバーが同時にapplyを実行すると、State Fileへの書き込みが衝突し、State Fileが壊れる可能性があります。また、各メンバーが最新のState Fileを共有する必要があります。
  • CI/CD: CI/CDエージェントが実行する際に、過去のState Fileをどのように引き継ぐかという課題が生じます。
  • State Fileの喪失: ローカルのState Fileを誤って削除したり、PCが故障したりすると、State Fileが失われ、Terraformが管理しているリソースとの関連付けができなくなります。

これらの問題を解決するために、リモートState Backendを利用することが強く推奨されます。

リモートState BackendとState Locking

リモートState Backendは、State Fileを中央集権的な場所に保存する仕組みです。これにより、State Fileを安全に保管し、チームメンバー間で共有できます。

図9：リモートState BackendとState Locking

  • 複数のユーザーまたはCI/CDエージェントが、同じConfiguration Filesを使ってTerraformコマンドを実行。
  • Terraform Core は、State Backend (例: S3バケット) にState Fileを保存・取得。
  • State Backend または 連携するサービス (例: DynamoDB) が State Locking 機能を提供。
  • 誰かが apply を実行している間は、他のユーザー/エージェントはState Fileをロックされ、同時にStateを変更できない。

主要なリモートState Backendには以下があります。

  • AWS S3 + DynamoDB: S3にState Fileを保存し、DynamoDBでState Lockingを実現します。AWS環境でTerraformを利用する場合の最も一般的な方法です。
  • Azure Blob Storage: AzureのストレージアカウントにState Fileを保存します。
  • Google Cloud Storage: GCPのCloud StorageバケットにState Fileを保存します。
  • Terraform Cloud/Enterprise: HashiCorpが提供するマネージドサービスです。State管理、ロック、リモート実行、チーム管理、ポリシー適用など、様々な機能を提供します。IaCの成熟度を高める上では非常に有力な選択肢です。

リモートState Backendを設定するには、Configuration Filesにbackendブロックを追加します。例えば、AWS S3を使う場合：

“`hcl

main.tf

terraform {
required_providers {
aws = {
source = “hashicorp/aws”
version = “~> 5.0”
}
}

# リモート State Backend (AWS S3) を設定
backend “s3” {
bucket = “my-terraform-state-bucket-xxxxxxxx” # State File を保存するS3バケット名
key = “path/to/your/state/terraform.tfstate” # バケット内のパス
region = “ap-northeast-1”
encrypt = true # State File を暗号化
# State Locking に使用するDynamoDBテーブル名 (オプションだがチーム開発では必須)
dynamodb_table = “my-terraform-state-lock”
}
}

… provider, resource などの定義は続く …

“`

backendブロックを追加または変更した場合は、必ず再度 terraform init を実行する必要があります。これにより、Terraformは新しいバックエンド設定を認識し、必要に応じて既存のState Fileを新しいバックエンドに移行します。

bash
terraform init -reconfigure # バックエンド設定を変更した場合

リモートState BackendとState Lockingは、Terraformを安全にチームで運用する上で不可欠な機能です。使い始める際には、ローカルStateだけでなく、リモートStateの管理方法についても理解しておくべきです。

Terraformをさらに活用するために

Terraformの基本的な使い方をマスターしたら、さらに高度な機能やテクニックを学ぶことで、より複雑なインフラを効率的に管理できるようになります。

  • 変数の活用 (variables.tf): 環境固有の値（インスタンスタイプ、リージョンなど）、機密情報（パスワードなど）、または単にConfigurationファイルをカスタマイズ可能にするための値を変数として定義できます。これにより、同じConfigurationファイルを使って異なる環境にデプロイしたり、汎用的なモジュールを作成したりできます。変数はterraform.tfvarsファイルや環境変数などで設定値を渡します。
  • データソース (dataブロック): 既存のインフラリソースや外部サービスの情報を取得するために使用します。例えば、特定のAMI IDを取得したり、既存のVPCの情報を参照したりできます。これにより、Terraformが管理していない既存のリソースと連携したり、Configurationファイルを動的に生成したりすることが可能になります。
  • モジュールの作成と利用: 独自のモジュールを作成し、ローカルまたはリモートリポジトリで管理・共有します。また、Terraform Registryで公開されている多数の公式・コミュニティモジュールを利用します。モジュールを使うことで、複雑な構成を構造化し、コードの重複をなくすことができます。
  • countとfor_eachによる複数リソースの管理: 類似したリソースを複数作成する場合に、countまたはfor_each引数を使用します。これにより、コードの繰り返しを減らし、簡潔に多数のリソースを定義できます。
  • Conditionals (countやfor_each内のif、またはconditional式): 特定の条件に基づいてリソースを作成するかどうかを制御できます。
  • ワークスペースの詳細な利用: terraform workspaceコマンドを使って、開発、ステージング、本番などの環境をStateファイルレベルで分離します。
  • Provisioners: リソース作成後に、そのリソースに対して特定の操作（例えばリモートでのスクリプト実行）を行わせたい場合に利用できます。ただし、HashiCorpはProvisionerの使用を非推奨としており、Packerでイメージを作成したり、構成管理ツール（Ansibleなど）と組み合わせたりすることを推奨しています。
  • State操作コマンド: terraform state コマンド群を使うことで、Stateファイルの内容を直接操作できます。リソースの移動 (mv)、削除 (rm)、リスト表示 (list) など、Stateファイルが現在のインフラと一致しなくなった場合のリカバリや、Configurationの整理に役立ちますが、誤った操作はStateを壊す可能性があるため慎重に使用する必要があります。
  • CI/CDパイプラインへの組み込み: Jenkins, GitLab CI, GitHub Actions, CircleCIなどのCI/CDツールと連携し、コードの変更がトリガーとなって自動的にterraform planやterraform applyを実行するパイプラインを構築します。これにより、インフラの変更を自動化し、より迅速かつ安全なデプロイを実現できます。

これらの機能を使いこなすことで、Terraformの能力を最大限に引き出し、様々な要件に対応できるようになります。

よくある課題と解決策

Terraformを利用する上で遭遇しやすい課題と、その一般的な解決策をいくつか紹介します。

  • ステートファイルのコンフリクト:

    • 課題: チームメンバーが同時にapplyを実行しようとしたり、CI/CDパイプラインと手動実行が衝突したりすると、State Fileが壊れる可能性があります。
    • 解決策: リモートState Backendと必ずState Locking機能を有効にします。これにより、State Fileへの同時書き込みを防ぎます。

  • 手動変更 (Out-of-band changes) との同期問題:

    • 課題: Terraformを使わずにインフラを手動で変更すると、State Fileと実際のインフラの状態が乖離し、次回Terraformを実行した際に問題が発生します。
    • 解決策: 全てのインフラ変更はTerraform経由で行うという運用ルールを徹底します。やむを得ず手動変更した場合は、terraform importコマンドを使ってState Fileに手動変更を反映させるか、Configurationを修正してTerraformがその状態を認識できるようにします。定期的にterraform planを実行し、計画外の変更がないかチェックするのも有効です。

  • 依存関係の管理:

    • 課題: リソース間に複雑な依存関係がある場合、Terraformが自動で解決できない、または意図しない順序で実行されることがあります。
    • 解決策: 基本的にはリソース参照（例: aws_s3_bucket_public_access_block.my_bucket_public_access_block.bucket = aws_s3_bucket.my_bucket.id）を使うことで、Terraformは依存関係を自動的に認識します。明示的な依存関係が必要な場合は、depends_on引数を使用します（ただし、可能な限りリソース参照を優先すべきです）。モジュールを使って関連するリソースをグループ化することも依存関係を整理するのに役立ちます。

  • セキュリティ（シークレット情報の管理）:

    • 課題: データベースのパスワードやAPIキーなどの機密情報をConfiguration Filesに直接記述したり、State Fileに平文で保存したりするのは危険です。
    • 解決策:
      • 変数を使って機密情報を扱う場合、.tfvarsファイルではなく、環境変数やCI/CDツールのシークレット変数機能で渡します。
      • State File自体に機密情報が保存されないように、パスワードなどが設定される属性にはsensitive = trueを設定します（これにより、planやapplyの出力で値が表示されなくなりますが、State Fileには保存されます）。
      • よりセキュアな方法として、AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, HashiCorp Vaultのようなシークレット管理サービスを利用します。Terraformのデータソースを使ってこれらのサービスからシークレットを取得し、リソースに設定します。State Fileには、シークレットの値そのものではなく、シークレット管理サービスへの参照情報が記録されるようにします。

  • コスト管理:

    • 課題: Terraformを使ってリソースを簡単に作成できる反面、意図せず高コストなリソースを作成したり、リソースを削除し忘れたりするリスクがあります。
    • 解決策: terraform planで作成・変更されるリソースの種類や数量を慎重に確認します。Cost Estimationツール（例: terraform-costやTerraform Cloudの機能）を利用して、変更によるコスト影響を事前に把握します。リソースに適切なタグ（例: Environment, Owner, Project）を付けておき、クラウドプロバイダー側のコスト分析ツールでタグごとのコストを追跡・管理します。不要になったリソースは忘れずにterraform destroyで削除します。

これらの課題と解決策を事前に理解しておくことで、より安全かつ効率的にTerraformを運用できます。

Terraformと他のIaCツールの比較

Terraformは強力なツールですが、IaCツールはTerraformだけではありません。他の代表的なツールとの違いを理解することで、状況に応じた適切なツールの選択や組み合わせが可能になります。

  • 構成管理ツール (Ansible, Chef, Puppet):

    • 目的: 主にサーバー内部の構成管理（OS設定、パッケージインストール、サービス管理など）に特化しています。
    • アプローチ: Ansibleは命令的（手順記述）な側面が強いですが、宣言的な記述も可能です。ChefやPuppetは宣言的です。
    • 得意なこと: 既存サーバーの設定変更、アプリケーションデプロイ。
    • 苦手なこと: サーバー自体のプロビジョニング、VPCやネットワークなどのインフラ基盤構築。
    • Terraformとの関係: Terraformでサーバー（VM、コンテナ）を作成し、Ansibleなどでそのサーバー内部を構成するというように、組み合わせて使用されることが多いです。

  • クラウドプロバイダー固有のIaCツール (AWS CloudFormation, Azure Resource Manager, Google Cloud Deployment Manager):

    • 目的: 特定のクラウドプロバイダー上のリソースプロビジョニング。
    • アプローチ: 基本的に宣言的です。
    • 得意なこと: そのプロバイダーの最新サービスや機能をいち早くサポートします。同じプロバイダー内での連携がスムーズです。
    • 苦手なこと: マルチクラウド環境には対応できません。 複数のクラウドを跨るインフラを管理する場合、各クラウドのツールを使い分ける必要があります。
    • Terraformとの関係: Terraformはマルチクラウド対応という点で優位性がありますが、特定のクラウドに特化した機能のサポートや、そのプロバイダーのエコシステムとの連携においては、固有ツールが優れる場合もあります。企業の戦略（特定のクラウドに一本化するか、マルチクラウド戦略をとるか）によって選択が変わります。

  • Pulumi:

    • 目的: インフラリソースのプロビジョニング。
    • アプローチ: 宣言的ですが、HCLではなく一般的なプログラミング言語（Python, Node.js/TypeScript, Go, C#など）を使って構成を記述します。
    • 得意なこと: 既存のプログラミングスキルを活かせる。複雑なロジックや抽象化がプログラミング言語の機能を使って容易に実現できる。UnitテストやIntegrationテストを書きやすい。
    • 苦手なこと: HCLに比べて学習コストが高い場合がある。プログラミング言語のランタイムが必要。
    • Terraformとの関係: 同じプロビジョニングツールとして、しばしば比較検討されます。HCLに慣れているか、既存のプログラミングスキルを活かしたいか、より複雑なプログラマブルなインフラ定義が必要か、などが選択のポイントになります。Terraformと同じHashiCorpのプロバイダーエコシステムを利用できる場合があります。

これらの比較から、Terraformは「マルチクラウド環境で、リソースのプロビジョニングとライフサイクル管理を宣言的に行いたい」場合に特に強力なツールであることがわかります。サーバー内部の構成管理が必要な場合はAnsibleなどと組み合わせ、特定のクラウドに完全に特化する場合は固有ツールも検討の余地があります。

まとめ：Terraformを使い始める前に

この記事では、Terraformとは何か、その基本概念、アーキテクチャ、メリット・デメリット、そして使い始めるための実践的なステップと注意点について詳しく解説しました。

Terraformは、Infrastructure as Code (IaC) を実現するための強力なツールであり、現代のクラウドインフラ管理においてデファクトスタンダードの一つとなりつつあります。宣言的な構文、マルチクラウド対応、実行計画による安全な変更、State Fileによる確実な状態管理、モジュールによる再利用性といった特長を持ち、インフラの構築、変更、管理を劇的に効率化・自動化できます。

使い始める上で重要なポイントは以下の通りです。

  1. IaCの目的とTerraformの位置づけを理解する: なぜIaCが必要なのか、そしてTerraformがプロビジョニングツールとして何を得意とするのかを理解することが、効果的な利用の第一歩です。
  2. 基本概念をしっかりと押さえる: Provider, Resource, State, Module, HCLといったコアな概念、そしてinit, plan, apply, destroyという基本的なワークフローを確実に理解しましょう。
  3. State File管理の重要性を認識する: State Fileはインフラの現在の状態を管理する上で非常に重要です。特にチーム開発においては、リモートState BackendとState Lockingの利用が必須であることを忘れないでください。
  4. スモールスタートで慣れる: 最初から複雑な構成に挑戦するのではなく、S3バケットやVM一台といった簡単なリソースから始めて、planとapplyの流れ、State Fileの動きに慣れていきましょう。
  5. ドキュメントやコミュニティを活用する: Terraformの公式ドキュメントは非常に充実しています。また、活発なコミュニティから多くの情報やモジュールを入手できます。

Terraformをマスターすることで、インフラ管理の効率が向上し、より迅速かつ安全にシステムをデプロイできるようになります。これは、アジャイル開発やDevOpsのプラクティスを推進する上で強力な武器となるでしょう。

この記事が、あなたがTerraformの世界に踏み出すための一助となれば幸いです。ぜひ実際に手を動かして、Terraformの便利さを体験してみてください。そして、State Fileの管理と、全ての変更をTerraform経由で行うという運用の徹底を心がけながら、段階的に複雑なインフラ構成へと挑戦していきましょう。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール