GCP入門： Terraform を使用した IaC -Vol.7-

今日は、TerraformでGCPのリソース作成について解説しています。

背景

前回の記事の続きになります。

実施内容

main.tfにて下記の緑色部分を編集します。

resource "google_compute_instance" "vm_instance" {
  name         = "terraform-instance"
  machine_type = "e2-micro"
  tags         = ["web", "dev"]

  provisioner "local-exec" {
    command = "echo ${google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip} >> ip_address.txt"
  }

  boot_disk {
    initialize_params {
      image = "cos-cloud/cos-stable"
    }
  }

  network_interface {
    network = google_compute_network.vpc_network.self_link
    access_config {
      nat_ip = google_compute_address.vm_static_ip.address
    }
  }
}

追記後、下記のコマンドを実施しました。

# 再作成の強制
terraform taint google_compute_instance.vm_instance

# 変更の適用
terraform apply

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

解説

main.tf

このprovisionerブロックについて解説し、使用する際の注意点をお伝えします。

provisioner "local-exec" {
  command = "echo ${google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip} >> ip_address.txt"
}

解説:

1. このprovisionerはlocal-execタイプで、Terraformが実行されているローカルマシン上でコマンドを実行します。
2. command属性には実行するシェルコマンドを指定します。
3. このコマンドは、Google Compute Engineインスタンス（vm_instance）のパブリックIP（NAT IP）アドレスをip_address.txtファイルに追記します。
4. >>は追記モードを意味し、ファイルが存在しない場合は新規作成されます。
5. ${...}は Terraform の変数展開構文で、インスタンスのNAT IPアドレスを参照しています。

注意点と潜在的な問題:

1. 循環依存の可能性:
   このプロビジョナーがvm_instanceリソース自体の中で定義されている場合、循環依存を引き起こす可能性があります。インスタンスの作成が完了する前にIPアドレスにアクセスしようとするためです。
2. 適切なリソース配置:
   このプロビジョナーは、vm_instanceリソースの外部で、そのリソースに依存する別のリソース（例：null_resource）内に配置するのが望ましいです。
3. 冪等性の欠如:
   このコマンドは Terraform の実行ごとにファイルに追記するため、同じIPアドレスが複数回記録される可能性があります。
4. エラーハンドリング:
   ファイルの書き込みに失敠した場合の処理が含まれていません。

改善案:

resource "google_compute_instance" "vm_instance" {
  # ... インスタンスの設定 ...
}

resource "null_resource" "save_ip" {
  triggers = {
    instance_id = google_compute_instance.vm_instance.id
  }

  provisioner "local-exec" {
    command = "echo '${google_compute_instance.vm_instance.network_interface[0].access_config[0].nat_ip}' > ip_address.txt"
  }

  depends_on = [google_compute_instance.vm_instance]
}

この改善版では:

1. null_resourceを使用して、インスタンス作成後にプロビジョナーを実行します。
2. triggersを使用して、インスタンスIDが変更された場合のみ実行されるようにしています。
3. >を使用して、ファイルを上書きモードで作成します（重複を避けるため）。
4. depends_onで明示的に依存関係を示しています。

これらの変更により、より安全で予測可能な動作が期待できます。実際の使用においては、プロジェクトの要件に応じてさらなる調整が必要になる場合があります。

terraform taint & apply

これらのコマンドについて解説いたします。各コマンドの目的と使用方法を説明します。

1. terraform taint google_compute_instance.vm_instance

目的：

• 特定のリソース（この場合は google_compute_instance.vm_instance）を “tainted”（汚染）状態にマークします。
• これにより、次の terraform apply 実行時にこのリソースが強制的に再作成されます。

使用場合：

• リソースの状態が望ましくない場合や、手動で変更が加えられた場合に使用します。
• リソースを完全に再作成したい場合に有用です。

注意点：

• このコマンドは状態を変更するだけで、実際のインフラストラクチャには影響を与えません。
• 再作成によりデータ損失のリスクがある場合は注意が必要です。

1. terraform apply

目的：

• Terraform の設定ファイル（.tf ファイル）に基づいて、インフラストラクチャの変更を適用します。

動作：

• 現在の状態と望ましい状態を比較し、必要な変更を実行します。
• taint されたリソースがある場合、それらを再作成します。

使用方法：

• 変更計画を確認してから適用するには terraform plan を先に実行することをお勧めします。
• 自動承認で適用する場合は terraform apply -auto-approve を使用できます。

1. terraform show

目的：

• 現在の状態ファイルの内容を人間が読める形式で表示します。

使用場合：

• 適用された変更を確認する際に使用します。
• リソースの現在の状態や属性を確認したい場合に有用です。

出力内容：

• 各リソースの詳細な情報（ID、属性、依存関係など）が表示されます。

これらのコマンドを順番に実行すると：

1. 特定のCompute Engineインスタンスが再作成対象としてマークされます。
2. 変更（この場合はインスタンスの再作成）が適用されます。
3. 適用後の状態が表示され、再作成されたインスタンスの新しい詳細を確認できます。

この一連の操作は、例えばインスタンスの設定を大幅に変更する必要がある場合や、インスタンスの状態をクリーンな状態にリセットしたい場合などに有用です。ただし、運用中のシステムでこれらのコマンドを使用する際は、ダウンタイムやデータ損失のリスクを慎重に評価する必要があります。

おわりに

今日は、 TerraformでGCPのリソース作成について解説しました。