Google Cloud の Terraform に関するよくある質問

このページでは、Terraform を使用して Google Cloudのリソースを管理するとき（特に API の操作や Terraform を初めて使用する場合）のよくある質問に対する回答を紹介します。

Terraform を使ってみる

このセクションでは、Terraform を初めて使用するユーザー向けに、基本的なコンセプトと最初の手順について説明します。

Infrastructure as Code（IaC）とは何ですか？また、Terraform を使用すべき理由を教えてください。

Infrastructure as Code（IaC）は、機械で読み取り可能な定義ファイルを使用してコンピューティング インフラストラクチャを管理およびプロビジョニングする手法です。IaC のコンセプトとメリットの概要については、Infrastructure as Code とはをご覧ください。

Terraform は、クラウドとオンプレミスのリソースの定義、プロビジョニング、管理に使用されるオープンソースの IaC ツールです。IaC ワークフローで Terraform を使用するメリットについては、Terraform を使用するメリットをご覧ください。

Terraform をインストールして最初の構成を実行するにはどうすればよいですか？

Terraform を使い始めるには、まずローカルマシンに Terraform CLI をダウンロードしてインストールする必要があります。手順については、HashiCorp Terraform のウェブサイトをご覧ください。インストール後、Terraform 構成ファイルを作成してリソース（Cloud Storage バケットなど）を定義できます。その後、terraform init を使用して作業ディレクトリを初期化したり、terraform plan を使用して変更をプレビューしたり、terraform apply を使用して変更を適用したりできます。

HashiCorp Configuration Language（HCL）とは何ですか？また、その構文はどこで学習できますか？

HashiCorp Configuration Language（HCL）は、Terraform で使用される構成言語です。インフラストラクチャの定義を明確かつ効率的に記述し理解するために、人間が読みやすく、機械も容易に扱えるように設計されています。HCL では、変数、式、関数、モジュールなどのさまざまな機能がサポートされています。HCL 構文は、公式の HashiCorp Terraform ドキュメントで学習できます。このドキュメントには、包括的なガイドと例が記載されています。

Google Cloud リソースの Terraform 構成の例はどこにありますか？

Google Cloudの Terraform 構成の例は多数あります。

  • HashiCorp Terraform Registry: Google Cloud プロバイダ向けの公式の Terraform Registry には、すべてのリソースとデータソースのドキュメントと例が含まれています。

  • Google Cloud Terraform のサンプル: Google は、一般的な Google Cloud リソースのデプロイ方法と管理方法を示すさまざまな Terraform のサンプルを提供しています。

  • GitHub リポジトリ: terraform-google-modules GitHub 組織を含む多くのオープンソース リポジトリで、再利用可能なモジュールと例が提供されています。

複雑な Terraform 構成を管理およびテストするにはどうすればよいですか？特に多くのリソースを扱う場合について教えてください。

複雑な構成の場合は、スケーラビリティと保守性を高めるように設計された Terraform の以下の機能を使用することを検討してください。

  • モジュール: 共通のインフラストラクチャ パターンをカプセル化して再利用します。

  • ワークスペース: 単一の構成の複数の異なるインスタンスを管理します。

  • terraform plan と terraform validate: これらのコマンドは、構文を検証したり、実際のデプロイなしに変更をプレビューしたりするために頻繁に使用されます。

  • リソースのターゲティング（使用する際は注意が必要）: 特定の部分をテストする場合は、terraform apply または terraform destroy で -target を一時的に使用できます。ただし、これを使用すると状態管理が複雑になるため、日常的な運用での使用は一般に推奨されません。

  • 専用環境: 本番環境の前にテスト用の開発環境またはステージング環境にデプロイします。

Google Cloud API に関する質問

以下の質問では、Terraform とGoogle Cloud API（公開 API と非公開 API を含む）のやり取りに関するよくある質問について説明します。

Terraform を使用して、dataproc-control.googleapis.com などの内部または非公開 Google Cloud API を管理またはインポートできますか？

いいえ。内部または非公開 Google Cloud API は、Google が管理する Service Infrastructure の一部であり、お客様が Terraform を使用して直接管理、有効化、またはインポートできるようにするために公開されているものではありません。これらの API は Google Cloudによって自動的に処理されます。Terraform で直接管理しようとすると、エラーが発生します。

詳細な説明については、 Google Cloud API と Terraform に関するガイドをご覧ください。

Terraform で API を有効化することとリソースをインポートすることの違いは何ですか？

  • API の有効化: プロジェクトで特定の Google Cloud サービスをアクティブ化し、そのサービスを使用するために必要な権限をプロジェクトに付与することを意味します。 Google Cloudで Terraform を使用する場合、通常は google_project_service リソースを使用して行います。これは、その API に依存するリソースを作成するための前提条件です。

  • リソースのインポート: Terraform の外部で作成された既存の Google Cloud リソース（Compute Engine インスタンス、Cloud Storage バケットなど）を Terraform の管理下に置くことを指します。API 自体ではなく、リソースをインポートします。

詳細については、 Google Cloud API と Terraform に関するガイドをご覧ください。

dataproc-control.googleapis.com を明示的に管理またはインポートしないとどうなりますか？これは Dataproc の使用に影響しますか？

いいえ、Dataproc の使用には影響しません。dataproc-control.googleapis.com は、Dataproc が独自の運用上の制御に使用する内部 API です。この機能はGoogle Cloudによって自動的に管理されるため、Terraform を使用して明示的に有効化、インポート、管理する必要はありません。Dataproc クラスタとジョブは、この内部 API に関して手動で操作を行わなくても正常に機能します。

Terraform で 403 Permission Denied（権限の拒否）エラーのトラブルシューティングを行うにはどうすればよいですか？

403 Permission Denied エラーは通常、Terraform で使用されるサービス アカウントまたはユーザー認証情報に、特定の Google Cloud リソースに対してリクエストされたアクションを実行するために必要な IAM 権限がないことを示します。以下の手順でトラブルシューティングを行います。

  1. 影響を受けるリソースと API メソッドを特定する: 通常、エラー メッセージには、リソースタイプと失敗した API 呼び出しが示されています。

  2. IAM ロールを確認する: プリンシパル（サービス アカウントまたはユーザー）に、正しい IAM ロールが適切なレベル（プロジェクト、フォルダ、組織、リソース）で割り当てられていることを確認します。 Google Cloud コンソールの IAM トラブルシューティングを使用します。

  3. サービスの有効化を確認する: （gcloud services enable や google_project_service を使用するなど）プロジェクトで必要な Google Cloud API サービスが有効になっていることを確認します。

  4. 組織のポリシーを確認する: 組織のポリシーによってアクションが制限されていないか確認します。

割り当てエラーは、プロジェクトが現在の割り当て上限を超えてリソースを消費しようとしたり、API リクエストを行おうとしたりした場合に発生します。この問題を解決するには:

  1. 具体的な割り当てを特定する: 通常、エラー メッセージには、API と超過した割り当て上限が示されています。

  2. 現在の割り当てを確認する: Google Cloud コンソールの割り当てページにアクセスして、現在の使用量と上限を確認します。

  3. 割り当ての増加をリクエストする: 容量が不足している場合は、割り当てページから割り当ての増加を直接リクエストできます。

  4. user_project_override を検討する: 一部のリソースでは、認証情報プロジェクトがリソース プロジェクトと異なる場合、API リクエストの料金が認証情報プロジェクトの割り当てに対して請求されることがあります。user_project_override（プロバイダ リファレンスを参照）を使用して、割り当ての料金がリソースのプロジェクトに請求されるように強制することで、この問題を解決できる場合があります。

ユーザー管理のデフォルト サービス アカウントとは何ですか？また、Terraform でその権限を管理するにはどうすればよいですか？

特定の Google Cloud サービスでは、プロジェクトが作成されたとき、またはサービスが有効化されたときに、ユーザー管理のサービス アカウント（一般にデフォルト サービス アカウントと呼ばれます）が自動的に作成されます。通常、これらのロールには広範な権限が付与されます。これらのアカウントはユーザーによって管理されますが、Google によって作成されます。google_project_iam_member などの IAM リソースを使用してアカウントのロールを変更することで、アカウントの権限を管理できます。デフォルト サービス アカウント自体に対してアクション（デフォルトの高権限ロールの削除やアカウントの完全な削除など）を実行したい場合は、google_project_default_service_accounts リソースを使用できます。Google は、デフォルト サービス アカウント タイプに関するガイダンスも提供しています。

Google 管理のサービス アカウントとは何ですか？また、Terraform 構成でそのアカウントを参照するにはどうすればよいですか？

Google 管理のサービス アカウントは、特定のサービス用に Google によって作成され、完全に管理されます。これらのアカウントは、ユーザー プロジェクトの外部に存在し、ユーザーがユーザー管理のサービス アカウントと同じ方法で直接構成することはできません。ただし、リソースとやり取りするために、これらのアカウントに IAM 権限を付与することが必要になる場合があります。Terraform で google_project_service_identity データソースまたはリソースを使用して特定のサービス用の Google 管理のサービス アカウントのメールアドレスを参照し、そのアドレスに IAM ポリシーを適用できます。この手法は、Cloud Build や Cloud Composer などのサービスでよく使用されます。

disable_on_destroy が構成されているリソースを terraform destroy するとどうなりますか？

google_project_service と他の一部のリソース（google_storage_bucket など）の disable_on_destroy 引数は、Terraform リソースが破棄されたときに基盤となるクラウド リソースが無効化されるか、削除されるかを制御します。

  • disable_on_destroy が true の場合、または未設定（通常はこれがデフォルト）の場合、terraform destroy は対応するクラウド リソースを無効化（API の場合）または削除（バケットの場合）しようとします。

  • disable_on_destroy が false の場合、terraform destroy は Terraform の状態からリソースを削除しますが、実際のクラウド リソース（有効な API やバケットなど）は Google Cloud プロジェクトにそのまま残します。これは、誤って無効にしたり削除したりしてはならない重要なサービスでよく使用されます。