1 つのサーバーの場合、クラウド コンソールをクリックするだけで問題ありません。ステージングと運用環境で同じ設定が必要な場合、または昨年 3 月にファイアウォール ルールを変更したのは誰かと尋ねられた場合、問題は解決しません。この 初心者向け Terraform チュートリアルでは、インフラストラクチャをコードで記述し、ツールでそれを実現するという、より良い方法を示しています。

ほとんどのチュートリアルはクラウド アカウントから始まるため、何も学ぶ前に請求リスクが追加されます。まず Terraform の local プロバイダーから始めます。これはコンピューター上にファイルを作成するだけなので、間違いがあってもコストはかかりません。これらの例とサンプル出力は標準的な図であり、この記事では実行しませんでした。正確な表現はバージョンによって異なります。

テラフォームとは何ですか?

Terraform は、HashiCorp のコードとしてのインフラストラクチャ (IaC) ツールです。 HashiCorp 構成言語である HCL で構成ファイルを作成し、必要な最終結果を記述します。次に、Terraform は、そこに到達するために何を作成、変更、または削除するかを判断します。

プロバイダーと呼ばれるプラグインを通じてプラットフォームと通信します。 AWS、Azure、Google Cloud、Kubernetes、GitHub、Cloudflare などのプロバイダーがあるため、それらすべてで 1 つのワークフローを使用できます。

知っておくべきことの 1 つは、2023 年に HashiCorp が Terraform をビジネス ソース ライセンスに移行したことです。その後コミュニティは、非常によく似たコマンドと設定を使用するオープンソース フォークである OpenTofu を作成しました。ここで学んだことは、主に両方に当てはまります。

なぜコードとしてのインフラストラクチャなのか?

Terraform は宣言型でもあります。 「サーバーを 3 回作成する」ではなく、「サーバーが 3 つある必要がある」と述べています。すでに 2 つ存在する場合は 1 つ追加されます。単純にステップを繰り返すスクリプトでは、最終的にさらに 3 つ作成される可能性があります。

Terraform をインストールする

オペレーティング システム用の公式 HashiCorp 手順を使用してインストールし、動作することを確認します。

terraform -version

プロジェクト用に空のフォルダーを作成します。 Terraform は現在のフォルダー内のすべての .tf ファイルを読み取るため、1 つのフォルダーは 1 つの構成に相当します。

最初の構成

main.tf という名前のファイルを作成します。

terraform {
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.5"
    }
  }
}

resource "local_file" "greeting" {
  filename = "${path.module}/hello.txt"
  content  = "Hello from Terraform\n"
}

resource ブロックを見てください。ほぼすべての記述がこの形状に従っています。 local_file はリソース タイプ、greeting は構成内での独自の名前です。これらを組み合わせるとアドレスが形成されます: local_file.greeting。内部の引数は、必要なものを説明します。

ワークフロー: 初期化、計画、適用

テラフォームの初期化

これにより、フォルダーが準備され、要求したプロバイダーがダウンロードされます。最初に 1 回実行し、プロバイダーまたはモジュールを追加するたびにもう一度実行します。また、正確なプロバイダーのバージョンを記録する .terraform.lock.hcl ファイルも作成されます。そのファイルを Git にコミットします。

terraform init

テラフォーム計画

これにより、何も触れずに、コードを既存のコードと比較し、計画された変更が表示されます。

terraform plan

# local_file.greeting will be created
+ resource "local_file" "greeting" {
    + content  = "Hello from Terraform\n"
    + filename = "./hello.txt"
  }

Plan: 1 to add, 0 to change, 0 to destroy.

たくさんの計画を読むことになるので、記号を学びましょう。

テラフォーム適用

これにより、計画が再度表示され、確認を求められ、変更が加えられます。

terraform apply

yesを入力するとhello.txtが表示されます。 terraform plan を再度実行します。現実はすでにコードと一致しているため、変更は報告されません。繰り返し実行してもそれ以上の変化が起こらないこの特性は、冪等性と呼ばれます。

変化と破壊

content行を編集し、terraform planを実行します。 Terraform は違いを見つけて変更を提案します。このリソースの場合、ファイルが置き換えられます。データベースを再作成するとデータが失われる可能性があるため、実際のインフラストラクチャでの置き換えには注意してください。

次にhello.txtを手動で削除し、再度計画を立てます。 Terraform はそれが欠落していることに気づき、再作成することを提案します。コードと現実の差異は ドリフト と呼ばれ、それを検出することがこのツールの主な利点の 1 つです。

この構成が管理するものをすべて削除するには、次を実行します。

terraform destroy

変数と出力

値をハードコードすると、コードの再利用ができなくなります。入力変数により構成が柔軟になり、出力により有用な値が返されます。

# variables.tf
variable "environment" {
  type        = string
  description = "Deployment environment"
  default     = "dev"

  validation {
    condition     = contains(["dev", "staging", "prod"], var.environment)
    error_message = "Use dev, staging or prod."
  }
}

# main.tf
resource "local_file" "config" {
  filename = "${path.module}/${var.environment}.txt"
  content  = "environment=${var.environment}\n"
}

# outputs.tf
output "config_path" {
  value = local_file.config.filename
}

コマンドラインで値を設定するか、自動的にロードされる terraform.tfvars という名前のファイルに値を保存します。

terraform apply -var="environment=staging"

出力で local_file.config.filename を使用することは、リソースが相互に参照する方法でもあります。 Terraform はこれらの参照を読み取り、作成する正しい順序を決定します。

テラフォームの状態

適用するとterraform.tfstateというファイルができます。これは、Terraform が管理する内容の記録であり、コードを実際のオブジェクトにマッピングします。これがなければ、Terraform は local_file.greeting がその特定のファイルであることを認識できません。

ここでは 3 つのルールが重要です。

1. 決して状態を Git にコミットしないでください。 パスワードやその他の秘密情報がプレーン テキストで含まれる可能性があります。
2. 手動で編集しないでください。terraform state listやterraform state mvなどのコマンドを使用します。
3. チーム プロジェクトにはリモート バックエンドを使用します。 共有バックエンドは状態を一元的に保存し、ロックするため、2 人が同時に申請することはできません。

以下は、事前に作成したバケットを使用した、Amazon S3 を使用する典型的なバックエンドです。

terraform {
  backend "s3" {
    bucket       = "my-company-terraform-state"
    key          = "shop/prod/terraform.tfstate"
    region       = "ap-south-1"
    encrypt      = true
    use_lockfile = true
  }
}

本物のクラウドリソース

クラウドに移行してもワークフローは変わりません。これは AWS 上の S3 バケットです。まず価格を確認し、練習中に作成したものはすべて破棄します。

provider "aws" {
  region = "ap-south-1"
}

resource "aws_s3_bucket" "reports" {
  bucket = "my-unique-reports-bucket-2026"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

Terraform は、AWS CLI セットアップまたは環境変数から認証情報を取得します。 .tf ファイルにはアクセス キーを決して書き込まないでください。

モジュール

モジュールは、さまざまな入力で呼び出すことができる Terraform ファイルの単なるフォルダーです。これは関数とよく似た働きをし、パターンを一度定義すれば、それを再利用できます。

project/
  main.tf
  modules/
    reports_bucket/
      main.tf
      variables.tf
      outputs.tf

module "staging_reports" {
  source      = "./modules/reports_bucket"
  environment = "staging"
}

module "prod_reports" {
  source      = "./modules/reports_bucket"
  environment = "prod"
}

パブリック Terraform レジストリにも既製のモジュールがありますが、信頼する前にモジュールを読み、バージョンを固定してください。モジュールを構築するのが早すぎないでください。パターンを少なくとも 2 回繰り返すまで待ち​​ます。

安全なチームワークフロー

1. ブランチを作成し、.tf ファイルを変更します。復習が必要な場合は、初心者向けの Git チュートリアルを参照してください。
2. terraform fmtとterraform validateを実行します。
3. レビューのために terraform plan の出力を添付してプル リクエストを開きます。
4. 承認後、その保存された計画を 1 つの管理された場所 (理想的にはパイプライン) から適用します。

計画を保存すると、確認した内容を正確に適用できます。

terraform plan -out=tfplan
terraform apply tfplan

これは CI/CD と GitHub アクション に自然に適合します。通常、Terraform がクラスターをプロビジョニングし、Kubernetes などのツールがその上でアプリケーションを実行します。

よくある間違い

• プランを読まずに申請する。 データベースに 1 つ -/+ あると、非常に高額な費用がかかる可能性があります。
• 1 台のラップトップで状態を維持します。 そのラップトップを失うと、Terraform はインフラストラクチャを追跡できなくなります。
• コンソールを手動で変更する。 これらによりドリフトが発生し、次回適用すると元に戻される可能性があります。
• 固定されていないバージョンの使用。 アップグレードが意図的に行われるように、プロバイダーとモジュールのバージョンを固定します。
• 1 つの巨大な構成を使用します。 環境またはシステムごとに分割することで、間違いによる損害を制限します。

まとめ

これで、リソースの宣言、計画のレビュー、適用、状態の保護など、ほぼすべての Terraform 作業の背後にあるアイデアがわかりました。ワークフローが自然になるまで local プロバイダーを使用して練習し、その後、無料利用枠のアカウントで 1 つの小さな実際のリソースを管理します。複数の人または複数の環境が関係する場合は、リモート状態とモジュールを組み込みます。

よくある質問

学び続ける