チェックポイント
Creating Resources in terraform
/ 30
Change Infrastructure
/ 20
Destructive Changes
/ 20
Create Resource Dependencies
/ 20
Create bucket dependent instance
/ 10
Terraform を使用した Infrastructure as Code
このラボは 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 コンソールを開く] ボタン
- 残り時間
- このラボで使用する必要がある一時的な認証情報
- このラボを行うために必要なその他の情報（ある場合）
-
[Google コンソールを開く] をクリックします。 ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択] ダイアログが表示されたら、[別のアカウントを使用] をクリックします。 -
必要に応じて、[ラボの詳細] パネルから [ユーザー名] をコピーして [ログイン] ダイアログに貼り付けます。[次へ] をクリックします。
-
[ラボの詳細] パネルから [パスワード] をコピーして [ようこそ] ダイアログに貼り付けます。[次へ] をクリックします。
重要: 認証情報は左側のパネルに表示されたものを使用してください。Google Cloud Skills Boost の認証情報は使用しないでください。 注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。 -
その後次のように進みます。
- 利用規約に同意してください。
- 一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
- 無料トライアルには登録しないでください。
その後このタブで Cloud Console が開きます。
Cloud Shell をアクティブにする
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
- Google Cloud コンソールの上部にある「Cloud Shell をアクティブにする」アイコン
をクリックします。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
- （省略可）次のコマンドを使用すると、有効なアカウント名を一覧表示できます。
-
[承認] をクリックします。
-
出力は次のようになります。
出力:
- （省略可）次のコマンドを使用すると、プロジェクト ID を一覧表示できます。
出力:
出力例:
gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
タスク 1. インフラストラクチャの構築
Terraform は、Cloud Shell にプリインストールされています。インストール済みの Terraform を使用することで、インフラストラクチャの作成を即座に始めることができます。
まず、main.tf というファイルにサンプルの構成を作成します。Terraform では、名前が .tf または .tf.json で終わるファイルが構成ファイルとして認識され、実行時に読み込まれます。
- 次のコマンドで
main.tfファイルを作成します。
-
Cloud Shell のツールバーで [エディタを開く] ボタンをクリックします（必要に応じて [エディタを開く] アイコンおよび [ターミナルを開く] アイコンを使用して Cloud Shell とコードエディタを切り替えることができます。または、「新しいウィンドウで開く」ボタンをクリックして別のタブでエディタを開いたままにすることもできます）。
-
エディタで、
main.tfファイルに次の内容を追加します。
terraform {} ブロックを削除します。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 です。このコマンドを実行すると、それ以降のコマンドで使用されるさまざまなローカル設定やローカルデータが初期化されます。
-
main.tfファイルと同じディレクトリでterraform initを実行して新しい Terraform 構成を初期化します。
リソースの作成
- 次に、
terraform applyを実行して構成を適用します。
出力でリソース "google_compute_network" "vpc_network" の横に「+」が表示されます。これは、このリソースが Terraform で新規に作成されることを表しています。その下に、設定される属性が表示されます。値が (known after apply) になっている場合、その属性の値はリソースが作成されるまでわかりません。
プランが正常に作成された場合、Terraform はここで一時停止して、続行する前に承認を求めます。プランに正しくない内容や危険な内容が含まれていると思われる場合は、インフラストラクチャを変更せず、ここで中止するのが安全です。
terraform apply がエラーで失敗した場合は、エラー メッセージを確認し、発生したエラーを修正してください。
- この例ではプランに問題がないようなので、確認プロンプトで「
yes」と入力して続行します。
プランの実行には数分かかります。ネットワークが正常に作成されるまで Terraform が待機するためです。
以上で Terraform の作業は終了です。Cloud コンソールに移動すると、プロビジョニングしたネットワークを確認できます。
- コンソールのナビゲーション メニューで [VPC ネットワーク] に移動します。
terraform-networkがプロビジョニングされていることを確認できます。
- Cloud Shell で
terraform showコマンドを実行して現在の状態を確認します。
これらの値を参照して他のリソースや出力を構成できます。これについては、このラボで後ほど説明します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 2. インフラストラクチャの変更
前のセクションでは、Terraform で基本的なインフラストラクチャとして VPC ネットワークを作成しました。このセクションでは構成を変更し、その変更が Terraform でどのように処理されるかを確認します。
インフラストラクチャは絶えず進化を続けるため、そのような変更の管理と適用を支援するために Terraform が開発されました。Terraform 構成を変更すると、望ましい状態に到達するために必要な変更のみを適用する実行プランが作成されます。
Terraform を使用してインフラストラクチャを変更することにより、構成だけでなく状態のバージョン管理も行うことができ、インフラストラクチャの経時的変化を確認できます。
リソースの追加
新規のリソースを追加するには、Terraform 構成にリソースを追加し、terraform apply を実行してそのリソースをプロビジョニングします。
- エディタで
main.tfにコンピューティング インスタンス リソースを追加します。
このリソースには、より多くの引数が指定されています。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 ブロックを指定することにより、引数を何も指定しなくても、このインスタンスにインターネット経由でアクセスできるようになります。
- 次に、
terraform applyを実行してコンピューティング インスタンスを作成します。
- ここでも、確認プロンプトで「
yes」と入力します。
これはとてもわかりやすい変更といえるでしょう。"vm_instance" という名前の "google_compute_instance" リソースを構成に追加し、そのリソースが Terraform によって Google Cloud に作成されました。
リソースの変更
Terraform では、リソースを作成するだけでなく、作成したリソースに変更を加えることもできます。
- 次のように、この例の "vm_instance" に
tags引数を追加します。
-
terraform applyをもう一度実行してインスタンスを更新します。
- 接頭辞「
~」は、リソースがインプレースで更新されることを意味します。「yes」と入力して変更の適用を続行すると、インスタンスにタグが追加されます。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
破壊的変更
破壊的変更とは、既存のリソースを更新するのではなく置き換えることが必要になる変更です。一般に、これは構成で記述した方法でリソースを更新することがクラウド プロバイダでサポートされない場合に行います。
たとえば、インスタンスのディスク イメージの変更は破壊的変更です。
- 構成ファイルを編集して
vm_instanceリソース内のboot_diskブロックを次のように変更します。
- 次に、
terraform applyをもう一度実行して既存のリソースにこの変更がどう適用されるかを確認します。
接頭辞「-/+」は、リソースをインプレースで更新するのではなく、リソースを一度破棄してから再作成することを意味します。一部の属性はインプレースで更新できますが（これは接頭辞「~」で示されます）、インスタンスのブートディスク イメージを変更するにはインスタンスを再作成する必要があります。Terraform と Google Cloud プロバイダでこうした変更が自動的に処理され、Terraform が処理する内容は実行プランで示されます。
また、実行プランでは、ディスク イメージの変更によってインスタンスの置き換えが必要になったことも示されます。リソースを破棄または作成する更新が許容されない状況にある場合は、この情報を参照して、そのような変更を回避するように調整することができます。
- ここでも確認プロンプトが表示され、実行プランの続行の承認が求められます。「
yes」を入力してプランされたステップを実行します。
実行プランで示されるように、Terraform はまず既存のインスタンスを破棄し、次に元のインスタンスに代わる新しいインスタンスを作成します。terraform show をもう一度実行して、このインスタンスに関連付けられている新しい値を確認します。
インフラストラクチャの破棄
ここまでで、インフラストラクチャの構築方法と変更方法について学びました。複数リソースの作成とリソースの依存関係の確認に進む前に、Terraform で管理するインフラストラクチャを完全に破棄する方法について学びましょう。
インフラストラクチャの破棄を本番環境で行うことはあまりありません。ただし、Terraform を使用して開発環境、テスト環境、ステージング環境など複数の環境をスピンアップする場合は、破棄を行うことが有効な場合があります。
リソースを破棄するには、terraform destroy を使用します。このコマンドは terraform apply と似ていますが、構成からすべてのリソースが削除されたかのように動作します。
-
terraform destroyを実行します。このプランを実行してインフラストラクチャを破棄するには、「yes」と入力します。
接頭辞「-」は、インスタンスとネットワークが破棄されることを示します。terraform apply と同様に実行プランが表示され、変更の実行を承認するまで待機中になります。
terraform apply の場合と同じく、破棄の手順は Terraform によって決定されます。Google Cloud ではリソースが残っている VPC ネットワークは削除できないため、Terraform はインスタンスが破棄されるまで待機してからネットワークを破棄します。Terraform はオペレーションの実行時に依存関係グラフを作成してオペレーションの正しい順序を決定します。複数のリソースに関わる複雑なケースでは、安全に行える場合に複数のオペレーションが同時に実行されます。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
タスク 3. リソースの依存関係の作成
このセクションでは、リソースの依存関係について学習し、リソース パラメータを使用してリソースの情報を他のリソースと共有する方法について学習します。
現実のインフラストラクチャは、多様なリソースとリソースタイプで構成されます。Terraform 構成には複数のリソースと複数のリソースタイプを含めることができ、これらのタイプが複数のプロバイダにまたがることも可能です。
このセクションでは、複数のリソースを構成する方法と、リソースの属性を使用して他のリソースを構成する方法について基本的な例を示します。
- ネットワークとインスタンスを再作成します。プロンプトに「
yes」と入力すると、リソースが作成されます。
静的 IP アドレスの割り当て
- 次に、
main.tfで VM インスタンスに静的 IP を割り当てて構成に追加します。
これは、これまでの例で VM インスタンス リソースを追加した手順に似ていますが、ここでは "google_compute_address" リソースタイプを作成する点が異なります。このリソースタイプはプロジェクトに予約済み IP アドレスを割り振ります。
- 次に、
terraform planを実行します。
terraform plan で作成される内容が表示されます。
terraform apply とは異なり、plan コマンドは変更する内容を示すだけです。実際に変更内容を直接適用するわけではありません。この時点までに加えた変更は静的 IP の追加だけです。次に、その IP アドレスをインスタンスに割り当てる必要があります。
- インスタンスの
network_interface構成を次のように更新します。
access_config ブロックには省略可能な引数が複数ありますが、ここでは nat_ip を静的 IP アドレスに設定します。Terraform は、この構成を読み取り、次の処理を行います。
-
vm_instanceを作成する前にvm_static_ipを作成するようにする -
vm_static_ipのプロパティを状態に保存する -
nat_ipをvm_static_ip.addressプロパティの値に設定する
- terraform plan をもう一度実行します。ただし、今回はプランを保存します。
このようにプランを保存しておくことで、今後まったく同じプランを適用できます。プランで作成されたファイルを適用しようとすると、そのプランの適用前にまず、完全に同じ変更を加えてもよいかどうか、Terraform によって確認されます。
この場合、新しい google_compute_address が作成され、それを使用する既存の VM が更新されることが見て取れます。
-
terraform apply "static_ip"を実行し、Terraform プランでこの変更がどのように適用されるかを確認します。
上記のように、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 を使用してこの依存関係を明示的に宣言する必要があります。
- Cloud Storage バケットと、そのバケットに明示的に依存するインスタンスを追加するには、
main.tfに次のコードを追加します。
UNIQUE-BUCKET-NAME を一意の有効なバケット名に置き換える必要があります。通常、作成者自身の名前と日付を組み合わせて使用するのが、一意のバケット名を作成する優れた方法となります。
構成ファイル内のどこでリソースを定義すればよいか、迷うことがあるかもしれませんが、Terraform 構成ファイルでリソースを定義する順序は、Terraform がどのように変更を適用するかには影響を及ぼしません。構成ファイルは、作成者やチームにとって最もわかりやすい方法で整理してください。
- 次に、terraform plan と terraform apply を実行して、これらの変更の結果を確認します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
- 次に進む前に、これらの新しいリソースを構成から削除し、
terraform applyをもう一度実行してそれらを破棄します。このラボでは、これ以降、バケットと 2 つ目のインスタンスは使用しません。
タスク 4. インフラストラクチャのプロビジョニング
この時点では、作成したコンピューティング インスタンスは指定した Google イメージに基づいていますが、他のソフトウェアはインストールされておらず、他の構成も適用されていません。
Google Cloud では、ユーザー独自のカスタム オペレーティング システム イメージを使用できます。これにより、Terraform でプロビジョニングするインスタンスを必要に応じて効果的に事前構成できます。Packer はそのような作業に最適なツールであり、Google Cloud 向けのビルダーが付属しています。
Terraform は、ファイルのアップロード、シェル スクリプトの実行、構成管理ツールなど他のソフトウェアのインストールやトリガーに、プロビジョナーを使用します。
プロビジョナーの定義
- プロビジョナーを定義するには、構成ファイルで最初の
vm_instanceを定義するリソース ブロックを次のように変更します。
ここでは、resource ブロック内に 1 つの provisioner ブロックを追加しています。複数のプロビジョニング ステップを定義する場合は、複数の provisioner ブロックを追加することもできます。Terraform は多数のプロビジョナーをサポートしていますが、この例では local-exec プロビジョナーを使用します。
local-exec プロビジョナーは、VM インスタンス上ではなく、Terraform を実行するマシン上でローカルにコマンドを実行します。ここでは他のプロビジョナーではなくこのプロビジョナーを使用するため、この時点で接続情報を指定する必要はありません。
また、これまで以上に複雑な文字列補間の例も示されています。各 VM インスタンスでは複数のネットワーク インスタンスが使用可能なため、network_interface[0] で 1 番目のネットワーク インスタンスを参照しています。この場合、大半のプログラミング言語と同様、0 から始まるインデックスを使用します。各ネットワーク インスタンスでは複数の access_config ブロックも使用可能なため、1 番目の access_config ブロックも同様に指定します。
-
terraform applyを次のように実行します。
初めはこの時点の出力に戸惑うかもしれません。
Terraform は何も行いませんでした。確認すると、ローカルマシンに ip_address.txt ファイルはありません。
Terraform によるプロビジョナーの扱いは、他の引数とは異なります。プロビジョナーはリソースの作成時のみ実行されますが、プロビジョナーを追加しても、そのリソースの破棄や再作成は強制的には実行されません。
- Terraform にインスタンスの再作成を指示するには、
terraform taintを実行します。
tainted 状態になったリソースは、次回の apply 時に破棄され、再作成されます。
- ここで、
terraform applyを実行します。
-
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 テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2024 年 1 月 26 日
ラボの最終テスト日: 2023 年 9 月 25 日
Copyright 2024 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。