
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Provision infrastructure
/ 50
Upload files to the bucket
/ 50
このラボは Google のパートナーである Hashicorp と共同開発されました。アカウント プロフィールでサービスの最新情報、お知らせ、特典の受け取りを希望された場合、お客様の個人情報が本ラボのスポンサーである Hashicorp と共有される可能性があります。
Terraform でインフラストラクチャの管理を行っていると、構成が次第に複雑になってきます。Terraform の構成ファイルも構成ディレクトリも複雑化を止める方法が事実上ないため、1 つのディレクトリ内で構成ファイルの作成と更新を延々と続けてしまう可能性があります。しかし、それを続けると以下のような問題が生じることがあります。
このラボでは、こうした問題をモジュールによって解決する方法、Terraform モジュールの構造、モジュールを使用および作成する際のベスト プラクティスについて学びます。
上記の問題の解決にモジュールがどのように役立つのかを、以下に示します。
構成の体系化: モジュール化して、構成の相互に関連する部分をまとめることで、構成の管理、把握、更新が容易になります。それほど複雑でないインフラストラクチャでも、何百行または何千行もの構成の実装が必要になることがあります。モジュールを使用すると、構成を整理して論理的なコンポーネントにまとめることができます。
構成のカプセル化: モジュールを使用するもう 1 つの利点は、構成を個別の論理コンポーネントにカプセル化できることです。カプセル化すると、構成の一部を変更した場合に他のインフラストラクチャまで変更されてしまうといった、意図しない結果を防ぐことができます。また、2 つの異なるリソースに同じ名前を使用するといった、単純なエラーの回避にもつながります。
構成の再利用: 既存のコードを利用せずにすべての構成を記述しようとすると、相当な時間がかかり、エラーも発生しやすくなります。自分または他のチームメンバー、あるいは他の Terraform 利用者が作成してモジュールとして公開している構成を再利用すれば、時間を節約でき、費用がかさむエラーの発生を抑えることができます。自分が作成したモジュールをチームまたは一般の人々と共有し、苦労の末に得られた成果を分かち合うこともできます。
整合性の維持とベスト プラクティスの確立: モジュールは、構成の整合性を確保するうえでも役に立ちます。整合性があれば、複雑な構成の把握が容易になります。また、構成のすべての部分にベスト プラクティスを適用しやすくなります。たとえば、クラウド プロバイダは、Amazon S3(Simple Storage Service)や Google の Cloud Storage バケットなどのオブジェクト ストレージ サービスを構成するためのオプションを数多く提供しています。多くの重要なセキュリティ インシデントには、セキュリティの保護に不備があるオブジェクト ストレージが関係しています。こうしたサービスは、複雑な構成オプションが多いため、不慮の構成エラーが発生しやすくなっています。
モジュールを使用すると、こうしたエラーの発生を抑えることができます。たとえば、組織の公開ウェブサイト バケットのすべてがどのように構成されるかを記述するモジュールや、ロギング アプリケーションで使用される限定公開バケット用のモジュールを作成できます。また、あるタイプのリソース用の構成を更新する必要がある場合、モジュールを使えば、1 か所を更新するだけで、そのモジュールを使用するすべてのケースに更新内容を適用できます。
このラボでは、次のタスクの実行方法について学びます。
こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、Google Cloud のリソースを利用できる時間を示しています。
このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。
このラボを完了するためには、下記が必要です。
[ラボを開始] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。 左側の [ラボの詳細] パネルには、以下が表示されます。
[Google Cloud コンソールを開く] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウでリンクを開く] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
必要に応じて、下のユーザー名をコピーして、[ログイン] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [ユーザー名] を確認できます。
[次へ] をクリックします。
以下のパスワードをコピーして、[ようこそ] ダイアログに貼り付けます。
[ラボの詳細] パネルでも [パスワード] を確認できます。
[次へ] をクリックします。
その後次のように進みます。
その後、このタブで Google Cloud コンソールが開きます。
Cloud Shell は、開発ツールと一緒に読み込まれる仮想マシンです。5 GB の永続ホーム ディレクトリが用意されており、Google Cloud で稼働します。Cloud Shell を使用すると、コマンドラインで Google Cloud リソースにアクセスできます。
接続した時点で認証が完了しており、プロジェクトに各自の PROJECT_ID が設定されます。出力には、このセッションの PROJECT_ID を宣言する次の行が含まれています。
gcloud
は Google Cloud のコマンドライン ツールです。このツールは、Cloud Shell にプリインストールされており、タブ補完がサポートされています。
[承認] をクリックします。
出力は次のようになります。
出力:
出力:
出力例:
gcloud
ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。
Terraform モジュールとは、Terraform 構成ファイルを 1 つのディレクトリ内に集めたものです。1 つのディレクトリに .tf
ファイルが 1 つまたは複数だけという単純な構成でも、1 つのモジュールです。このようなディレクトリから Terraform コマンドを直接実行すると、そのディレクトリはルート モジュールと見なされます。この意味では、あらゆる Terraform 構成がモジュールの一部になります。次のような単純な Terraform 構成ファイルの集まりについて考えます。
この場合、minimal-module
ディレクトリ内で Terraform コマンドを実行すると、そのディレクトリの中身がルート モジュールと見なされます。
Terraform コマンドは、あるディレクトリ(通常は、現在作業しているディレクトリ)内の構成ファイルを直接使用します。ただし、モジュール ブロックを使った構成では、他のディレクトリにあるモジュールを呼び出すこともできます。モジュール ブロックがあると、Terraform はそのモジュールの構成ファイルを読み込んで処理します。
別の構成によって呼び出されるモジュールを、その構成の「子モジュール」と呼ぶことがあります。
モジュールの読み込みは、ローカル ファイルシステムとリモートソースのどちらからでも行えます。Terraform は、Terraform Registry やほとんどのバージョン管理システム、HTTP URL、Terraform Cloud または Terraform Enterprise の限定公開モジュール レジストリなど、さまざまなリモートソースをサポートしています。
Terraform モジュールには、ほとんどのプログラミング言語に見られるライブラリ、パッケージ、モジュールの概念との類似点が数多くあり、それらの利点の多くが備わっています。ほぼすべての重要なコンピュータ プログラムと同様、実世界の Terraform 構成でも、上記の利点を活かすために必ずと言っていいほどモジュールを利用します。
すべての Terraform 利用者は、以下のベスト プラクティスに沿ってモジュールを使用することが推奨されます。
モジュール化のプランに沿って構成を記述し始める。それほど複雑でない Terraform 構成を 1 人で管理する場合でも、モジュールを使用する利点は、モジュールの適切な使用に時間がかかるという欠点を補って余りあるものです。
ローカル モジュールを使用して、コードを体系化してカプセル化する。リモート モジュールを使用したり公開したりしない場合でも、最初から構成をモジュールとして整理しておけば、インフラストラクチャが複雑になった際に、構成のメンテナンスと更新にかかる負担を大幅に軽減できます。
一般公開の Terraform Registry を使用して有用なモジュールを見つける。他の人の成果物を利用することで、短時間で確実に自分の構成を実装できます。
モジュールをチーム内で公開して共有する。ほとんどのインフラストラクチャはチームで管理されるため、モジュールは、インフラストラクチャの構築とメンテナンスをチームで行うための重要なツールとなります。前述のように、モジュールは一般公開にすることも限定公開にすることもできます。こうした公開方法については、このシリーズの別のラボで説明します。
このセクションでは、Terraform Registry にあるモジュールを使用して、Google Cloud でサンプル環境のプロビジョニングを行います。ここで紹介する考え方は、ソースにかかわらずすべてのモジュールに適用できます。
このページには、モジュールに関する情報とソース リポジトリへのリンクが記載されています。ページの右側には、モジュールのバージョンを選択するためのプルダウンと、このモジュールを使ってインフラストラクチャをプロビジョニングする手順が表示されています。
モジュールを呼び出す際には、source
引数を指定する必要があります。この例では、与えられた文字列に一致する Terraform Registry 内のモジュールが検索されます。URL またはローカル ファイルのパスをモジュールのソースとして指定することもできます。使用できるモジュール ソースの一覧は、Terraform のドキュメントをご覧ください。
ここにはもう 1 つの引数、version
が示されています。version を使用すると、サポートされているソースに対し、どのバージョンのモジュールが読み込まれるかを定義できます。このラボでは、自分が使用するモジュールの正確なバージョン番号を指定します。バージョンを指定するその他の方法については、モジュールのドキュメントをご覧ください。
モジュール ブロックに対するその他の引数は、モジュールへの入力変数として扱われます。
v6.0.1
ブランチに切り替えます。これにより、適切なバージョン番号が確実に使用されます。
Cloud Shell ツールバーで [エディタを開く] をクリックします。Cloud Shell とコードエディタを切り替えるには、必要に応じて [エディタを開く] または [ターミナルを開く] をクリックするか、[新しいウィンドウで開く] をクリックして別のタブでエディタを開いたままにします。
エディタで、terraform-google-network/examples/simple_project
を参照して main.tf
ファイルを開きます。main.tf
による構成内容は次のようになります。
この構成には重要なブロックが 1 つ含まれています。
module "test-vpc-module"
は Virtual Private Cloud(VPC)を定義する。VPC はインフラストラクチャの残り部分にネットワーク サービスを提供する。一部の入力変数は必須です。つまり、モジュールによってデフォルト値が指定されておらず、Terraform を適切に実行するには、明示的な値を指定する必要があります。
モジュールの "test-vpc-module"
ブロックで、設定している入力変数を確認します。これらの各入力変数の詳細については、Terraform Registry のページを参照してください。このモジュールの必須の入力は、次のとおりです。
network_name
: 作成されるネットワークの名前project_id
: この VPC が作成されるプロジェクトの IDsubnets
: 作成されるサブセットのリストほとんどのモジュールは、モジュール構成に入力変数を渡して使用する必要があります。モジュールを呼び出す構成は、その入力値の設定に関与します。入力値は、引数としてモジュール ブロックに渡されます。source
と version
を除き、モジュール ブロックに対する引数のほとんどは変数の値を設定します。
Terraform Registry の Google Cloud ネットワーク モジュールのページにある [Inputs] タブには、このモジュールがサポートしているすべての入力変数が記載されています。
モジュールでの入力変数の使い方は、Terraform 構成で変数を使用する場合と非常によく似ています。後で変更する可能性があるモジュール入力変数を特定したうえで、対応する変数と適切なデフォルト値を構成の variables.tf
ファイル内に作成する、というのが一般的なパターンです。これらの変数はその後、引数としてモジュール ブロックに渡すことができます。
エディタで、これまでと同じディレクトリ内にある variables.tf
を開きます。
先ほどのコマンドの出力を使って、変数 project_id
を設定します。以下の書式に沿って、この変数の default
値を設定する必要があります。
variables.tf
で、変数 network_name
を設定します。example-vpc
など、任意の名前を使用できます。以下の書式に沿って、この変数の default
値を設定する必要があります。main.tf
ファイルに戻り、network_name
パラメータの値を var.network_name
に設定して、先ほど定義した変数を使用するように更新します。main.tf
ファイルで、35、40、47 行目のサブネット リージョンを us-west1
から モジュールには出力値もあります。出力値の定義は、キーワード output
を使ってモジュール内で行います。出力値にアクセスするには、module.<モジュール名>.<出力名>
のように指定します。入力変数と同様、モジュールの出力は Terraform Registry のページの [Outputs
] タブに記されています。
通常、モジュールの出力は、構成の他の部分に渡されるか、ルート モジュールで出力として定義されるかのどちらかになります。このラボでは、両方の使用例を紹介します。
outputs.tf
ファイルを開きます。このファイルに以下の記述があることを確認します。simple_project
ディレクトリに移動します。これで、最初のモジュールの利用が完了しました。構成の出力は、次のようになるはずです。
新しいモジュールを初めて使用する際には、terraform init
または terraform get
のどちらかを実行してモジュールをインストールする必要があります。これらのコマンドのいずれかを実行すると、構成の作業ディレクトリ内の .terraform/modules
ディレクトリにある新しいモジュールが Terraform によってすべてインストールされます。ローカル モジュールの場合は、そのモジュールのディレクトリへのシンボリック リンクが作成されます。そのため、ローカル モジュールに対する変更は terraform get
を実行し直さなくてもすぐに有効になります。
ここまでは、Terraform Registry にあるモジュールについて、その使用方法、入力変数による構成方法、出力値の取得方法を説明しました。
プロンプトに「yes
」と入力します。
作成したインフラストラクチャが Terraform によって破棄されます。
リソースを破棄したら、terraform-google-network
フォルダを削除します。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
前のタスクでは、Terraform Registry にあるモジュールを使って Google Cloud 内に VPC ネットワークを作成しました。既存の Terraform モジュールを正しく使用することは重要なスキルですが、Terraform 技術者ならだれでも、モジュールの作成方法を学ぶメリットはあります。すべての Terraform 構成はモジュールとしての使用を想定して作成することをおすすめします。これにより、柔軟性が高く、再利用や組み合わせが可能な構成を設計できます。
すでに説明したとおり、Terraform ではすべての構成がモジュールとして扱われます。terraform
コマンドを実行するか、Terraform Cloud または Terraform Enterprise を使用して Terraform をリモートで実行すると、Terraform 構成が含まれているターゲット ディレクトリがルート モジュールとして扱われます。
このタスクでは、静的ウェブサイトのホスティングに使用されるコンピューティングおよびストレージ バケットを管理するためのモジュールを作成します。
Terraform は、module
ブロックの source
引数で参照されているすべてのローカル ディレクトリをモジュールとして扱います。新しいモジュールの一般的な構造は、次のとおりです。
.tf
ファイルだけで作成できます。他の任意のファイル構造を使用することもできます。
これらの各ファイルの用途は、次のとおりです。
LICENSE
にはモジュールを配布する際のライセンスが記載される。モジュールを共有する際に、この LICENSE ファイルによってモジュールの使用者に利用条件を知らせることができる。Terraform 自体はこのファイルを使用しない。README.md
には、モジュールの使用方法を説明するドキュメントが Markdown 形式で記載される。Terraform はこのファイルを使用しないが、モジュールの Terraform Registry ページや GitHub ページにアクセスした人には、Terraform Registry や GitHub のようなサービスによって、このファイルの内容が表示される。main.tf
には、モジュールの構成の主要な部分が含まれる。その他の構成ファイルを作成し、プロジェクトに合うように構成ファイルを整理することもできる。variables.tf
には、モジュール用の変数定義が含まれる。他の人がこのモジュールを使用する際、各変数はモジュール ブロック内の引数として構成される。Terraform ではすべての値を定義する必要があるため、デフォルト値を持たない変数はすべて必須の引数になる。デフォルト値がある変数は、モジュール引数として指定することもできる。その場合、デフォルト値はオーバーライドされる。outputs.tf
には、モジュールの出力の定義が含まれる。モジュールの出力は、モジュールを使った構成で使用できるため、多くの場合、モジュールで定義されたインフラストラクチャの各部分に関する情報を構成の他の部分に渡すために使用される。これらのファイルに注意し、モジュールの一部として配布しないようにしてください。
terraform.tfstate
ファイルと terraform.tfstate.backup
ファイルは、Terraform の状態を格納し、構成とその構成によってプロビジョニングされるインフラストラクチャとの関係が Terraform によってどのように追跡されるかを示す。.terraform
ディレクトリには、インフラストラクチャのプロビジョニングに使用されるモジュールとプラグインが含まれる。これらのファイルは、.tf
ファイルで定義されたインフラストラクチャの構成に固有のものではなく、インフラストラクチャをプロビジョニングする際の Terraform の個々のインスタンスに固有のものである。*.tfvars
ファイルは、スタンドアロンの Terraform 構成としても使用する場合を除き、モジュールと一緒に配布する必要はない。モジュールの入力変数は、構成内のモジュール ブロックへの引数によって設定されるためである。ホーム ディレクトリに移動し、新しい構成ファイル main.tf
を記述することでルート モジュールを作成します。次に、modules というディレクトリを作成し、その内部に gcs-static-website-bucket
という別のフォルダを作成します。gcs-static-website-bucket
ディレクトリの内部で 3 つの Terraform 構成ファイル website.tf
、variables.tf
、outputs.tf
を扱います。
gcs-static-website-bucket
ディレクトリ内で次のコマンドを実行し、コマンドの後に続く内容で README.md
というファイルを作成します。LICENSE
という別のファイルを作成し、その内容を次のようにします。この時点で、モジュールのディレクトリの構造は次のようになっているはずです。
modules/gcs-static-website-bucket
ディレクトリ内の website.tf
ファイルに追加します。プロバイダのドキュメントは、GitHub にあります。
variables.tf
ファイルを開き、次のコードを追加します。outputs.tf
ファイルでモジュールへの出力を追加します。変数と同様、モジュールでの出力もルート モジュールの場合と同じ役割を果たしますが、アクセス方法が異なります。モジュールの出力には、モジュール オブジェクトの読み取り専用属性としてアクセスできます。モジュール オブジェクトは、そのモジュールを呼び出す構成内で参照できます。
main.tf
に戻り、新しいモジュールへの参照を追加します。outputs.tf
ファイルを作成します。outputs.tf
ファイルに次のコードを追加します。variables.tf
ファイルを作成します。variables.tf
ファイルに次のコードを追加します。変数の project_id
と name
のデフォルトには、プロジェクト ID 新しいモジュールが構成に追加されるたびに、Terraform はそのモジュールをインストールして使えるようにする必要があります。terraform get
と terraform init
の両方のコマンドによってモジュールのインストールと更新を行います。terraform init
のコマンドは、バックエンドの初期化とプラグインのインストールも行います。
独自のモジュールを構成して使用し、静的ウェブサイトを作成しました。すぐにこの静的ウェブサイトにアクセスしたいところですが、現時点ではバケットが空なので、このウェブサイトには何も表示されません。なんらかのコンテンツを表示するには、バケットにオブジェクトをアップロードする必要があります。www
ディレクトリのコンテンツを GitHub リポジトリでアップロードできます。
YOUR-BUCKET-NAME
の部分をストレージ バケットの名前で置き換えます。https://storage.cloud.google.com/YOUR-BUCKET-NAME/index.html
(YOUR-BUCKET-NAME
の部分はストレージ バケットの名前で置き換える)にアクセスします。「ここに表示されるものはありません」と書かれた、簡易 HTML のウェブページが表示されます。
[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。
最後に、作成したインフラストラクチャを破棄してプロジェクトをクリーンアップします。
プロンプトに「yes
」と入力すると、このラボで作成したすべてのリソースが Terraform によって破棄されます。
このラボでは、Terraform モジュールの基礎と、Registry にある既存モジュールの使用方法を学習しました。また、Cloud Storage バケットでホスティングされる静的ウェブサイトを作成するための独自モジュールを構築しました。その際には、構成ファイル用の入力、出力、変数を定義し、モジュール構築のベスト プラクティスを学びました。
次のリンクから、Terraform に関するその他の実践演習を行うことができます。
Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。
マニュアルの最終更新日: 2024 年 1 月 26 日
ラボの最終テスト日: 2023 年 12 月 11 日
Copyright 2025 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。
このコンテンツは現在ご利用いただけません
利用可能になりましたら、メールでお知らせいたします
ありがとうございます。
利用可能になりましたら、メールでご連絡いたします
One lab at a time
Confirm to end all existing labs and start this one