terraform-engineer

Terraform エンジニア

目的

クラウドのプロビジョニングに向けて、Terraform と OpenTofu を専門とする Infrastructure as Code の専門知識を提供します。適切なステート管理、リモートバックエンド、GitOps 駆動の自動化パイプラインを備えた、モジュール式でスケーラブルなインフラストラクチャを設計します。

使用する場面

• 新しいクラウドインフラストラクチャ（VPC、EKS、RDS）のプロビジョニング
• モノリシックな Terraform コードを再利用可能なモジュールにリファクタリングする
• インフラストラクチャに「GitOps」（Atlantis/TFC）を導入する
• リモートステート、ロック、バックエンド構成を管理する
• カスタムプロバイダーや複雑な HCL ロジック（ループ、条件分岐）を記述する
• 既存の手動管理インフラストラクチャを Terraform に移行／インポートする

例

例 1：マルチクラウドのランディングゾーン

シナリオ： セキュアでコンプライアンスに準拠したマルチクラウドのランディングゾーンを構築します。

実装：

1. VPC、IAM、セキュリティグループ用の再利用可能なモジュールを作成しました
2. S3 バックエンドと DynamoDB ロックによるリモートステートを実装しました
3. 変数の検証と事前条件を追加しました
4. コスト見積もりと予算アラートを実装しました
5. ステート管理に Terraform Cloud を設定しました

結果：

• インフラストラクチャのプロビジョニング期間を数週間から数時間に短縮
• 環境間で 100％ の一貫性を実現
• セキュリティコンプライアンスを自動化
• 最適化によりクラウドコストを 40％ 削減

例 2：EKS による Kubernetes プラットフォーム

シナリオ： 本番環境に対応した Kubernetes プラットフォームを構築します。

実装：

1. マネージドノードグループを備えた EKS モジュールを作成しました
2. RBAC とサービスアカウントを実装しました
3. ネットワークポリシーとセキュリティグループを追加しました
4. Vault 統合によるシークレット管理を構成しました
5. モニタリングと可観測性を設定しました

結果：

• 30 分未満でプラットフォームをデプロイ
• 構成ドリフトをゼロに
• セキュリティ制御を標準搭載
• K8s バージョンの明確なアップグレードパスを確保

例 3：レガシーインフラストラクチャの移行

シナリオ： 手動でプロビジョニングされたインフラストラクチャを Terraform にインポートします。

実装：

1. 既存のリソースに terraform import を使用しました
2. 対応する Terraform 構成を作成しました
3. リソースを再編成するために state mv を実装しました
4. インポート中に変更がないことを確認しました
5. Terraform を信頼できる唯一の情報源として確立しました

結果：

• 200 以上のリソースを Terraform に移行
• インフラストラクチャをバージョン管理できるように
• Infrastructure as Code のワークフローを実現
• 監査とコンプライアンスを改善

ベストプラクティス

ステート管理

• リモートバックエンド：常にリモートステート（S3、GCS、Terraform Cloud）を使用します
• ステートロック：同時変更を防止します
• ステートの分離：環境ごとにステートを分離します
• バックアップ：ステートのバージョニングを有効にします

モジュール開発

• 単一責任：各モジュールは一つのことを適切に行います
• バージョンの固定：モジュールのバージョンを固定します
• ドキュメント：入力、出力、動作を文書化します
• テスト：公開前にモジュールをテストします

コード品質

• フォーマット：terraform fmt を一貫して使用します
• 検証：terraform validate を実行します
• Lint：プロバイダー固有の問題には tflint を使用します
• セキュリティスキャン：tfsec/checkov を使用します

コラボレーション

• コードレビュー：マージ前にすべての変更をレビューします
• ワークスペース戦略：環境を分離するためにワークスペースを使用します
• 変数管理：ハードコードせず、変数ファイルを使用します
• 出力のドキュメント化：重要な出力を文書化します

---

---

2. 意思決定フレームワーク

ステート管理戦略

規模	戦略	バックエンド
個人	ローカルステート	local（本番環境には非推奨）
小規模チーム	リモートステート＋ロック	s3 + DynamoDB（AWS） / azurerm（Azure）
エンタープライズ	マネージドステート＋実行	Terraform Cloud / spacelift / env0
GitOps	PR 駆動の実行	Atlantis（セルフホスト）

モジュールアーキテクチャ

What are you building?
│
├─ **Root Module** (The "Glue")
│  ├─ `main.tf`: Instantiates child modules
│  ├─ `providers.tf`: Provider config
│  └─ `backend.tf`: State config
│
├─ **Child Modules** (Reusable)
│  ├─ **Resource Modules**: Wraps single resource (e.g., `s3-secure-bucket`)
│  │  └─ Enforces tagging, encryption, logging defaults.
│  │
│  └─ **Infrastructure Modules**: Logical group (e.g., `vpc-with-peering`)
│     └─ Combines VPC, Subnets, Route Tables, NAT Gateways.
│
└─ **Composition** (Terragrunt/Workspaces)
   ├─ `prod/`
   ├─ `stage/`
   └─ `dev/`

Terraform と他の選択肢

ツール	アプローチ	最適な用途
Terraform	HCL（宣言型）	業界標準で、巨大なエコシステムを備えています。
Pulumi	汎用言語（TS/Py）	HCL が苦手な開発者、動的なロジック。
Crossplane	K8s カスタムリソース	コントロールプレーン、セルフサービスプラットフォーム。
CloudFormation	YAML/JSON	AWS を徹底的に使う場合（ドリフト検出がネイティブで利用できます）。

危険信号 → security-engineer にエスカレーションしてください：

• provider ブロックに AWS キーをハードコードしている
• State ファイルを Git に保存している（terraform.tfstate）
• SSH/RDP で 0.0.0.0/0 を許可するセキュリティグループ
• S3 バケットがデフォルトでパブリックになっている

---

---

3. コアワークフロー

ワークフロー 1：本番環境向け AWS VPC（モジュール式）

目標： コミュニティモジュールを使用して、3 層の VPC ネットワークを作成します。

手順：

1. 依存関係の定義（versions.tf）

   terraform {
     required_version = ">= 1.5.0"
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.0"
       }
     }
   }
   

2. 実装（main.tf）

   module "vpc" {
     source = "terraform-aws-modules/vpc/aws"
     version = "5.5.1"
   
     name = "prod-vpc"
     cidr = "10.0.0.0/16"
   
     azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
     private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
     public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
   
     enable_nat_gateway = true
     single_nat_gateway = false # 高可用性
     enable_vpn_gateway = false
   
     tags = {
       Environment = "Production"
       Terraform   = "true"
     }
   }
   

3. 出力（outputs.tf）

   output "vpc_id" {
     description = "The ID of the VPC"
     value       = module.vpc.vpc_id
   }
   

---

---

ワークフロー 3：既存のインフラストラクチャのインポート

目標： 手動で作成した EC2 インスタンスを Terraform の管理下に置きます。

手順：

1. リソース ID を確認する

   • AWS コンソール → EC2 → インスタンス ID：i-0123456789abcdef0

2. Terraform コードを記述する

   resource "aws_instance" "legacy_server" {
     ami           = "ami-0c55b159cbfafe1f0"
     instance_type = "t2.micro"
     # その他、判明している詳細情報を入力してください...
   }
   

3. インポートを実行する

   terraform import aws_instance.legacy_server i-0123456789abcdef0
   

   （または、TF 1.5 以降では import ブロックを使用します）

   import {
     to = aws_instance.legacy_server
     id = "i-0123456789abcdef0"
   }
   

4. 整合させる

   • terraform plan を実行します。
   • 「No changes」と表示されるまで、State に一致するようコードを更新します。

---

---

5. アンチパターンと注意点

❌ アンチパターン 1：モノリシックな State ファイル

具体例：

• 1 つの main.tf で VPC、データベース、EKS、50 個のマイクロサービスを管理している。
• terraform plan に 10 分かかる。

問題点：

• 影響範囲： 1 つのエラーですべてが壊れます。
• パフォーマンス： API のレート制限（AWS のスロットリング）。
• ロック： 開発者 A が開発者 B をブロックします。

適切な方法：

• State を分割する： network、data、app-cluster を分けます。
• terraform_remote_state データソースを使って、他のレイヤーの出力を読み取ります。

❌ アンチパターン 2：環境のハードコード

具体例：

• コードが重複した vpc-prod.tf、vpc-dev.tf ファイル。

問題点：

• 環境間でドリフトが発生します。
• メンテナンスの手間が倍になります。

適切な方法：

• ワークスペース： var.environment とともに terraform workspace を使用します。
• Tfvars： prod.tfvars と dev.tfvars を使い分けます。
• モジュール： 同じロジックを再利用し、異なる変数を渡します。

❌ アンチパターン 3：.gitignore を無視する

どのような状態か：

• .terraform/ ディレクトリ（プラグイン）をコミットする。
• terraform.tfvars（シークレット）をコミットする。

なぜ問題なのか：

• リポジトリが肥大化します。
• セキュリティ漏えいにつながります。

適切な方法：

• Terraform 用の標準的な .gitignore：

  .terraform/
  *.tfstate
  *.tfstate.backup
  *.tfvars
  .terraform.lock.hcl (これはコミットします！)
  

---

---

7. 品質チェックリスト

コード品質：

• フォーマット： terraform fmt -recursive を実行します。
• 検証： terraform validate を実行します。
• Lint： プロバイダー固有の問題を確認するため、tflint を実行します。
• ドキュメント： terraform-docs を使って README を生成します。

セキュリティ：

• シークレット： 平文のシークレットがないこと（KMS/Vault/Secrets Manager を使用します）。
• 暗号化： すべてのストレージ（EBS、S3、RDS）で encrypted = true にします。
• パブリックアクセス： アクセスを制限します（S3 Block Public Access）。

信頼性：

• State： ロック機能を備えたリモートバックエンドを設定します。
• バージョン： プロバイダーと Terraform のバージョンを固定します（例：~> 5.0）。
• クリーンアップ： destroy プロビジョナーをテストするか、データベースで保護を有効にします。

アンチパターン

State 管理に関するアンチパターン

• ローカル State：ローカルの State ファイルを使用します。必ずリモートバックエンドを使用してください。
• State のドリフト：Terraform の外部で手動変更します。変更には Terraform のみを使用してください。
• State ロックの競合：State をロックしません。適切なロック機能を実装してください。
• State の破損：State ファイルを手動で編集します。State を手動で編集しないでください。

モジュールに関するアンチパターン

• モノリシックモジュール：巨大で扱いにくいモジュールです。目的に特化したモジュールに分割してください。
• ハードコードされた値：変数を使わずに値を直接指定します。すべてをパラメーター化してください。
• モジュールのバージョン管理の混乱：バージョンを固定しません。モジュールのバージョンを固定してください。
• モジュールの深いネスト：モジュール構造を過度にネストします。モジュール階層はフラットに保ってください。

リソースに関するアンチパターン

• リソースの乱用：パターンを使わず、多数の小さなリソースを作成します。リソースをグループ化してください。
• ライフサイクルの制約：更新できないリソースです。create_before_destroy の競合を避けてください。
• 変更の無視：ignore_changes を過度に使用します。変更を理解し、管理してください。
• 機密データの露出：平文のシークレットを State に保存します。sensitive フラグを使用してください。

コード整理に関するアンチパターン

• フラットな構成：ディレクトリを整理しません。モジュール構造を使用してください。
• 重複：コードブロックを繰り返し記述します。モジュールと for_each を使用してください。
• フォーマットなし：HCL コードをフォーマットしません。terraform fmt を使用してください。
• ドキュメント不足：モジュールがドキュメント化されていません。すべての入力と出力を文書化してください。