【保存版】terraform applyの使い方完全ガイド！実務で使える12のテクニック

SHARE

目次

目次へ

terraform applyとは？基本から理解する実行の仕組み

Terraformを使用したインフラストラクチャの構築において、terraform applyは最も重要なコマンドの1つです。このコマンドは、定義されたインフラストラクチャのコード（HCL）を実際のクラウドリソースとして展開する役割を担っています。

terraform applyが実行する3つの主要な処理フロー

terraform applyコマンドは、以下の3つの主要な処理フローを実行します：

  1. 構成ファイルの読み込みと検証
  • .tfファイルの構文チェック
  • 変数の解決と型チェック
  • プロバイダーの初期化確認
   # 構成ファイルの例
   provider "aws" {
     region = "ap-northeast-1"
   }

   resource "aws_instance" "example" {
     ami           = "ami-0c3fd0f5d33134a76"
     instance_type = "t3.micro"

     tags = {
       Name = "terraform-example"
     }
   }
  1. 実行計画の生成（暗黙的なplan）
  • 現在の状態（state）の読み込み
  • 目標状態との差分計算
  • リソース間の依存関係の解析
   実行計画の出力例：
   Terraform will perform the following actions:

     # aws_instance.example will be created
     + resource "aws_instance" "example" {
         + ami                          = "ami-0c3fd0f5d33134a76"
         + instance_type               = "t3.micro"
         + tags                        = {
             + "Name" = "terraform-example"
           }
         # ... その他の属性
       }

   Plan: 1 to add, 0 to change, 0 to destroy.
  1. リソースの作成/更新/削除の実行
  • プロバイダーAPIを使用したリソース操作
  • 状態ファイルの更新
  • 実行結果のレポート生成

plan結果との関係性を理解しよう

terraform applyは、terraform planコマンドと密接な関係があります：

  1. 暗黙的なplanの実行
  • applyコマンド実行時に、自動的にplanが実行される
  • この結果は、明示的なplan実行時と同じ
  1. plan結果の再利用
   # planの結果をファイルに保存
   terraform plan -out=tfplan

   # 保存したplan結果を使用してapply
   terraform apply tfplan
  1. 差分の確認と実行の一貫性
  • plan時と実行時の差分がある場合は警告
  • ステート競合を防ぐためのロック機能
planとapplyの比較planapply
リソース変更の実行×○
差分の計算○○
実行計画の表示○○
ステート更新×○
承認プロンプト×○
  1. 実行の安全性確保
  • apply実行前の最終確認プロンプト
  • 予期せぬ変更の防止
  • ロールバック可能な変更管理

terraform applyの処理フローを理解することで、より安全で効率的なインフラストラクチャの管理が可能になります。特に、planとの関係性を把握することで、意図しない変更を防ぎ、確実なインフラストラクチャのデプロイメントを実現できます。

terraform applyコマンドの基本的な使い方

基本的なコマンド構文と必須オプション

terraform applyコマンドの基本構文は以下の通りです：

terraform apply [オプション] [ディレクトリ]

主要なオプション一覧：

オプション説明使用例
-auto-approve承認プロンプトをスキップterraform apply -auto-approve
-var変数の値を指定terraform apply -var="env=prod"
-var-file変数定義ファイルを指定terraform apply -var-file="prod.tfvars"
-target特定のリソースのみを対象terraform apply -target=aws_instance.web
-parallelism並列実行数を設定terraform apply -parallelism=5

コマンド実行の基本的な流れ：

# 1. 初期化（まだ実行していない場合）
terraform init

# 2. 基本的なapply実行
terraform apply

# 3. 変数を指定してapply
terraform apply -var="environment=production"

# 4. 特定のリソースのみを対象にapply
terraform apply -target=aws_instance.example

実行結果の見方と成功/失敗の判断方法

terraform applyの実行結果は、以下のような形式で表示されます：

Terraform will perform the following actions:

  # aws_instance.example will be created
  + resource "aws_instance" "example" {
      + ami           = "ami-0c3fd0f5d33134a76"
      + instance_type = "t3.micro"
      + tags         = {
          + "Name" = "example-instance"
        }
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value:

実行結果の判断ポイント：

  1. 実行前の計画確認
  • + : リソースの追加
  • - : リソースの削除
  • ~ : リソースの更新
  • ± : リソースの置き換え
  1. 実行状況の確認
   aws_instance.example: Creating...
   aws_instance.example: Still creating... [10s elapsed]
   aws_instance.example: Creation complete after 30s [id=i-1234567890abcdef0]
  1. エラー出力の例
   Error: Error launching source instance: InvalidKeyPair.NotFound: 
   The key pair 'missing-key' does not exist

実行結果の判断基準：

状態特徴対応方法
成功– 緑色のSuccess表示
– エラーメッセージなし
– 状態ファイルの更新完了		次の作業へ進行
警告– 黄色の警告表示
– 処理は継続
– 注意が必要な情報		警告内容の確認と記録
失敗– 赤色のError表示
– 処理が中断
– エラーメッセージあり		エラー内容の分析と修正

自動承認オプション-auto-approveの使い所

-auto-approveオプションは、承認プロンプトをスキップして直接実行を開始します：

terraform apply -auto-approve

auto-approveの適切な使用シーン：

  1. CI/CDパイプラインでの自動デプロイ
   # GitLab CI/CD設定例
   deploy:
     script:
       - terraform init
       - terraform apply -auto-approve
  1. テスト環境での迅速なデプロイ
   # テスト環境用のスクリプト例
   #!/bin/bash
   terraform init
   terraform apply -auto-approve -var-file="test.tfvars"

auto-approveの使用に関する注意点：

  1. 本番環境での使用は推奨されない
  • 意図しない変更のリスク
  • 手動確認の重要性
  1. 使用が適切なケース
  • 自動化されたテスト環境
  • 開発環境での反復的なデプロイ
  • 十分にテストされたCI/CDパイプライン
  1. セキュリティ考慮事項
  • 権限管理の徹底
  • 監査ログの有効化
  • 実行結果の確認プロセス

terraform applyコマンドを効果的に使用するためには、これらの基本的な使い方を理解し、適切なオプションを状況に応じて選択することが重要です。特に本番環境での運用では、auto-approveの使用は慎重に判断し、適切な承認プロセスを確立することが推奨されます。

実務で使えるterraform apply実行テクニック

目標リソースを指定して実行する方法

特定のリソースのみを対象とした実行は、大規模なインフラストラクチャの管理において非常に重要なテクニックです。

  1. targetオプションの活用
# インフラ構成例
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "main"
  }
}

resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"

  tags = {
    Name = "Public Subnet"
  }
}

特定のリソースのみを適用：

# VPCのみを作成/更新
terraform apply -target=aws_vpc.main

# サブネットのみを作成/更新
terraform apply -target=aws_subnet.public
  1. 複数リソースの指定
# 複数のリソースを指定して適用
terraform apply -target=aws_vpc.main -target=aws_subnet.public

注意点：

  • 依存関係の自動解決は行われる
  • 指定したリソース以外は変更されない
  • 過度な使用は推奨されない

変数ファイルを使用した柔軟な環境移行

環境ごとの設定を効率的に管理するための変数ファイル活用テクニック：

  1. 環境別の変数ファイル作成
# variables.tf
variable "environment" {
  type = string
}

variable "instance_type" {
  type = string
}

variable "vpc_cidr" {
  type = string
}
# dev.tfvars
environment    = "development"
instance_type  = "t3.micro"
vpc_cidr       = "10.0.0.0/16"
# prod.tfvars
environment    = "production"
instance_type  = "t3.medium"
vpc_cidr       = "172.16.0.0/16"
  1. 変数ファイルの使用方法
# 開発環境への適用
terraform apply -var-file="dev.tfvars"

# 本番環境への適用
terraform apply -var-file="prod.tfvars"
  1. 環境固有の設定管理
# main.tf
resource "aws_instance" "app" {
  ami           = data.aws_ami.amazon_linux_2.id
  instance_type = var.instance_type

  tags = {
    Environment = var.environment
    Name        = "${var.environment}-app-server"
  }
}

高度な変数管理テクニック：

テクニック使用例メリット
階層化された変数ファイルcommon.tfvars + env固有.tfvars設定の重複を防ぐ
条件分岐による制御count/for_eachと変数の組み合わせ環境ごとの柔軟な制御
ワークスペース活用terraform workspaceと組み合わせ環境の完全な分離

実行数の調整によるパフォーマンス最適化

大規模なインフラストラクチャの適用時のパフォーマンスを最適化するテクニック：

  1. 並列実行数の調整
# 並列実行数を指定して適用
terraform apply -parallelism=20
  1. リソースの依存関係最適化
# 依存関係の明示的な指定
resource "aws_instance" "web" {
  # ... 設定 ...
  depends_on = [aws_vpc.main, aws_subnet.public]
}
  1. パフォーマンス最適化のベストプラクティス
# モジュール分割の例
module "networking" {
  source = "./modules/networking"
  # ... 変数 ...
}

module "compute" {
  source = "./modules/compute"
  depends_on = [module.networking]
  # ... 変数 ...
}

パフォーマンス最適化のポイント：

  1. 実行時の考慮事項
  • リソース数と依存関係の把握
  • APIレート制限への配慮
  • 実行時間の見積もり
  1. 最適化テクニック
   # for_eachを使用した効率的なリソース作成
   resource "aws_instance" "servers" {
     for_each = toset(["web", "app", "db"])

     ami           = data.aws_ami.amazon_linux_2.id
     instance_type = var.instance_type

     tags = {
       Name = "server-${each.key}"
     }
   }
  1. モニタリングと調整
  • 実行時間の計測
  • ボトルネックの特定
  • 段階的な調整

これらのテクニックを適切に組み合わせることで、効率的なTerraform運用が可能になります。特に大規模な環境では、これらのテクニックの重要性が増してきます。実務での適用においては、環境や要件に応じて適切なテクニックを選択し、必要に応じて組み合わせることが重要です。

エラー対処方法と実行時の注意点

よくあるエラーメッセージと解決方法

terraform applyを実行する際によく遭遇するエラーとその解決方法を解説します。

  1. 初期化関連のエラー
Error: Provider configuration not present

Provider "aws" was not configured. Please configure the provider as described in 
the documentation.

解決方法:

# プロバイダーの初期化
terraform init

# プロバイダーの再初期化（キャッシュクリア）
terraform init -upgrade
  1. 認証関連のエラー
Error: error configuring Terraform AWS Provider: no valid credential sources 
for Terraform AWS Provider found.

解決方法:

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

# または、AWS CLIのプロファイル使用
export AWS_PROFILE="your_profile"
  1. リソース依存関係のエラー
Error: Error creating Security Group: VPC ID is not valid

よくあるエラーとその対処方法：

エラーカテゴリ一般的な原因解決方法
構文エラーHCL構文の誤りコードのフォーマット確認とバリデーション
権限エラーIAM権限不足必要な権限の追加
リソース制限クォータ超過リソース制限の確認と申請
API制限リクエスト過多並列実行数の調整

ステートロックによるチーム運用での衝突防止

ステートロックは複数メンバーでの同時操作を防ぐ重要な機能です：

  1. ステートロックの設定
# backend設定例
terraform {
  backend "s3" {
    bucket         = "terraform-state-bucket"
    key            = "terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-lock"
  }
}
  1. DynamoDBでのロックテーブル作成
resource "aws_dynamodb_table" "terraform_lock" {
  name           = "terraform-lock"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}
  1. ロック関連の問題解決
# 強制的なロック解除（注意して使用）
terraform force-unlock LOCK_ID

ステートロック使用時の注意点：

  • ロックの有効期限設定
  • 手動解除の基準策定
  • バックエンドの冗長化検討

実行前に確認すべき4つのチェックポイント

  1. 構成ファイルの検証
   # フォーマットチェック
   terraform fmt -check

   # 構文検証
   terraform validate
  1. 変更内容の確認
   # 詳細な実行計画の確認
   terraform plan -detailed-exitcode

実行前チェックリスト：

チェック項目確認内容コマンド/方法
コード品質フォーマット・構文terraform fmt -check
実行計画リソース変更内容terraform plan
権限確認必要なIAM権限IAMポリシーの確認
依存関係リソース間の依存グラフ生成・確認
  1. 環境固有の注意点

本番環境での実行前チェックポイント：

# ワークスペースの確認
terraform workspace show

# 変数値の確認
terraform console
> var.environment
> var.region
  1. セーフガードの確認
# 重要なリソースの保護例
lifecycle {
  prevent_destroy = true
}

実行時の追加的な注意点：

  1. バックアップと復旧計画
  • 状態ファイルのバックアップ
  • ロールバック手順の準備
  • 緊急時の対応手順
  1. モニタリングの確認
   # CloudWatchメトリクスの確認
   aws cloudwatch get-metric-statistics ...
  1. 通知設定の確認
   # SNSトピック設定例
   resource "aws_sns_topic" "terraform_notification" {
     name = "terraform-apply-notification"
   }

これらの注意点とチェックポイントを適切に実施することで、安全かつ確実なTerraform実行が可能になります。特に本番環境での実行においては、これらのチェックを確実に実施することが重要です。

本番環境でのterraform apply実践ガイド

CI/CDパイプラインでの自動実行設定

本番環境でのTerraform実行を自動化するための、CI/CDパイプライン構築方法を解説します。

  1. GitLab CIでの実装例
# .gitlab-ci.yml
variables:
  TF_ROOT: ${CI_PROJECT_DIR}/terraform
  TF_STATE_NAME: ${CI_PROJECT_NAME}-${CI_ENVIRONMENT_NAME}

stages:
  - validate
  - plan
  - apply

terraform-validate:
  stage: validate
  script:
    - cd ${TF_ROOT}
    - terraform init
    - terraform validate
    - terraform fmt -check

terraform-plan:
  stage: plan
  script:
    - cd ${TF_ROOT}
    - terraform init
    - terraform plan -out=tfplan
  artifacts:
    paths:
      - tfplan

terraform-apply:
  stage: apply
  script:
    - cd ${TF_ROOT}
    - terraform init
    - terraform apply tfplan
  when: manual
  environment:
    name: production
  only:
    - main
  1. GitHub Actionsでの実装例
# .github/workflows/terraform.yml
name: 'Terraform CI/CD'

on:
  push:
    branches:
      - main
  pull_request:

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

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

    - name: Terraform Init
      run: terraform init

    - name: Terraform Plan
      run: terraform plan -out=tfplan

    - name: Terraform Apply
      if: github.ref == 'refs/heads/main'
      run: terraform apply tfplan
      env:
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

承認フローを組み込んだ安全な実行方法

本番環境での安全な実行のための承認フロー実装：

  1. マルチステージ承認プロセス
# 承認状態管理用のDynamoDBテーブル
resource "aws_dynamodb_table" "approval_status" {
  name           = "terraform-approval-status"
  billing_mode   = "PAY_PER_REQUEST"
  hash_key       = "RequestId"

  attribute {
    name = "RequestId"
    type = "S"
  }

  tags = {
    Environment = "production"
  }
}
  1. 承認フロー実装例
#!/bin/bash
# approve_terraform.sh

# 承認リクエストの作成
request_id=$(uuidgen)
aws dynamodb put-item \
  --table-name terraform-approval-status \
  --item '{"RequestId": {"S": "'$request_id'"}, "Status": {"S": "pending"}}'

# Slack通知の送信
curl -X POST -H 'Content-type: application/json' \
  --data '{"text":"新しいTerraform実行リクエスト: '$request_id'"}' \
  $SLACK_WEBHOOK_URL

# 承認待ち
while true; do
  status=$(aws dynamodb get-item \
    --table-name terraform-approval-status \
    --key '{"RequestId": {"S": "'$request_id'"}}' \
    --query 'Item.Status.S' \
    --output text)

  if [ "$status" = "approved" ]; then
    terraform apply -auto-approve
    break
  fi
  sleep 30
done

承認フローのベストプラクティス：

フェーズ確認項目担当者
計画レビューリソース変更内容インフラ担当者
セキュリティ承認セキュリティ要件セキュリティチーム
最終承認ビジネスインパクトサービス責任者

実行結果の監査ログ取得と分析方法

  1. CloudTrail統合による監査ログ設定
# CloudTrail設定
resource "aws_cloudtrail" "terraform_audit" {
  name                          = "terraform-audit-trail"
  s3_bucket_name               = aws_s3_bucket.audit_logs.id
  include_global_service_events = true

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

# ログ保存用S3バケット
resource "aws_s3_bucket" "audit_logs" {
  bucket = "terraform-audit-logs-${data.aws_caller_identity.current.account_id}"

  versioning {
    enabled = true
  }
}
  1. ログ分析の実装
# analyze_terraform_logs.py
import boto3
import json
from datetime import datetime, timedelta

def analyze_terraform_events():
    cloudtrail = boto3.client('cloudtrail')

    response = cloudtrail.lookup_events(
        LookupAttributes=[
            {
                'AttributeKey': 'EventSource',
                'AttributeValue': 'terraform.amazonaws.com'
            }
        ],
        StartTime=datetime.now() - timedelta(days=7)
    )

    return response['Events']
  1. 監査レポートの自動生成
#!/bin/bash
# generate_audit_report.sh

# CloudWatchログの取得
aws logs filter-log-events \
  --log-group-name "/aws/terraform" \
  --filter-pattern "terraform apply" \
  --start-time $(date -d '7 days ago' +%s000) \
  --query 'events[*].message' \
  --output text > terraform_audit.log

# レポート生成
cat terraform_audit.log | \
  jq -r '. | select(.eventName=="ApplyChanges") | \
    [.eventTime, .userIdentity.userName, .resources[].resourceName] | @csv' \
  > audit_report.csv

監査ログ分析のポイント：

  1. 重要な監視項目
  • リソース変更の履歴
  • 実行者の特定
  • エラーパターンの分析
  1. アラート設定
   # CloudWatch アラーム設定
   resource "aws_cloudwatch_metric_alarm" "terraform_errors" {
     alarm_name          = "terraform-apply-errors"
     comparison_operator = "GreaterThanThreshold"
     evaluation_periods  = "1"
     metric_name        = "ErrorCount"
     namespace          = "TerraformMetrics"
     period             = "300"
     statistic          = "Sum"
     threshold          = "0"
     alarm_description  = "Terraform apply errors detected"
     alarm_actions      = [aws_sns_topic.terraform_alerts.arn]
   }
  1. レポーティング自動化
  • 定期実行スクリプト
  • メール通知設定
  • ダッシュボード作成

本番環境でのTerraform運用においては、これらの要素を適切に組み合わせることで、安全で追跡可能な実行環境を構築することができます。特に、承認フローと監査ログの整備は、組織的な運用において重要な役割を果たします。

前の記事

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

次の記事

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