【保存版】Terraform Provider完全入門 2024年版 〜AWS環境構築を10倍効率化する方法〜

SHARE

目次

目次へ

Terraformプロバイダーとは？基礎から完全解説

Terraformプロバイダーの役割と重要性

Terraformプロバイダーは、Terraformを実際のクラウドインフラストラクチャと接続する重要な「架け橋」としての役割を果たします。具体的には、以下の3つの主要な機能を提供します：

  1. APIとの通信処理
  • クラウドプロバイダーのAPIを抽象化
  • 認証情報の管理と安全な通信の実現
  • APIのバージョン差異の吸収
  1. リソース定義の提供
  • 各クラウドサービスに対応するリソースタイプの定義
  • 属性やパラメータの型定義
  • 依存関係の管理機能
  1. 状態管理の実現
  • 現在のインフラ状態の把握
  • 差分検出と適用の制御
  • ステート情報の永続化

プロバイダーの基本的な設定例：

# AWS プロバイダーの設定例
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"  # バージョン指定
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"  # 東京リージョン
  # 認証情報の設定（環境変数や共有認証情報から自動取得）
}

AWSプロバイダーを使用するメリット3選

  1. 一貫性のある環境構築
  • インフラのコード化による再現性の確保
  • 環境間の設定差異の最小化
  • バージョン管理による変更履歴の追跡
   # 複数環境での一貫した設定例
   provider "aws" {
     alias  = "production"
     region = "ap-northeast-1"
     # プロダクション用の追加設定
   }

   provider "aws" {
     alias  = "staging"
     region = "ap-northeast-1"
     # ステージング用の追加設定
   }
  1. 作業効率の大幅な向上
  • 手動作業の自動化による工数削減
  • エラーの早期発見と修正
  • 複雑な依存関係の自動解決
  1. セキュリティとコンプライアンスの強化
  • IaCによる設定の標準化
  • アクセス権限の一元管理
  • 監査ログの自動記録

プロバイダー設定のベストプラクティス

  1. バージョン管理の徹底
   terraform {
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.0"  # マイナーバージョンのみアップデート
       }
     }
     required_version = ">= 1.0.0"  # Terraformのバージョン指定
   }
  1. 認証情報の安全な管理
  • 環境変数の活用
   export AWS_ACCESS_KEY_ID="your_access_key"
   export AWS_SECRET_ACCESS_KEY="your_secret_key"
  • 共有認証情報ファイルの利用
   provider "aws" {
     shared_config_files      = ["/Users/username/.aws/config"]
     shared_credentials_files = ["/Users/username/.aws/credentials"]
     profile                  = "default"
   }
  1. プロバイダーの適切な分割
  • 環境ごとの分離
  • リージョンごとの設定
  • 責任範囲の明確化
  1. エラーハンドリングの実装
   provider "aws" {
     region = "ap-northeast-1"

     # リトライ設定
     max_retries = 3

     # カスタムエンドポイント（必要な場合）
     endpoints {
       s3 = "s3.your-domain.com"
     }
   }
  1. タグ付けの標準化
   # デフォルトタグの設定
   provider "aws" {
     default_tags {
       tags = {
         Environment = "production"
         Project     = "terraform-management"
         Owner       = "infrastructure-team"
      }
    }
   }

これらの基本概念と設定方法を理解することで、AWSリソースの効率的な管理と運用が可能になります。次のセクションでは、実際の環境構築手順について詳しく解説していきます。

AWSプロバイダ環境構築の手順を徹底解説

AWSプロバイダのインストール方法

1. 前提条件の確認

Terraformプロバイダをインストールする前に、以下の要件を満たしていることを確認してください：

  • Terraform CLI（1.0以上）のインストール
  • AWS CLIのインストール（推奨）
  • AWSアカウントの作成
  • 適切なIAM権限の設定

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

# 作業ディレクトリの作成と移動
mkdir terraform-aws-project
cd terraform-aws-project

# プロジェクトの初期化
terraform init

3. プロバイダの設定

main.tf ファイルを作成し、以下の内容を記述します：

# プロバイダーの要件定義
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

# プロバイダーの基本設定
provider "aws" {
  region = "ap-northeast-1"
}

4. OS別インストール手順

Linux/macOS

# Terraformの設定ディレクトリを作成
mkdir -p ~/.terraform.d/plugins

# プロバイダのダウンロードと展開
terraform init

Windows

# Terraformの設定ディレクトリを作成
mkdir -p $env:APPDATA\terraform.d\plugins

# プロバイダのダウンロードと展開
terraform init

5. インストールの確認

# プロバイダのバージョン確認
terraform version

# プロバイダの一覧表示
terraform providers

# 初期化状態の確認
terraform init -upgrade

6. トラブルシューティング

よくある問題と解決方法：

  1. 初期化エラー
# キャッシュのクリア
rm -rf .terraform
terraform init
  1. バージョン互換性の問題
# バージョン制約の緩和
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0.0"  # より広い範囲を指定
    }
  }
}
  1. プロキシ環境での設定
# プロキシ設定の追加
export HTTP_PROXY="http://proxy.example.com:8080"
export HTTPS_PROXY="http://proxy.example.com:8080"

認証情報の設定と管理方法

1. 認証情報の設定方法（複数の選択肢）

方法1: 環境変数を使用

# AWS認証情報の設定
export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_DEFAULT_REGION="ap-northeast-1"

方法2: 共有認証情報ファイルの使用

# ~/.aws/credentials
[default]

aws_access_key_id = your_access_key aws_secret_access_key = your_secret_key # ~/.aws/config

[default]

region = ap-northeast-1 output = json

方法3: プロバイダ設定での直接指定（非推奨）

provider "aws" {
  region     = "ap-northeast-1"
  access_key = "your_access_key"
  secret_key = "your_secret_key"
}

2. セキュリティのベストプラクティス

  • 環境変数または共有認証情報ファイルの使用を推奨
  • アクセスキーの定期的なローテーション
  • 最小権限の原則に基づいたIAMポリシーの使用
  • 機密情報のバージョン管理からの除外
# .gitignore
.terraform
*.tfstate
*.tfstate.*
.terraformrc
terraform.rc
*.tfvars

リージョン設定と管理のコツ

1. 単一リージョンの設定

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

2. マルチリージョン設定

# 東京リージョン（メイン）
provider "aws" {
  region = "ap-northeast-1"
}

# シンガポールリージョン（バックアップ）
provider "aws" {
  alias  = "singapore"
  region = "ap-southeast-1"
}

# リソースでのリージョン指定
resource "aws_instance" "example" {
  provider = aws.singapore
  # ... その他の設定
}

3. リージョン設定のベストプラクティス

  • 変数を使用したリージョン管理
variable "aws_region" {
  description = "AWS region"
  type        = string
  default     = "ap-northeast-1"
}

provider "aws" {
  region = var.aws_region
}
  • リージョン固有の設定の分離
locals {
  region_settings = {
    ap-northeast-1 = {
      instance_type = "t3.micro"
      az_count      = 3
    }
    ap-southeast-1 = {
      instance_type = "t3.small"
      az_count      = 2
    }
  }
}

これで環境構築の基本設定は完了です。次のセクションでは、実際のインフラ構築の自動化について解説していきます。

実践！AWSプロバイダでインフラ構築を自動化

EC2インスタンスの作成と管理

1. 基本的なEC2インスタンスの作成

まずは、シンプルなEC2インスタンスを作成する例から始めましょう：

# Amazon Linux 2の最新AMIを取得
data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

# セキュリティグループの作成
resource "aws_security_group" "allow_ssh" {
  name        = "allow_ssh"
  description = "Allow SSH inbound traffic"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "SSH from anywhere"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "allow_ssh"
  }
}

# EC2インスタンスの作成
resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = "t3.micro"

  subnet_id                   = aws_subnet.public.id
  vpc_security_group_ids      = [aws_security_group.allow_ssh.id]
  associate_public_ip_address = true

  root_block_device {
    volume_size = 20
    volume_type = "gp3"
  }

  tags = {
    Name = "WebServer"
    Environment = "production"
  }

  user_data = <<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              EOF
}

2. 高度な設定オプション

AutoScalingの設定
# 起動テンプレートの作成
resource "aws_launch_template" "web_server" {
  name_prefix   = "web-server"
  image_id      = data.aws_ami.amazon_linux_2.id
  instance_type = "t3.micro"

  network_interfaces {
    associate_public_ip_address = true
    security_groups            = [aws_security_group.allow_ssh.id]
  }

  user_data = base64encode(<<-EOF
              #!/bin/bash
              yum update -y
              yum install -y httpd
              systemctl start httpd
              systemctl enable httpd
              EOF
  )

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name = "WebServer"
    }
  }
}

# AutoScaling Groupの作成
resource "aws_autoscaling_group" "web_server" {
  desired_capacity    = 2
  max_size           = 4
  min_size           = 1
  target_group_arns  = [aws_lb_target_group.web_server.arn]
  vpc_zone_identifier = [aws_subnet.public_1.id, aws_subnet.public_2.id]

  launch_template {
    id      = aws_launch_template.web_server.id
    version = "$Latest"
  }

  tag {
    key                 = "Name"
    value               = "WebServer"
    propagate_at_launch = true
  }
}

3. 運用管理のベストプラクティス

インスタンス監視の設定
# CloudWatch Alarmの設定
resource "aws_cloudwatch_metric_alarm" "high_cpu" {
  alarm_name          = "high-cpu-usage"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = "2"
  metric_name        = "CPUUtilization"
  namespace          = "AWS/EC2"
  period             = "300"
  statistic          = "Average"
  threshold          = "80"
  alarm_description  = "This metric monitors ec2 cpu utilization"
  alarm_actions      = [aws_sns_topic.alerts.arn]

  dimensions = {
    InstanceId = aws_instance.web_server.id
  }
}
バックアップの自動化
# バックアップポリシーの作成
resource "aws_backup_plan" "example" {
  name = "daily_backup_plan"

  rule {
    rule_name         = "daily_backup"
    target_vault_name = aws_backup_vault.example.name
    schedule          = "cron(0 12 * * ? *)"

    lifecycle {
      delete_after = 14
    }
  }
}

# バックアップ対象の選択
resource "aws_backup_selection" "example" {
  name         = "ec2_backup_selection"
  iam_role_arn = aws_iam_role.backup.arn
  plan_id      = aws_backup_plan.example.id

  resources = [
    aws_instance.web_server.arn
  ]
}

VPCネットワークの構築方法

1. 基本的なVPC構成

# VPCの作成
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "main"
  }
}

# パブリックサブネットの作成
resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "Public Subnet ${count.index + 1}"
  }
}

# インターネットゲートウェイの作成
resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "Main IGW"
  }
}

# ルートテーブルの設定
resource "aws_route_table" "public" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main.id
  }

  tags = {
    Name = "Public Route Table"
  }
}

2. セキュリティ設定

# NACLの設定
resource "aws_network_acl" "main" {
  vpc_id = aws_vpc.main.id

  egress {
    protocol   = "-1"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 0
    to_port    = 0
  }

  ingress {
    protocol   = "tcp"
    rule_no    = 100
    action     = "allow"
    cidr_block = "0.0.0.0/0"
    from_port  = 80
    to_port    = 80
  }

  tags = {
    Name = "Main NACL"
  }
}

S3バケットとアクセス制御

1. 基本的なS3バケットの作成

# S3バケットの作成
resource "aws_s3_bucket" "content" {
  bucket = "my-unique-bucket-name-${data.aws_caller_identity.current.account_id}"

  tags = {
    Name        = "Content Bucket"
    Environment = "Production"
  }
}

# バケットの暗号化設定
resource "aws_s3_bucket_server_side_encryption_configuration" "content" {
  bucket = aws_s3_bucket.content.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

# パブリックアクセスのブロック
resource "aws_s3_bucket_public_access_block" "content" {
  bucket = aws_s3_bucket.content.id

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

2. バケットポリシーの設定

# バケットポリシーの作成
resource "aws_s3_bucket_policy" "content" {
  bucket = aws_s3_bucket.content.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "DenyHttpRequests"
        Effect    = "Deny"
        Principal = "*"
        Action    = "s3:*"
        Resource  = [
          aws_s3_bucket.content.arn,
          "${aws_s3_bucket.content.arn}/*"
        ]
        Condition = {
          Bool = {
            "aws:SecureTransport": "false"
          }
        }
      }
    ]
  })
}

3. ライフサイクルルールの設定

# ライフサイクルルールの設定
resource "aws_s3_bucket_lifecycle_configuration" "content" {
  bucket = aws_s3_bucket.content.id

  rule {
    id     = "archive_old_files"
    status = "Enabled"

    transition {
      days          = 90
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 180
      storage_class = "GLACIER"
    }

    expiration {
      days = 365
    }
  }
}

これらの実装例を基に、実際の要件に合わせてカスタマイズしていくことで、効率的なインフラ構築が可能になります。次のセクションでは、実装時によく発生するトラブルとその解決方法について解説していきます。

困ったときの対処法とトラブルシューティング

よくあるエラーと解決方法

1. 認証関連のエラー

エラーパターン1: クレデンシャルが見つからない
Error: NoCredentialProviders: no valid providers in chain

原因と解決策:

  1. 環境変数の確認
# 環境変数の設定
export AWS_ACCESS_KEY_ID="your_access_key"
export AWS_SECRET_ACCESS_KEY="your_secret_key"
export AWS_REGION="ap-northeast-1"

# 環境変数の確認
env | grep AWS
  1. 共有認証情報ファイルの確認
# ~/.aws/credentials の確認
cat ~/.aws/credentials

# 権限の確認
ls -la ~/.aws/
  1. IAMロールの確認
# プロバイダー設定でのプロファイル指定
provider "aws" {
  profile = "default"
  region  = "ap-northeast-1"
}

2. リソース作成エラー

エラーパターン2: 重複リソース
Error: Resource already exists

解決手順:

  1. 既存リソースのインポート
# 既存リソースの状態をインポート
terraform import aws_instance.example i-1234567890abcdef0

# 状態の確認
terraform show
  1. リソース名の変更
# リソース名を一意に設定
resource "aws_instance" "web_server_2024" {
  # ... 設定 ...
}
エラーパターン3: 依存関係エラー
Error: Resource depends on non-existent resource

解決策:

  1. 依存関係の明示的な指定
# depends_onの使用
resource "aws_instance" "web" {
  # ... 設定 ...
  depends_on = [
    aws_vpc.main,
    aws_subnet.public
  ]
}
  1. データソースの活用
# 既存リソースの参照
data "aws_vpc" "existing" {
  id = "vpc-1234567890abcdef0"
}

resource "aws_subnet" "new" {
  vpc_id = data.aws_vpc.existing.id
  # ... その他の設定 ...
}

3. 状態管理のエラー

エラーパターン4: 状態ファイルの競合
Error: Error loading state: state file is locked

解決手順:

  1. ロックの強制解除
# 強制的なロック解除（注意して使用）
terraform force-unlock LOCK_ID
  1. リモート状態管理の設定
# S3バックエンドの設定
terraform {
  backend "s3" {
    bucket = "terraform-state-bucket"
    key    = "prod/terraform.tfstate"
    region = "ap-northeast-1"
    dynamodb_table = "terraform-locks"
    encrypt = true
  }
}

デバッグとログ確認の方法

1. デバッグログの有効化

# 詳細なログ出力の有効化
export TF_LOG=DEBUG
export TF_LOG_PATH=./terraform.log

# プロバイダーデバッグログの有効化
export AWS_DEBUG=true

2. プランの詳細確認

# 詳細なプラン出力
terraform plan -detailed-exitcode -out=plan.out

# プランの可視化
terraform show -json plan.out | jq

3. 状態の検査とデバッグ

# 状態ファイルの内容確認
terraform show

# 特定のリソースの状態確認
terraform state show aws_instance.web

# 状態のバックアップ
terraform state pull > terraform.backup

アップデート時の注意点と互換性確認

1. バージョン管理のベストプラクティス

# バージョン制約の指定
terraform {
  required_version = ">= 1.0.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"  # メジャーバージョンの固定
    }
  }
}

2. アップデート手順

  1. バージョン情報の確認
# 現在のバージョン確認
terraform version
terraform providers

# 利用可能なアップデートの確認
terraform init -upgrade
  1. 段階的なアップデート
# プロバイダーの更新
terraform init -upgrade

# 設定の妥当性確認
terraform validate

# プランの確認
terraform plan

3. 互換性問題の対処

  1. 非互換性の検出
# terraform 0.12upgrade コマンドの実行（古いバージョンの場合）
terraform 0.12upgrade

# 設定ファイルの検証
terraform validate
  1. バージョン固定による安定化
# プロバイダーバージョンの固定
provider "aws" {
  version = "= 5.0.0"  # 特定バージョンに固定
}
  1. マイグレーションの実施
# 状態のバックアップ
terraform state pull > terraform.backup

# マイグレーションの実行
terraform init -migrate-state

# 状態の検証
terraform plan

これらのトラブルシューティング手法を理解することで、多くの一般的な問題に効率的に対処できるようになります。次のセクションでは、実務で使える高度な活用テクニックについて解説していきます。

実務で使えるAWSプロバイダ活用テクニック

モジュール化によるコード再利用の方法

1. モジュール設計の基本原則

ディレクトリ構造の例
terraform-aws-project/
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   ├── ec2/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── README.md
│   └── s3/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       └── README.md
├── environments/
│   ├── prod/
│   │   ├── main.tf
│   │   ├── terraform.tfvars
│   │   └── backend.tf
│   └── dev/
│       ├── main.tf
│       ├── terraform.tfvars
│       └── backend.tf
└── README.md
再利用可能なVPCモジュールの例
# modules/vpc/variables.tf
variable "project_name" {
  type        = string
  description = "プロジェクト名"
}

variable "environment" {
  type        = string
  description = "環境名（dev/stg/prod）"
}

variable "vpc_cidr" {
  type        = string
  description = "VPCのCIDRブロック"
  default     = "10.0.0.0/16"
}

# modules/vpc/main.tf
resource "aws_vpc" "main" {
  cidr_block           = var.vpc_cidr
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "${var.project_name}-${var.environment}-vpc"
    Environment = var.environment
    Project     = var.project_name
    Terraform   = "true"
  }
}

# modules/vpc/outputs.tf
output "vpc_id" {
  value       = aws_vpc.main.id
  description = "作成されたVPCのID"
}

2. モジュールの使用例

環境別の設定
# environments/prod/main.tf
module "vpc" {
  source = "../../modules/vpc"

  project_name = "example"
  environment  = "prod"
  vpc_cidr     = "10.0.0.0/16"
}

module "ec2" {
  source = "../../modules/ec2"

  vpc_id       = module.vpc.vpc_id
  environment  = "prod"
  instance_type = "t3.medium"
}

変数管理とワークスペース活用のコツ

1. 変数管理のベストプラクティス

環境別の変数ファイル
# environments/prod/terraform.tfvars
project_name    = "example"
environment     = "prod"
instance_type   = "t3.medium"
vpc_cidr        = "10.0.0.0/16"
enable_backup   = true

# environments/dev/terraform.tfvars
project_name    = "example"
environment     = "dev"
instance_type   = "t3.micro"
vpc_cidr        = "10.1.0.0/16"
enable_backup   = false
変数の型定義と検証
# variables.tf
variable "environment" {
  type        = string
  description = "環境名"
  validation {
    condition     = contains(["dev", "stg", "prod"], var.environment)
    error_message = "環境名は'dev'、'stg'、'prod'のいずれかである必要があります。"
  }
}

variable "instance_type" {
  type        = string
  description = "EC2インスタンスタイプ"
  validation {
    condition     = can(regex("^t[23]\\.", var.instance_type))
    error_message = "指定されたインスタンスタイプは許可されていません。"
  }
}

2. ワークスペースの効果的な活用

ワークスペースの設定
# ワークスペースの作成と切り替え
terraform workspace new prod
terraform workspace new dev
terraform workspace select prod
ワークスペースに基づく条件分岐
locals {
  workspace_config = {
    prod = {
      instance_type = "t3.medium"
      min_size      = 2
      max_size      = 4
    }
    dev = {
      instance_type = "t3.micro"
      min_size      = 1
      max_size      = 2
    }
  }

  config = local.workspace_config[terraform.workspace]
}

resource "aws_instance" "app" {
  instance_type = local.config.instance_type
  # ... その他の設定 ...
}

チーム開発におけるベストプラクティス

1. コード品質の維持

pre-commitフックの設定
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/antonbabenko/pre-commit-terraform
    rev: v1.50.0
    hooks:
      - id: terraform_fmt
      - id: terraform_docs
      - id: terraform_tflint
      - id: terraform_validate
コーディング規約の例
# 命名規則の例
resource "aws_instance" "web_server" {  # スネークケースを使用
  instance_type = "t3.micro"

  tags = {
    Name        = "${var.project}-${var.environment}-web"  # 一貫した命名パターン
    Environment = var.environment
    Terraform   = "true"
  }
}

2. チームワークフロー

Pull Requestテンプレート
# .github/pull_request_template.md
## 変更内容
- [ ] インフラの追加/変更/削除
- [ ] モジュールの追加/変更
- [ ] 設定の更新

## 確認項目
- [ ] terraform fmt実行済み
- [ ] terraform validate確認済み
- [ ] terraformプラン確認済み
- [ ] セキュリティ上の影響なし
CIパイプラインの設定
# .github/workflows/terraform.yml
name: Terraform

on:
  pull_request:
    paths:
      - '**.tf'
      - '**.tfvars'

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1

      - name: Terraform Format
        run: terraform fmt -check

      - name: Terraform Init
        run: terraform init

      - name: Terraform Validate
        run: terraform validate

      - name: Terraform Plan
        run: terraform plan

3. セキュリティとコンプライアンス

セキュリティポリシーの実装
# policies/security.tf
resource "aws_iam_policy" "strict_security" {
  name        = "strict-security-policy"
  description = "セキュリティ要件に基づいたポリシー"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Deny"
        Action = [
          "s3:*"
        ]
        Resource = "*"
        Condition = {
          Bool = {
            "aws:SecureTransport": "false"
          }
        }
      }
    ]
  })
}
コンプライアンスチェック
# compliance/rules.tf
resource "aws_config_config_rule" "require_tag" {
  name = "require-tags"

  source {
    owner             = "AWS"
    source_identifier = "REQUIRED_TAGS"
  }

  input_parameters = jsonencode({
    tag1Key   = "Environment"
    tag1Value = "prod,dev,stg"
    tag2Key   = "Project"
  })
}

これらの実務テクニックを適切に組み合わせることで、チーム開発の効率化と品質の向上を実現できます。特に大規模なプロジェクトでは、これらのプラクティスが重要な役割を果たします。

前の記事

【保守性爆上げ】Terraform localsの5つの実践的…

次の記事

【保存版】Terraformのfor_eachを完全解説！7つ…