Gemini | MISO https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com 未来を創造するITのミソ Mon, 26 May 2025 01:36:55 +0000 ja hourly 1 https://wordpress.org/?v=6.7.2 https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/wp-content/uploads/2017/09/tdi_300-300-300x280.png Gemini | MISO https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com 32 32 Geminiに聞くTerraformのベストプラクティス10箇条(後編) https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/gemini-terraform-bestpractice10-2 Thu, 22 May 2025 04:32:15 +0000 https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/?p=19016 はじめに 前回の記事では、Googleの生成AIであるGeminiにTerraformのベストプラクティス10箇条を聞き、出力された内容の詳細を5箇条解説しました。後編となる今回は、前編で書ききれなかった5箇条の詳細を書…

The post Geminiに聞くTerraformのベストプラクティス10箇条(後編) first appeared on MISO.]]>
はじめに

前回の記事では、Googleの生成AIであるGeminiにTerraformのベストプラクティス10箇条を聞き、出力された内容の詳細を5箇条解説しました。後編となる今回は、前編で書ききれなかった5箇条の詳細を書いていきます。
前回記事はこちらをご覧ください。

 

ベストプラクティス10箇条(後編)

6.状態管理の徹底

Terraformの状態ファイルは、インフラストラクチャの現在の状態を記録した重要なファイルです。状態管理を徹底することで、Terraformを安全かつ効率的に運用しインフラストラクチャの整合性を保つことができます。

①リモート状態の利用

ローカルでの状態管理は共有やバージョン管理が困難で、削除リスクも伴います。一方、クラウドストレージやTerraform Cloudを利用するリモート状態管理は安全な共有と管理を可能にし、チームでの共同作業を円滑にします。
 

②状態のバックアップ

状態ファイルの定期的なバックアップは、障害時の復元に不可欠です。クラウドストレージのバージョン管理機能を利用すれば、過去の状態も復元可能です。また、バックアップは元のファイルとは異なる場所に保管することで、データ損失のリスクを最小限に抑えられます。
 

③状態の暗号化

状態ファイルには機密情報が含まれるため、保護が重要です。クラウドストレージの暗号化機能やHashiCorp Vaultなどの秘密管理ツールを用いてファイルを暗号化し、セキュリティを強化します。
 

④状態のバージョン管理

状態ファイルをGitなどのバージョン管理システムで管理すれば、変更履歴の追跡と必要に応じた状態復元が可能です。変更時には、内容を明確にするコミットメッセージを記述し、管理を徹底します。
 

⑤状態のロック

複数人が同時にterraform applyを実行すると状態ファイルが競合し、インフラストラクチャが不安定化する可能性があります。Terraform Cloudや-lock、-lock-timeoutオプションを使用して状態ファイルへのアクセスをロックし、同時実行を防ぎます。
 

⑥状態の分割

大規模インフラでは、状態ファイルを分割することで管理性とパフォーマンスが向上します。モジュールごとにファイルを分割すれば、独立性と再利用性が高まります。
 

⑦状態の定期的なレビュー

状態ファイルには、削除済みリソースの情報が残ることがあります。定期的なレビューで不要な情報を削除し、ファイルサイズを削減することでパフォーマンスを向上させることができます。また、実際のインフラと状態ファイルの内容が一致しているか確認し、差異があれば修正することが重要です。
 

7.機密情報の保護

Terraformでインフラストラクチャを管理する際、APIキー、パスワード、証明書などの機密情報を扱うことは避けられません。これらの機密情報を適切に保護することは、セキュリティを維持するために非常に重要です。
 

①機密情報を直接コードに含めない

Terraformコードへの機密情報の直接記述は、漏洩リスクを高めます。変数を活用し、機密情報は.tfvarsファイルに分離しましょう。.tfvarsファイルはバージョン管理から除外し安全に管理することで、コードの可読性とセキュリティを両立できます。
 

②環境変数の利用

機密情報をコードやファイルに直接記述しないように、環境変数を利用して実行時にその情報を渡すことで、保存の必要がなくなります。環境変数を利用して実行時に機密情報を渡すことで、保存の必要性を排除できます。継続的インテグレーション/継続的デリバリー(以下、CI/CD)パイプラインで環境変数を設定すれば、機密情報を安全に管理し、自動化されたデプロイメントプロセスに統合できます。
 

③アクセス制御

Terraformのセキュリティを強化するには、最小権限の原則を徹底すべきです。Terraformを実行するユーザーやサービスアカウントには、必要な最小限の権限のみを付与します。クラウドプロバイダーのIAM(Identity and Access Management)を活用し、Terraformがアクセスできるリソースを厳密に制限することで、セキュリティリスクを低減できます。
 

④秘密管理ツールの利用

Terraformの機密情報管理には、秘密管理ツールが有効です。これらのツールを使うことで機密情報を一元的に管理し、アクセス制御や監査ログ機能でセキュリティを強化できます。
 

⑤定期的な監査

Terraformのセキュリティ監査では、アクセスログの定期的な確認が不可欠です。実行ログや状態ファイルへのアクセス記録を分析し、不正な操作を早期に発見しましょう。また、設定レビューも定期的に実施し、セキュリティ上の不備がないか継続的に確認します。これらの対策によりTerraform環境のセキュリティを維持し、潜在的なリスクを最小限に抑えることができます。
 

8.バージョン管理

Terraformのコードをバージョン管理システムで管理することは、チームでの共同作業、変更履歴の追跡、障害発生時の復旧などを実現するために不可欠です。

①ファイル管理

Terraform固有のファイル(.terraform、terraform.tfstateなど)や、機密情報を含むファイルは、.gitignoreに追加してバージョン管理から除外しましょう。これにより、リポジトリの肥大化を防ぎ機密情報の漏洩リスクを低減できます。

②モジュール

再利用可能なTerraformモジュールは、独立したリポジトリで管理し、バージョン番号を付けて公開しましょう。これにより、モジュールの更新管理が容易になり、異なるプロジェクト間での再利用性と一貫性を高めることができます。

9.コードの検証とフォーマット

Terraformのコードは、インフラストラクチャの設計図となる重要なものです。コードの検証とフォーマットを徹底することでコードの品質を向上させ、エラーを早期に発見し、保守性を高めることができます。
 

①構文チェック

terraform validateは、Terraformコードの基本的な構文チェックを行うコマンドです。コードにエラーがある場合はエラーメッセージを表示します。CI/CDパイプラインに組み込むことで、コミットごとの構文チェックを自動化し、早期にエラーを発見できます。
 

②フォーマット

terraform fmtは、Terraformコードを標準フォーマットに自動整形し、可読性を向上させます。チーム全体で一貫したフォーマットを適用することで、共同作業が円滑に進み、コードレビューの効率も高まります。
 

③静的解析

TFLintはTerraformコードの静的解析ツールで、潜在的なエラーやセキュリティ問題を検出します。命名規則、ベストプラクティス、セキュリティルールなど多彩なルールを持ち、カスタムルール定義も可能です。CI/CDパイプラインに組み込むことで、コード品質を向上させます。
 

④Policy as Code

Open Policy Agent やSentinelはインフラストラクチャのポリシーをコード化し、Terraformコードがポリシーに準拠しているかを検証するツールです。これにより、特定リージョンへのリソース作成禁止やインスタンスへのタグ付け必須などのポリシーを強制できます。
 

⑤テスト

TerratestやKitchen-Terraformは、Terraformコードのテストツールです。実際にインフラを作成しテストを実行することで、コードが期待通りに動作するか検証します。これにより、デプロイ前に潜在的な問題を特定しインフラの信頼性を高められます。
 

10.CI/CDの導入

TerraformをCI/CDパイプラインに組み込むことでインフラストラクチャの変更を自動化し、迅速かつ安全にデプロイすることができます。
 

①インフラストラクチャ管理の自動化

CI/CDパイプラインを構築することで、Terraformコードの変更を自動的にテスト、検証、およびデプロイできます。これにより、手動による作業が減少し、人的エラーのリスクを軽減できます。インフラストラクチャの変更を迅速かつ一貫性のある方法で適用できるため、デプロイ時間の短縮と効率化が実現します。
 

②変更管理とバージョン管理の強化

Terraformコードをバージョン管理システムと連携させることで、変更履歴の追跡、コードレビュー、およびロールバックが容易になります。CI/CDパイプラインによる自動テストと検証により、コードの品質を維持し、予期しない問題の発生を防止できます。
 

③環境の一貫性と信頼性の向上

CI/CDパイプラインを通じて、開発環境、テスト環境、および本番環境で一貫性のあるインフラストラクチャを構築できます。自動テストと検証により、環境間の差異を最小限に抑え、本番環境での問題を早期に発見できます。
 

④セキュリティの向上

CI/CDパイプラインにセキュリティチェックを組み込むことで、インフラストラクチャの脆弱性を早期に特定し、修正できます。アクセス制御と権限管理をコードで定義し、自動的に適用することで、セキュリティポリシーの一貫性を確保できます。
 

⑤チームのコラボレーションの促進

Terraformコードを共有しレビューすることで、チームメンバー間のコラボレーションを促進できます。CI/CDパイプラインを通じて、インフラストラクチャの変更を透明性のある方法で管理し、チーム全体の理解を深めることができます。
 

最後に

Terraformは、インフラストラクチャをコードとして管理するための強力なツールです。 しかし、その力を最大限に引き出すためには、適切なプラクティスに従うことが重要です。ご紹介したこれらのプラクティスに従うことで、より効率的で、スケーラブルで、メンテナンスしやすいインフラを構築することができます。

The post Geminiに聞くTerraformのベストプラクティス10箇条(後編) first appeared on MISO.]]>
Geminiに聞くTerraformのベストプラクティス10箇条(前編) https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/gemini-terraform-bestpractice10-1 Wed, 12 Mar 2025 01:08:17 +0000 https://alb-owned-https-576747877.ap-northeast-1.elb.amazonaws.com/?p=18283 はじめに 生成AIへの注目が高まり、社内でも生成AIが業務のサポートに使用されています。技術的な不明点があれば生成AIに聞くと、回答が生成されます。この記事ではGoogleの生成AIであるGeminiに、Terrafor…

The post Geminiに聞くTerraformのベストプラクティス10箇条(前編) first appeared on MISO.]]>
はじめに

生成AIへの注目が高まり、社内でも生成AIが業務のサポートに使用されています。技術的な不明点があれば生成AIに聞くと、回答が生成されます。この記事ではGoogleの生成AIであるGeminiに、Terraformのベストプラクティス10箇条を聞いてみます。そして、Geminiから出力された内容の詳細を前編、後編で5箇条ずつに分けて解説します。 

Terraformとは、Infrastructure as Code(IaC)ツールです。インフラストラクチャの構成と管理をコードとして記述し、自動化することができます。

ベストプラクティス10箇条(前編)

1.モジュール化

まず、1つ目はモジュール化です。Terraformモジュールは、Terraform設定ファイルの集まりです。これらのファイルは特定のインフラストラクチャコンポーネントを定義し、入力変数を使用しカスタマイズできるようにします。
 

①モジュール化の利点

モジュール化は、インフラの再利用性、保守性、可読性、一貫性を向上させます。モジュールは複数の場所で再利用でき、一か所での更新で全体に反映されます。複雑なインフラを小さな要素に分割することで可読性が向上し、一貫した構成を維持できます。また、実装の詳細を隠蔽しインターフェースを通じてのみアクセス可能にすることで、複雑さを軽減します。
 

②モジュールの作成

モジュールは、Terraform設定ファイルを含むディレクトリとして作成されます。モジュールを使用するには、moduleブロックを使用してモジュールを呼び出します。
 
moduleブロックでは、モジュールのソースと入力変数を指定します。
 
  • variables.tf: モジュールの入力変数を定義

variable "project_id" {
  type = string
  description = "The ID of the Google Cloud project."
}

variable "region" {
  type = string
  description = "The region to deploy resources to."
  default = "us-central1"
}

variable "zone" {
  type = string
  description = "The zone to deploy resources to."
  default = "us-central1-f"
}

variable "machine_type" {
  type = string
  description = "The machine type for the Compute Engine instance."
  default = "e2-medium"
}

variable "source_image" {
  type = string
  description = "The source image for the Compute Engine instance."
  default = "debian-cloud/debian-9"
}

variable "network_name" {
  type    = string
  description = "Name of the VPC network"
  default = "default"
}

variable "subnet_name" {
  type = string
  description = "Name of the subnet"
  default = "default"
}

  • outputs.tf: モジュールから出力される値を定義
output "instance_name" {
  value       = google_compute_instance.default.name
  description = "Name of the created instance"
}

output "instance_zone" {
  value       = google_compute_instance.default.zone
  description = "Zone of the created instance"
}

output "instance_ip" {
  value       = google_compute_instance.default.network_interface.0.access_config.0.nat_ip
  description = "Public IP address of the created instance"
}

output "instance_self_link" {
  value       = google_compute_instance.default.self_link
  description = "Self-link of the created instance"
}
  • main.tf: モジュールのリソースを定義
# Google Cloud プロバイダの構成
terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0"
    }
  }
}

# 変数の定義 (variables.tfで定義)
# variable "project_id" {}
# variable "region" {}
# variable "zone" {}
# variable "machine_type" {}
# variable "source_image" {}
# variable "network_name" {}
# variable "subnet_name" {}

# Compute Engine インスタンスの作成
resource "google_compute_instance" "default" {
  project      = var.project_id
  name         = "terraform-instance"
  machine_type = var.machine_type
  zone         = var.zone

  boot_disk {
    initialize_params {
      image = var.source_image
    }
  }

  network_interface {
    subnetwork = "projects/${var.project_id}/regions/${var.region}/subnetworks/${var.subnet_name}"
  }

 tags = ["http-server"] 
}

# ファイアウォールルールの作成
resource "google_compute_firewall" "allow_http" {
  project     = var.project_id
  name        = "allow-http"
  network     = var.network_name
  source_ranges = ["0.0.0.0/0"]
  allowed {
    IP_protocol = "tcp"
    ports       = ["80"]
  }
  target_tags = ["http-server"]
}

 

2.適切な命名規則

次に2つ目は、適切な命名規則です。Terraformの命名規則は、コードの可読性、保守性、一貫性を向上させるために非常に重要です。
 

①基本原則

命名規則は、スネークケース(例:resource_type_name)を用い、全て小文字で単語をアンダースコア(_)で区切ります。リソースの目的が明確に伝わる簡潔でわかりやすい名前にし、プロジェクト全体で同じ命名規則を適用することで一貫性を保ちます。
 

②詳細な推奨事項

効果的なリソース命名規則は、リソースのタイプ、環境、役割といった要素を明確に示すことが重要です。例えば、「dev_web_server_instance_01」のように、開発環境(dev)にあるWebサーバーインスタンスの1番目であることを示す名前は、一目でリソースの特性を理解できます。リソースタイプを名前に含めることで、それがデータベースなのか、サーバーなのか、すぐに判別できます。

環境を含めることで、開発環境、ステージング環境、本番環境など、リソースがどこに存在するのかが明確になります。また、役割を含めることでそのリソースがWebサーバーなのか、データベースサーバーなのか、具体的な機能を理解しやすくなります。

さらに、同じ種類のリソースが複数ある場合は、番号を付けることで個々のリソースを区別できます。また、略語を避け、完全な単語を使用することで、名前の意図がより明確になります。

このように、リソース名に情報を詰め込むことで、運用管理の効率化、エラーの削減、チーム内でのコミュニケーションの円滑化などが期待できます。

 

3.変数の活用

次に、3つ目は変数の活用です。Terraformの変数はインフラストラクチャをコードで定義する際に、柔軟性と再利用性を高めるための強力な機能です。効果的に変数を使うためのベストプラクティスは以下のとおりです。
 

①変数の目的を明確にする

変数を活用することは、コードの品質と保守性を向上させる上で非常に有効な手段です。まず、同じ値を複数箇所で使用する場合にその値を変数として定義することで、コードの重複を避けることができます。値を変更する必要が生じた場合でも、変数の定義箇所を一箇所修正するだけで、全ての使用箇所に反映させることができます。これにより、修正漏れのリスクを減らし、効率的なコード管理が可能になります。

また、開発環境、ステージング環境、本番環境といった異なる環境ごとに異なる値を設定する場合にも、変数が役立ちます。環境ごとに異なる値を格納した変数を用意しておけば、環境が変わるたびにコードを書き換える必要はありません。さらに、APIキーやパスワードなどの機密情報を変数として定義し、別途管理することで、セキュリティを強化することができます。機密情報をコードに直接記述するリスクを軽減し、より安全なシステム運用に繋がります。このように、変数を適切に活用することで、コードの再利用性、柔軟性、セキュリティを向上させることができます。

 

②変数の型とデフォルト値

Terraformの変数を効果的に使用するには、いくつかのポイントがあります。まず、変数の値に合った型を指定することが重要です。string、number、bool、list、mapなど、適切な型を指定することで、コードの可読性と信頼性を高めます。また、可能な限りデフォルト値を設定することで、変数を省略できる場合を明確にし、モジュールの使い勝手を向上させます。

次に、変数のスコープも重要な要素です。ローカル値、モジュールレベルなど、変数のスコープを適切に選択することで、意図しない値の変更を防ぎ、コードの安全性を確保します。

また、モジュールを再利用しやすくするためには、入力変数を効果的に活用します。入力変数を使用することで、モジュールを呼び出す際に必要な値を外部から渡すことができ、モジュールの柔軟性を高めることができます。これらのポイントを意識することで、Terraformの変数をより効果的に活用し、効率的で保守性の高いコードを作成することができます。

 

③変数のドキュメント化

Terraformの変数を効果的に管理し利用を促進するためには、適切なドキュメントが不可欠です。まず、variableブロック内にdescriptionを記述することで、変数の用途を明確にすることができます。これにより、コードを読む人が変数の役割を理解しやすくなり適切な値を設定することができます。

さらに、プロジェクトのREADMEファイルに変数の使い方を記述することも重要です。READMEに具体的な使用例や設定時の注意点などを記載することで、コードを読む人だけでなく、実際にモジュールを利用する人にとっても有益な情報を提供することができます。これらのドキュメントを整備することで、Terraformコードの可読性、保守性、再利用性を高めることができます。

 

④変数の管理

Terraformの変数を安全かつ効率的に管理するためには、いくつかのベストプラクティスがあります。まず、変数の定義をバージョン管理システム(Gitなど)で管理することで、変更履歴を追跡し、問題発生時の切り戻しを容易にすることができます。

また、変数の値をコードから分離するために、.tfvarsファイルに格納します。これにより、設定値とコードを分けて管理することができ、可読性や保守性が向上します。さらに、APIキーやパスワードなどの機密情報は、コードに含めるべきではありません。これらの値は環境変数として設定し、Terraformのコードから参照することで、セキュリティを確保します。

 

4.出力値の定義

次に、4つ目は出力値の定義です。Terraformの出力値は、Terraformで作成したリソースに関する情報を外部に公開するための仕組みです。出力値を効果的に定義するためのベストプラクティスは以下のとおりです。
 

①出力値の目的を明確にする

Terraformの出力値は、モジュールの連携、デプロイ結果の確認、外部システムとの連携など、様々な場面で重要な役割を果たします。例えば、複数のモジュールを組み合わせてインフラを構築する場合、あるモジュールで作成したリソースの情報を別のモジュールで利用することがあります。この時、出力値として情報を公開することで、モジュール間の連携をスムーズに行うことができます。

また、Terraform apply実行後に出力値を表示することで、作成したリソースのID、IPアドレス、URLなどの重要な情報を容易に確認することができます。これにより、デプロイ結果の確認作業を効率化することができます。

さらに、Terraformで作成したリソースの情報を外部システムに渡す必要がある場合にも、出力値が役立ちます。例えば、CI/CDツールや監視ツールなど、外部のシステムと連携する際に、出力値を活用することで、スムーズな情報伝達を実現できます。

このように、Terraformの出力値は、モジュール間の連携、デプロイ結果の確認、外部システムとの連携など様々な場面で重要な役割を果たし、Terraformの利用を促進する上で欠かせない機能です。

 

②出力値の命名規則

Terraformの出力値にも、適切な命名規則を適用することで、コードの可読性と保守性を向上させることができます。出力値の名前には「2.適切な命名規則」でも記述した通り、スネークケースを採用し、全て小文字で単語をアンダースコア(_)で区切ります。例えば、instance_ipやvpc_idのように、出力値の内容が明確に伝わる名前にすることで、コードを読む人がその値の役割を容易に理解することができます。

プロジェクト全体で同じ命名規則を適用することで、一貫性を保ち、混乱を避けることが重要です。このように、出力値の命名規則を定めることで、Terraformコードの可読性、保守性、そしてチーム内での情報共有を促進することができます。

 

③出力値の型

Terraformの出力値を定義する際には、出力値の型を適切に指定することが重要です。string、number、bool、list、mapなど、値に合った型を指定することで、出力値を扱う際のエラーを防ぎ、コードの信頼性を高めることができます。

また、必要に応じてリストやマップなどの複雑なデータ構造を出力値として定義することも可能です。これにより、複数の値をまとめて出力したり、より構造化された情報を提供したりすることができます。

 

④出力値のドキュメント化

Terraformの出力値を効果的に活用するためには、適切なドキュメントが重要です。outputブロックにdescriptionを記述することで、出力値の内容を明確にすることができます。これにより、コードを読む人が出力値の役割を理解しやすくなり、その値を適切に利用することができます。

また、プロジェクトのREADMEファイルに出力値の使い方を記述することも重要です。READMEに具体的な使用例や注意点などを記載することで、コードを読む人だけでなく、実際にモジュールを利用する人にとっても有益な情報を提供することができます。これらのドキュメントを整備することで、Terraformコードの可読性、保守性、再利用性を高めることができます。

 

⑤出力値の属性

Terraformの出力値を扱う上で、セキュリティと依存関係の管理は重要な考慮事項です。パスワードなどの機密情報を出力値として定義する場合は、sensitive = trueを指定することで、値がコンソールに表示されないようにします。

これにより、意図しない情報漏洩のリスクを軽減することができます。また、出力値が依存するリソースがある場合は、depends_onを指定することで、リソースが作成される前に出力値が参照されるのを防ぎます。予期せぬエラーを回避し、安定したインフラ構築を実現することができます。これらの設定を適切に行うことで、Terraformの出力値を安全かつ確実に管理することができます。

 

⑥出力値の利用

Terraformで他のモジュールの出力値を参照するには、module.<モジュール名>.<出力値名>という形式を使用します。
 

5.依存関係の明示

前編の最後の5つ目は、依存関係の明示です。Terraformは、リソース間の依存関係を自動的に検出して適切な順序で作成・更新しますが、複雑なインフラストラクチャでは、Terraformが自動的に検出できない依存関係が発生することがあります。このような場合に、depends_onメタ引数を使用して依存関係を明示することで、リソースが意図した順序で作成・更新されるように制御し、エラーや予期せぬ動作を防ぐことができます。

 

①depends_on のベストプラクティス

Terraformのdepends_onは、リソース間の依存関係を明示的に指定するための機能ですが、その使用には注意が必要です。Terraformは多くの依存関係を自動的に処理できるため、depends_onは本当に必要な場合にのみ使用します。過剰な使用はコードの可読性を低下させ、Terraformの依存関係グラフの解析を複雑にする可能性があります。可能な限りリソース属性の参照など、暗黙的な依存関係を使用します。暗黙的な依存関係は、Terraformが依存関係を理解し、より効率的に処理するのに役立ちます。

depends_onを使用するときに注意すべき点として、循環依存関係があります。循環依存関係は、Terraformがリソースを作成・更新できなくなる原因となるため、絶対に避ける必要があります。

モジュール間の依存関係を管理するためにdepends_onを使用することもできます。あるモジュールが別のモジュールで作成されたリソースに依存している場合、depends_onを使用して依存関係を明示します。また、リソースのライフサイクル(create_before_destroyやprevent_destroyなど)設定と組み合わせて使用することで、リソースの削除・置換時の依存関係を制御できます。depends_onを使用する場合は、なぜ明示的な依存関係が必要なのかをコメントで説明することでコードの可読性を向上させることが重要です。

 

②depends_onを使用する例

例:VPCとサブネット: サブネットはVPCに依存するため、サブネットリソースでdepends_onを使用してVPCリソースへの依存関係を明示します。

resource "google_compute_network" "main" {
  # ...
}

resource "google_compute_subnetwork" "main" {
  # ...
  depends_on = [google_compute_network.main]
}

最後に

Geminiの力を借りて、Terraformのベストプラクティスを5箇条までをまとめました。後編は残りの5箇条について書いていきます。
 

The post Geminiに聞くTerraformのベストプラクティス10箇条(前編) first appeared on MISO.]]>