このラボは Google のパートナーである HashiCorp と共同開発されました。アカウント プロフィールでサービスの最新情報、お知らせ、特典の受け取りをご希望になった場合、お客様の個人情報が本ラボのスポンサーである Hashicorp と共有される場合があります。

GSP750

概要

Terraform は HashiCorp が開発した Infrastructure as Code ツールです。インフラストラクチャの構築、変更、管理を安全かつ再現可能な方法で行うことを目的としています。Terraform を使用すると、オペレーターとインフラストラクチャ チームは、HashiCorp Configuration Language（HCL）という構成言語を使用して環境を管理し、人が読める形式でデプロイを自動化できるようになります。

Infrastructure as Code とは、ユーザー インターフェースを使用して手動でリソースを構成する代わりに、ファイル形式でインフラストラクチャを管理するプロセスです。ここで言うリソースとは、仮想マシン、セキュリティ グループ、ネットワーク インターフェースなど、特定の環境のインフラストラクチャを形成する要素を指します。Terraform では、HCL を使用することにより、ほぼすべてのプロバイダ（AWS、Google Cloud、GitHub、Docker など）に対応する、希望のリソースを定義したファイルを作成でき、適用時にそのリソースの作成を自動化できます。

デプロイのワークフローはシンプルで、次の手順に沿って進めます。

• スコープ - 対象となるプロジェクトでどのリソースを作成する必要があるのかを確認します。
• 作成 - スコープに対応するパラメータに基づいて HCL で構成ファイルを作成します。
• 初期化 - 構成ファイルと同じプロジェクト ディレクトリで terraform init を実行します。これにより、プロジェクトに適切なプロバイダ プラグインがダウンロードされます。
• プランと適用 - terraform plan を実行して作成プロセスを確認します。次に、terraform apply を実行して実際のリソースを作成し、構成ファイルに記述されている将来の変更内容と、デプロイ環境の現在の状態を比較する状態ファイルも作成します。

目標

このラボでは、次のタスクの実行方法について学びます。

• Terraform を使用してインフラストラクチャを構築、変更、破棄する
• Terraform を使用してリソースの依存関係を作成する
• Terraform を使用してインフラストラクチャをプロビジョニングする

設定と要件

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボには時間制限があり、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく実際のクラウド環境を使って、ラボのアクティビティを行います。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モード（推奨）またはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウント間の競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: このラボでは、受講者アカウントのみを使用してください。別の Google Cloud アカウントを使用すると、そのアカウントに料金が発生する可能性があります。

ラボを開始して Google Cloud コンソールにログインする方法

1. [ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるダイアログでお支払い方法を選択してください。 右側の [ラボの設定とアクセス] パネルには、以下が表示されます。

   • [Google Cloud コンソールを開く] ボタン
   • このラボで使用する一時的な認証情報（ユーザー名とパスワード）
   • このラボを行うために必要なその他の情報（ある場合）

   ラボのタイマーはページの上部に表示され、残り時間が示されます。

2. [Google Cloud コンソールを開く] をクリックします（Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く] を選択します）。

   ラボでリソースがスピンアップし、別のタブで [ログイン] ページが表示されます。

   ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。

   注: [アカウントの選択] ダイアログが表示された場合は、[別のアカウントを使用] をクリックします。

3. 必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。

   {{{user_0.username | "Username"}}}

   [ラボの設定とアクセス] パネルでもユーザー名を確認できます。

4. [次へ] をクリックします。

5. 以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。

   {{{user_0.password | "Password"}}}

   [ラボの設定とアクセス] パネルでもパスワードを確認できます。

6. [次へ] をクリックします。

   重要: ラボで指定された認証情報を使用する必要があります。ご自身の Google Cloud アカウントの認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。

7. その後のページはクリックして先に進みます。

   • 利用規約に同意します。
   • 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
   • 無料トライアルには登録しないでください。

しばらくすると、このタブで Google Cloud コンソールが開きます。

注: Google Cloud のプロダクトやサービスにアクセスするには、ナビゲーション メニューをクリックするか、[検索] フィールドにサービス名またはプロダクト名を入力します。

Cloud Shell をアクティブにする

Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。

1. Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン をクリックします。

2. ウィンドウで次の操作を行います。

   • Cloud Shell 情報ウィンドウで操作を進めます。
   • Cloud Shell が認証情報を使用して Google Cloud API を呼び出すことを承認します。

接続した時点で認証が完了しており、プロジェクトに各自の Project_ID、 が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。

3. （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。

gcloud auth list

4. [承認] をクリックします。

出力:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。

gcloud config list project

出力:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Terraform をインストールする

Terraform は Cloud Shell にプリインストールされていません。Terraform CLI をインストールし、Cloud Shell セッションをまたいで永続化するように構成する必要があります。

1. HashiCorp リポジトリを構成して Terraform をインストールし、このインストールが今後のセッションでも永続化されるようにするために、Cloud Shell ターミナルで次のコマンドを実行します。

cat <<'EOF' > ~/.customize_environment # HashiCorp リポジトリを設定して Terraform をインストールする wget -O - https://apt.releases.hashicorp.com/gpg | sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(grep -oP '(?<=UBUNTU_CODENAME=).*' /etc/os-release || lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/hashicorp.list sudo apt update && sudo apt install -y terraform EOF bash ~/.customize_environment

2. Terraform が正しくインストールされていることを確認するために、次のコマンドを実行します。

terraform --version

出力には、インストールされているバージョン（v1.5.7 以降）が表示されます。

Terraform v1.9.0

タスク 1. インフラストラクチャを構築する

まず、main.tf というファイルにサンプルの構成を作成します。Terraform では、名前が .tf または .tf.json で終わるファイルが構成ファイルとして認識され、実行時に読み込まれます。

1. 次のコマンドで main.tf ファイルを作成します。

touch main.tf

2. Cloud Shell のツールバーで [エディタを開く] ボタンをクリックします（必要に応じて [エディタを開く] アイコンおよび [ターミナルを開く] アイコンを使用して Cloud Shell とコードエディタを切り替えることができます。または、[新しいウィンドウで開く] ボタンをクリックして別のタブでエディタを開いたままにすることもできます）。

3. エディタで、main.tf ファイルに次の内容を追加します。

terraform { required_providers { google = { source = "hashicorp/google" version = "3.5.0" } } } provider "google" { project = "{{{project_0.project_id | PROJECT ID}}}" region = "{{{project_0.default_region | REGION}}}" zone = "{{{project_0.default_zone | ZONE}}}" } resource "google_compute_network" "vpc_network" { name = "terraform-network" }

Terraform ブロック

terraform {} ブロックは、Terraform Registry からダウンロードするプロバイダを Terraform に知らせるために必要です。上記の構成では、google プロバイダのソースが registry.terraform.io/hashicorp/google の短縮形である hashicorp/google として定義されています。

required_providers ブロックで定義されたプロバイダそれぞれにバージョンを割り当てることもできます。version 引数は省略可能ですが、指定することをおすすめします。この引数を使用してプロバイダを特定のバージョン（またはバージョン範囲）に制限すると、破壊的変更が含まれている可能性のある新しいプロバイダがダウンロードされるのを防ぐことができます。バージョンを指定しないと、初期化時に最新のプロバイダが自動的にダウンロードされます。

詳細については、HashiCorp Terraform ウェブサイトで「Provider Requirements（プロバイダの要件）」をご覧ください。

プロバイダ

provider ブロックは、指定したプロバイダ（この場合は google）の構成に使用します。プロバイダは、リソースの作成と管理を担います。Terraform 構成で複数のプロバイダのリソースを管理する場合は、複数の provider ブロックを指定できます。

初期化

新しい構成（またはバージョン管理からチェックアウトした後の既存の構成）に対して最初に実行するコマンドは、terraform init です。このコマンドを実行すると、それ以降のコマンドで使用されるさまざまなローカル設定やローカルデータが初期化されます。

• Cloud Shell ターミナルで（必要であれば [ターミナルを開く] をクリックして開く）、新しい Terraform 構成を初期化します。

terraform init

リソースを作成する

1. 次に、terraform apply を実行して構成を適用します。

terraform apply

出力でリソース "google_compute_network" "vpc_network" の横に「+」が表示されます。これは、このリソースが Terraform によって新規に作成されることを表しています。その下に、設定される属性が表示されます。値が (known after apply) になっている場合、その属性の値はリソースが作成されるまでわかりません。

プランが正常に作成された場合、Terraform はここで一時停止して、続行する前に承認を求めます。プランに正しくない内容や危険な内容が含まれていると思われる場合は、インフラストラクチャを変更せず、ここで中止するのが安全です。

terraform apply がエラーで失敗した場合は、エラー メッセージを確認し、発生したエラーを修正してください。

2. この例ではプランに問題がないようなので、確認プロンプトで「yes」と入力して Enter キーを押して続行します。

プランの実行には数分かかります。ネットワークが正常に作成されるまで Terraform が待機するためです。

# ... Enter a value: yes google_compute_network.vpc_network: Creating... google_compute_network.vpc_network: Still creating... [10s elapsed] google_compute_network.vpc_network: Still creating... [20s elapsed] google_compute_network.vpc_network: Still creating... [30s elapsed] google_compute_network.vpc_network: Still creating... [40s elapsed] google_compute_network.vpc_network: Still creating... [50s elapsed] google_compute_network.vpc_network: Creation complete after 58s [id=terraform-network] Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

以上で Terraform の作業は終了です。Cloud コンソールに移動すると、プロビジョニングしたネットワークを確認できます。

3. Google Cloud コンソールのナビゲーション メニューで、[VPC ネットワーク] に移動します。terraform-network がプロビジョニングされていることを確認できます。

4. Cloud Shell で terraform show コマンドを実行して、現在の状態を確認します。

terraform show

これらの値を参照して他のリソースや出力を構成できます。これについては、このラボで後ほど説明します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 Terraform でリソースを作成する

タスク 2. インフラストラクチャを変更する

前のセクションでは、Terraform で基本的なインフラストラクチャとして VPC ネットワークを作成しました。このセクションでは構成を変更し、その変更が Terraform でどのように処理されるかを確認します。

インフラストラクチャは絶えず進化を続けるため、そのような変更の管理と適用を支援するために Terraform が開発されました。Terraform 構成を変更すると、望ましい状態に到達するために必要な変更のみを適用する実行プランが作成されます。

Terraform を使用してインフラストラクチャを変更することにより、構成だけでなく状態のバージョン管理も行うことができ、インフラストラクチャの経時的変化を確認できます。

リソースを追加する

新規のリソースを追加するには、Terraform 構成にリソースを追加し、terraform apply を実行してそのリソースをプロビジョニングします。

1. エディタで main.tf にコンピューティング インスタンス リソースを追加します。

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" boot_disk { initialize_params { image = "debian-cloud/{{{project_0.startup_script.debian_image_id_short | debian-12}}}" } } network_interface { network = google_compute_network.vpc_network.name access_config { } } }

このリソースには、より多くの引数が指定されています。name と machine_type は単純な文字列ですが、boot_disk と network_interface はより複雑なブロックになります。利用可能なオプションの一覧については、google_compute_instance ドキュメントをご覧ください。

この例のコンピューティング インスタンスは Debian オペレーティング システムを使用し、前の手順で作成した VPC ネットワークに接続します。この構成では、google_compute_network.vpc_network.name でネットワークの name プロパティを参照しています。ここで google_compute_network.vpc_network はネットワークを定義するブロック内の各種の値に対応する ID であり、name はそのリソースのプロパティです。

access_config ブロックを指定することにより、引数を何も指定しなくても、このインスタンスにインターネット経由でアクセスできるようになります。

2. 次に、terraform apply を実行してコンピューティング インスタンスを作成します。

terraform apply

3. ここでも、確認プロンプトで「yes」と入力します。

これはとてもわかりやすい変更といえるでしょう。"vm_instance" という名前の "google_compute_instance" リソースを構成に追加し、そのリソースが Terraform によって Google Cloud に作成されました。

リソースの変更

Terraform では、リソースを作成するだけでなく、作成したリソースに変更を加えることもできます。

1. main.tf ファイルの vm_instance リソースに tags 引数を追加します。

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" tags = ["web", "dev"] # Add this line # ... }

2. terraform apply をもう一度実行してインスタンスを更新します。

terraform apply

3. 接頭辞「~」は、リソースがインプレースで更新されることを意味します。「yes」と入力して変更を適用すると、インスタンスにタグが追加されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インフラストラクチャを変更する

破壊的変更

破壊的変更とは、プロバイダが既存のリソースを更新するのではなく置き換えることが必要になる変更です。一般に、これは構成で記述した方法でリソースを更新することがクラウド プロバイダでサポートされない場合に行います。

たとえば、インスタンスのディスク イメージの変更は破壊的変更です。

1. main.tf 構成ファイルで、vm_instance リソース内の boot_disk ブロックを編集して、次のように変更します。

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

2. 次に、terraform apply をもう一度実行して、既存のリソースにこの変更がどう適用されるかを確認します。

terraform apply

接頭辞「-/+」は、リソースをインプレースで更新するのではなく、リソースを一度破棄してから再作成することを意味します。一部の属性はインプレースで更新できますが（これは接頭辞「~」で示されます）、インスタンスのブートディスク イメージを変更するにはインスタンスを再作成する必要があります。Terraform と Google Cloud プロバイダでこうした変更が自動的に処理され、Terraform が処理する内容は実行プランで示されます。

また、実行プランでは、ディスク イメージの変更によってインスタンスの置き換えが必要になったことも示されます。リソースを破棄または作成する更新が許容されない状況にある場合は、この情報を参照して、そのような変更を回避するように調整することができます。

3. ここでも確認プロンプトが表示され、実行プランの続行の承認が求められます。「yes」を入力してプランされたステップを実行します。

実行プランで示されるように、Terraform はまず既存のインスタンスを破棄し、次に元のインスタンスに代わる新しいインスタンスを作成します。terraform show をもう一度実行して、このインスタンスに関連付けられている新しい値を確認します。

インフラストラクチャを破棄する

インフラストラクチャの構築方法と変更方法について学びました。複数リソースの作成とリソースの依存関係の確認に進む前に、Terraform で管理するインフラストラクチャを完全に破棄する方法について学びましょう。

インフラストラクチャの破棄を本番環境で行うことはあまりありません。ただし、Terraform を使用して開発環境、テスト環境、ステージング環境など複数の環境をスピンアップする場合は、破棄を行うことが有効な場合があります。

リソースを破棄するには、terraform destroy を使用します。このコマンドは terraform apply と似ていますが、構成からすべてのリソースが削除されたかのように動作します。

• terraform destroy を実行します。このプランを実行してインフラストラクチャを破棄することの確認が求められた場合は、「yes」と入力します。

terraform destroy

接頭辞「-」は、インスタンスとネットワークが破棄されることを示します。terraform apply と同様に実行プランが表示され、変更の実行を承認するまで待機中になります。

terraform apply の場合と同じく、破棄の順序は Terraform によって決定されます。Google Cloud ではリソースが残っている VPC ネットワークは削除できないため、Terraform はインスタンスが破棄されるまで待機してからネットワークを破棄します。Terraform はオペレーションの実行時に依存関係グラフを作成してオペレーションの正しい順序を決定します。複数のリソースに関わる複雑なケースでは、安全に行える場合に複数のオペレーションが同時に実行されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 破壊的な変更を加える

タスク 3. リソースの依存関係を作成する

このセクションでは、リソースの依存関係について学習し、リソース パラメータを使用してリソースの情報を他のリソースと共有する方法について学習します。

現実のインフラストラクチャは、多様なリソースとリソースタイプで構成されます。Terraform 構成には複数のリソースと複数のリソースタイプを含めることができ、これらのタイプが複数のプロバイダにまたがることも可能です。

このセクションでは、複数のリソースを構成する方法と、リソースの属性を使用して他のリソースを構成する方法について基本的な例を示します。

• 次のコマンドを実行して、ネットワークとインスタンスを再作成します。

terraform apply

プロンプトに「yes」と入力すると、リソースが作成されます。

静的 IP アドレスを割り当てる

1. 次のコードを main.tf 構成ファイルに追加して、VM インスタンスに静的 IP を割り当てます。

resource "google_compute_address" "vm_static_ip" { name = "terraform-static-ip" }

これは、これまでの例の VM インスタンス リソースを追加した手順に似ていますが、ここでは「google_compute_address」リソースタイプを作成する点が異なります。このリソースタイプはプロジェクトに予約済み IP アドレスを割り振ります。

2. 次に、terraform plan を実行します。

terraform plan

terraform plan で作成される内容が表示されます。

$ terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. google_compute_network.vpc_network: Refreshing state... [id=terraform-network] google_compute_instance.vm_instance: Refreshing state... [id=terraform-instance] ------------------------------------------------------------------------ An execution plan has been generated and is shown below. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions: # google_compute_address.vm_static_ip will be created + resource "google_compute_address" "vm_static_ip" { + address = (known after apply) + address_type = "EXTERNAL" + creation_timestamp = (known after apply) + id = (known after apply) + name = "terraform-static-ip" + network_tier = (known after apply) + project = (known after apply) + region = (known after apply) + self_link = (known after apply) + subnetwork = (known after apply) + users = (known after apply) } Plan: 1 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run.

terraform apply とは異なり、plan コマンドは変更する内容を示すだけです。実際に変更内容を直接適用するわけではありません。この時点までに加えた変更は静的 IP の追加だけです。次に、その IP アドレスをインスタンスに割り当てる必要があります。

3. インスタンスの network_interface 構成を次のように更新します。

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

access_config ブロックにはいくつかの省略可能な引数がありますが、ここでは nat_ip を静的 IP アドレスに設定します。Terraform は、この構成を読み取り、次の処理を行います。

• vm_instance を作成する前に vm_static_ip を作成する
• vm_static_ip のプロパティを状態に保存する
• nat_ip を vm_static_ip.address プロパティの値に設定する

4. terraform plan をもう一度実行します。ただし、今回はプランを保存します。

terraform plan -out static_ip

このようにプランを保存しておくと、将来的にまったく同じプランを適用できます。プランで作成されたファイルを適用しようとすると、そのプランの適用前にまず、完全に同じ変更を加えてもよいかどうか、Terraform によって確認されます。

この場合、新しい google_compute_address が作成され、それを使用する既存の VM が更新されることが見て取れます。

5. terraform apply "static_ip" を実行し、Terraform プランでこの変更がどのように適用されるかを確認します。

terraform apply "static_ip"

上記のように、VM インスタンスの変更前に静的 IP が作成されました。インスタンスのネットワーク インターフェース構成に IP アドレスを渡す補間式により、Terraform は依存関係を推測でき、インスタンスを更新する前に静的 IP を作成する必要があることを認識します。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 リソースの依存関係を作成する

暗黙的な依存関係と明示的な依存関係を確認する

Terraform は、補間式で使用されるリソースの属性を調べることで、リソース間の依存関係の有無を自動的に推測できます。上記の例では、google_compute_address.vm_static_ip.address への参照により、vm_static_ip という名前の google_compute_address に「暗黙の依存関係」が作成されます。

Terraform はこの依存関係情報を使用して、複数のリソースを作成および更新する正しい順序を判断します。上記の例では、Terraform は、vm_static_ip を先に作成してから、それを使用するように vm_instance を更新する必要があることを認識します。

補間式による暗黙の依存関係は、Terraform に依存関係を認識させる主要な手段であるため、可能な限り、これを使用します。

リソース間には、Terraform から「見えない」依存関係が存在する場合があります。明示的な依存関係を作成するには、リソースに depends_on 引数を追加し、依存先となるリソースのリストを指定します。

たとえば、インスタンスで実行するアプリケーションで特定の Cloud Storage バケットを使用するとします。この依存関係がアプリケーション コード内で構成されている場合、Terraform からは見えません。この場合は、depends_on を使用してこの依存関係を明示的に宣言する必要があります。

1. Cloud Storage バケットと、そのバケットに明示的に依存するインスタンスを追加するには、main.tf に次のコードを追加します。

# New resource for the storage bucket our application will use. resource "google_storage_bucket" "example_bucket" { name = "{{{project_0.project_id | PROJECT_ID}}}" location = "US" website { main_page_suffix = "index.html" not_found_page = "404.html" } } # Create a new instance that uses the bucket resource "google_compute_instance" "another_instance" { # Tells Terraform that this VM instance must be created only after the # storage bucket has been created. depends_on = [google_storage_bucket.example_bucket] name = "terraform-instance-2" machine_type = "e2-micro" boot_disk { initialize_params { image = "cos-cloud/cos-stable" } } network_interface { network = google_compute_network.vpc_network.self_link access_config { } } } 注: ストレージ バケットはグローバルに一意である必要があります。そのため、バケット名は一意のプロジェクト ID（{{{project_0.project_id | PROJECT_ID}}}）を使用するように構成されます。

構成ファイル内のどこでリソースを定義すべきか迷うことがあるかもしれませんが、Terraform 構成ファイル内でリソースがどのような順序で定義されたとしても、Terraform による変更の適用には影響はありません。構成ファイルは、作成者やチームにとって最もわかりやすい方法で整理してください。

2. 次に、terraform plan と terraform apply を実行して、これらの変更の結果を確認します。

terraform plan terraform apply

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 バケット依存インスタンスを作成する

3. 次に進む前に、main.tf ファイルからリソース ブロック google_storage_bucket.example_bucket と google_compute_instance.another_instance を削除し、terraform apply をもう一度実行してそれらを破棄します。このラボでは、これ以降、バケットと 2 つ目のインスタンスは使用しません。

タスク 4. インフラストラクチャをプロビジョニングする

この時点では、作成したコンピューティング インスタンスは指定した Google イメージがベースとなっていますが、他のソフトウェアはインストールされておらず、他の構成も適用されていません。

Google Cloud では、ユーザー独自のカスタム オペレーティング システム イメージを使用できます。これにより、Terraform でプロビジョニングするインスタンスを必要に応じて効果的に事前構成できます。Packer はそのような作業に最適なツールであり、Google Cloud 向けのビルダーが付属しています。

Terraform は、ファイルのアップロード、シェル スクリプトの実行、構成管理ツールなど他のソフトウェアのインストールやトリガーに、プロビジョナーを使用します。

プロビジョナーを定義する

1. プロビジョナーを定義するには、構成ファイルで最初の vm_instance を定義するリソース ブロックを次のように変更します。

resource "google_compute_instance" "vm_instance" { name = "terraform-instance" machine_type = "e2-micro" tags = ["web", "dev"] provisioner "local-exec" { command = "echo ${self.name}: ${self.network_interface[0].access_config[0].nat_ip} >> ip_address.txt" } # ... }

ここでは、resource ブロック内に provisioner ブロックを 1 つ追加しています。複数のプロビジョニング ステップを定義する場合は、複数の provisioner ブロックを追加することもできます。Terraform は多数のプロビジョナーをサポートしていますが、この例では local-exec プロビジョナーを使用します。

local-exec プロビジョナーは、VM インスタンス上ではなく、Terraform を実行するマシン上でローカルにコマンドを実行します。他のプロビジョナーではなく local-exec を使用するため、この時点で接続情報を指定する必要はありません。

また、今回の例ではこれまで以上に複雑な文字列補間も含まれています。各 VM インスタンスでは複数のネットワーク インスタンスが使用可能なため、network_interface[0] で 1 番目のネットワーク インスタンスを参照しています。この場合、大半のプログラミング言語と同様、0 から始まるインデックスを使用します。各ネットワーク インスタンスでは複数の access_config ブロックも使用可能なため、1 番目の access_config ブロックも同様に指定します。

2. terraform apply を次のように実行します。

terraform apply

初めはこの時点の出力に戸惑うかもしれません。

Terraform は何も行いませんでした。確認すると、ローカルマシンに ip_address.txt ファイルはありません。

Terraform によるプロビジョナーの扱いは、他の引数とは異なります。プロビジョナーはリソースの作成時のみ実行されますが、プロビジョナーを追加しても、そのリソースの破棄や再作成は強制的には実行されません。

3. Terraform にインスタンスの再作成を指示するには、terraform taint を実行します。

terraform taint google_compute_instance.vm_instance

tainted 状態になったリソースは、次回の apply 時に破棄され、再作成されます。

4. ここで、terraform apply を実行します。

terraform apply

5. ip_address.txt ファイルの内容を調べ、すべてが正しく実行されたことを確認します。

指定したとおりに IP アドレスが含まれています。

プロビジョナーの失敗と tainted 状態のリソース

リソースが正常に作成されてもプロビジョナーのステップが失敗した場合は、Terraform でエラーが発生し、リソースが tainted としてマークされます。リソースは tainted 状態になっても存続しますが、プロビジョニングが失敗しているので安全に使用できるものとは見なされません。

次に実行プランを生成するとき、Terraform は tainted 状態のリソースをすべて削除して新しいリソースを作成し、作成後にもう一度プロビジョニングを試みます。

破棄プロビジョナー

破棄オペレーション時にのみ実行されるプロビジョナーを定義することもできます。これはシステム クリーンアップやデータ抽出などに便利です。

多くのリソースの場合、可能な限り組み込みのクリーンアップ メカニズム（初期化スクリプトなど）を使用することをおすすめしますが、必要な場合はプロビジョナーを使用できます。

このラボでは、破棄プロビジョナーの例については説明しません。破棄プロビジョナーを使用する必要がある場合は、プロビジョナーのドキュメントをご覧ください。

お疲れさまでした

このラボでは、Terraform を使用してインフラストラクチャの構築、変更、破棄を行う方法について学習しました。また、Terraform 構成ファイルを使用してリソースの依存関係を作成する方法や、基本的なインフラストラクチャのプロビジョニングを行う方法についても学習しました。

次のステップと詳細情報

次のリソースを確認し、Terraform に関するその他の実践演習を受講できます。

• Google Cloud Marketplace の Hashicorp
• Hashicorp Learn
• Terraform コミュニティ
• Terraform の Google の例

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2026 年 7 月 14 日

ラボの最終テスト日: 2026 年 7 月 14 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。