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

GSP751

概要

Terraform でインフラストラクチャの管理を行っていると、構成が次第に複雑になってきます。Terraform の構成ファイルも構成ディレクトリも複雑化を止める方法が事実上ないため、1 つのディレクトリ内で構成ファイルの作成と更新を延々と続けてしまう可能性があります。しかし、それを続けると以下のような問題が生じることがあります。

• 構成ファイルの把握と管理が次第に困難になる。
• 1 つのブロックを更新すると構成の他のブロックに想定外の影響が及ぶ可能性があるため、構成の更新に伴うリスクが高くなる。
• 類似する構成ブロックの複製が増える可能性がある。たとえば、開発、ステージング、本番の各環境を個別に構成している場合、それぞれで更新が必要になり、負担が大きくなる。
• 構成の一部をプロジェクト間およびチーム間で共有したい場合、プロジェクト間で構成のブロックを切り取って貼り付けることでエラーが生じたり、メンテナンスが難しくなったりする可能性がある。

このラボでは、こうした問題をモジュールによって解決する方法、Terraform モジュールの構造、モジュールを使用および作成する際のベスト プラクティスについて学びます。

モジュールの目的

上記の問題の解決にモジュールがどのように役立つのかを、以下に示します。

• 構成の体系化: モジュール化して、構成の相互に関連する部分をまとめることで、構成の管理、把握、更新が容易になります。それほど複雑でないインフラストラクチャでも、何百行または何千行もの構成の実装が必要になることがあります。モジュールを使用すると、構成を整理して論理的なコンポーネントにまとめることができます。

• 構成のカプセル化: モジュールを使用するもう 1 つの利点は、構成を個別の論理コンポーネントにカプセル化できることです。カプセル化すると、構成の一部を変更した場合に他のインフラストラクチャまで変更されてしまうといった、意図しない結果を防ぐことができます。また、2 つの異なるリソースに同じ名前を使用するといった、単純なエラーの回避にもつながります。

• 構成の再利用: 既存のコードを利用せずにすべての構成を記述しようとすると、相当な時間がかかり、エラーも発生しやすくなります。自分または他のチームメンバー、あるいは他の Terraform 利用者が作成してモジュールとして公開している構成を再利用すれば、時間を節約でき、費用がかさむエラーの発生を抑えることができます。自分が作成したモジュールをチームまたは一般の人々と共有し、苦労の末に得られた成果を分かち合うこともできます。

• 整合性の維持とベスト プラクティスの確立: モジュールは、構成の整合性を確保するうえでも役に立ちます。整合性があれば、複雑な構成の把握が容易になります。また、構成のすべての部分にベスト プラクティスを適用しやすくなります。たとえば、クラウド プロバイダは、Amazon S3（Simple Storage Service）や Google の Cloud Storage バケットなどのオブジェクト ストレージ サービスを構成するためのオプションを数多く提供しています。多くの重要なセキュリティ インシデントには、セキュリティの保護に不備があるオブジェクト ストレージが関係しています。こうしたサービスは、複雑な構成オプションが多いため、不慮の構成エラーが発生しやすくなっています。

モジュールを使用すると、こうしたエラーの発生を抑えることができます。たとえば、組織の公開ウェブサイト バケットのすべてがどのように構成されるかを記述するモジュールや、ロギング アプリケーションで使用される限定公開バケット用のモジュールを作成できます。また、あるタイプのリソース用の構成を更新する必要がある場合、モジュールを使えば、1 か所を更新するだけで、そのモジュールを使用するすべてのケースに更新内容を適用できます。

目標

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

• Registry にあるモジュールを使用する
• モジュールを構築する

設定と要件

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

こちらの手順をお読みください。ラボの時間は記録されており、一時停止することはできません。[ラボを開始] をクリックするとスタートするタイマーは、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 をアクティブにする」アイコン をクリックします。

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

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

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

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

gcloud auth list

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

4. 出力は次のようになります。

出力:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

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

gcloud config list project

出力:

[core] project = <project_ID>

出力例:

[core] project = qwiklabs-gcp-44776a13dea667a6 注: Google Cloud における gcloud ドキュメントの全文については、gcloud CLI の概要ガイドをご覧ください。

Terraform モジュールとは

Terraform モジュールとは、Terraform 構成ファイルを 1 つのディレクトリ内に集めたものです。1 つのディレクトリに .tf ファイルが 1 つまたは複数だけという単純な構成でも、1 つのモジュールです。このようなディレクトリから Terraform コマンドを直接実行すると、そのディレクトリはルート モジュールと見なされます。この意味では、あらゆる Terraform 構成がモジュールの一部になります。次のような単純な Terraform 構成ファイルの集まりについて考えます。

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf

この場合、minimal-module ディレクトリ内で Terraform コマンドを実行すると、そのディレクトリの中身がルート モジュールと見なされます。

モジュールの呼び出し

Terraform コマンドは、あるディレクトリ（通常は、現在作業しているディレクトリ）内の構成ファイルを直接使用します。ただし、モジュール ブロックを使った構成では、他のディレクトリにあるモジュールを呼び出すこともできます。モジュール ブロックがあると、Terraform はそのモジュールの構成ファイルを読み込んで処理します。

別の構成によって呼び出されるモジュールを、その構成の「子モジュール」と呼ぶことがあります。

ローカル モジュールとリモート モジュール

モジュールの読み込みは、ローカル ファイルシステムとリモートソースのどちらからでも行えます。Terraform は、Terraform Registry やほとんどのバージョン管理システム、HTTP URL、Terraform Cloud または Terraform Enterprise の限定公開モジュール レジストリなど、さまざまなリモートソースをサポートしています。

モジュールに関するベスト プラクティス

Terraform モジュールには、ほとんどのプログラミング言語に見られるライブラリ、パッケージ、モジュールの概念との類似点が数多くあり、それらの利点の多くが備わっています。ほぼすべての重要なコンピュータ プログラムと同様、実世界の Terraform 構成でも、上記の利点を活かすために必ずと言っていいほどモジュールを利用します。

すべての Terraform 利用者は、以下のベスト プラクティスに沿ってモジュールを使用することが推奨されます。

• モジュール化のプランに沿って構成を記述し始める。それほど複雑でない Terraform 構成を 1 人で管理する場合でも、モジュールを使用する利点は、モジュールの適切な使用に時間がかかるという欠点を補って余りあるものです。

• ローカル モジュールを使用して、コードを体系化してカプセル化する。リモート モジュールを使用したり公開したりしない場合でも、最初から構成をモジュールとして整理しておけば、インフラストラクチャが複雑になった際に、構成のメンテナンスと更新にかかる負担を大幅に軽減できます。

• 一般公開の Terraform Registry を使用して有用なモジュールを見つける。他の人の成果物を利用することで、短時間で確実に自分の構成を実装できます。

• モジュールをチーム内で公開して共有する。ほとんどのインフラストラクチャはチームで管理されるため、モジュールは、インフラストラクチャの構築とメンテナンスをチームで行うための重要なツールとなります。前述のように、モジュールは一般公開にすることも限定公開にすることもできます。こうした公開方法については、このシリーズの別のラボで説明します。

タスク 1. Registry にあるモジュールを使用する

このセクションでは、Terraform Registry にあるモジュールを使用して、Google Cloud でサンプル環境のプロビジョニングを行います。ここで紹介する考え方は、ソースにかかわらずすべてのモジュールに適用できます。

• Terraform Network モジュール用の Terraform Registry ページを新しいブラウザタブまたはウィンドウで開きます。ページの内容は次のようになっています。

このページには、モジュールに関する情報とソース リポジトリへのリンクが記載されています。ページの右側には、モジュールのバージョンを選択するためのプルダウンと、このモジュールを使ってインフラストラクチャをプロビジョニングする手順が表示されています。

モジュールを呼び出す際には、source 引数を指定する必要があります。この例では、与えられた文字列に一致する Terraform Registry 内のモジュールが検索されます。URL またはローカル ファイルのパスをモジュールのソースとして指定することもできます。使用できるモジュール ソースの一覧は、Terraform のドキュメントをご覧ください。

ここにはもう 1 つの引数、version が示されています。version を使用すると、サポートされているソースに対し、どのバージョンのモジュールが読み込まれるかを定義できます。このラボでは、自分が使用するモジュールの正確なバージョン番号を指定します。バージョンを指定するその他の方法については、モジュールのドキュメントをご覧ください。

モジュール ブロックに対するその他の引数は、モジュールへの入力変数として扱われます。

Terraform 構成を作成する

1. 最初に Cloud Shell で次のコマンドを実行して、Google Terraform モジュールの GitHub リポジトリにある簡単なサンプル プロジェクトのクローンを作成し、v6.0.1 ブランチに切り替えます。

git clone https://github.com/terraform-google-modules/terraform-google-network cd terraform-google-network git checkout tags/v6.0.1 -b v6.0.1

これにより、適切なバージョン番号が確実に使用されます。

2. Cloud Shell ツールバーで [エディタを開く] をクリックします。Cloud Shell とコードエディタを切り替えるには、必要に応じて [エディタを開く] または [ターミナルを開く] をクリックするか、[新しいウィンドウで開く] をクリックして別のタブでエディタを開いたままにします。

3. エディタで、terraform-google-network/examples/simple_project を参照して main.tf ファイルを開きます。main.tf による構成内容は次のようになります。

module "test-vpc-module" { source = "terraform-google-modules/network/google" version = "~> 6.0" project_id = var.project_id # これをプロジェクト ID に置き換える network_name = "my-custom-mode-network" mtu = 1460 subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "us-west1" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "us-west1" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "us-west1" subnet_flow_logs = "true" subnet_flow_logs_interval = "INTERVAL_10_MIN" subnet_flow_logs_sampling = 0.7 subnet_flow_logs_metadata = "INCLUDE_ALL_METADATA" subnet_flow_logs_filter = "false" } ] }

この構成には重要なブロックが 1 つ含まれています。

• module "test-vpc-module" は Virtual Private Cloud（VPC）を定義する。VPC はインフラストラクチャの残り部分にネットワーク サービスを提供する。

モジュール入力変数の値を設定する

一部の入力変数は必須です。つまり、モジュールによってデフォルト値が指定されておらず、Terraform を適切に実行するには、明示的な値を指定する必要があります。

• モジュールの "test-vpc-module" ブロックで、設定している入力変数を確認します。これらの各入力変数の詳細については、Terraform Registry のページを参照してください。このモジュールの必須の入力は、次のとおりです。

  • network_name: 作成されるネットワークの名前
  • project_id: この VPC が作成されるプロジェクトの ID
  • subnets: 作成されるサブセットのリスト

ほとんどのモジュールは、モジュール構成に入力変数を渡して使用する必要があります。モジュールを呼び出す構成は、その入力値の設定に関与します。入力値は、引数としてモジュール ブロックに渡されます。source と version を除き、モジュール ブロックに対する引数のほとんどは変数の値を設定します。

Terraform Registry の Google Cloud ネットワーク モジュールのページにある [Inputs] タブには、このモジュールがサポートしているすべての入力変数が記載されています。

ルート入力変数を定義する

モジュールでの入力変数の使い方は、Terraform 構成で変数を使用する場合と非常によく似ています。後で変更する可能性があるモジュール入力変数を特定したうえで、対応する変数と適切なデフォルト値を構成の variables.tf ファイル内に作成する、というのが一般的なパターンです。これらの変数はその後、引数としてモジュール ブロックに渡すことができます。

1. プロジェクト ID を取得するには、Cloud Shell で次のコマンドを実行します。

gcloud config list --format 'value(core.project)'

2. エディタで、これまでと同じディレクトリ内にある variables.tf を開きます。

3. 先ほどのコマンドの出力を使って、変数 project_id を設定します。以下の書式に沿って、この変数の default 値を設定する必要があります。

variable "project_id" { description = "ネットワークをホストするプロジェクトの ID" default = "ここにプロジェクト ID を記入" }

4. variables.tf で、変数 network_name を設定します。example-vpc など、任意の名前を使用できます。以下の書式に沿って、この変数の default 値を設定する必要があります。

variable "network_name" { description = "作成する VPC ネットワークの名前" default = "example-vpc" }

5. main.tf ファイルに戻り、network_name パラメータの値を var.network_name に設定して、先ほど定義した変数を使用するように更新します。

module "test-vpc-module" { ... project_id = var.project_id network_name = var.network_name ...

6. main.tf ファイルで、35、40、47 行目のサブネット リージョンを us-west1 から に更新します。これにより、プロジェクトで許可されたリージョンにサブネットが作成されるようになります。モジュールは次のようになります。

subnets = [ { subnet_name = "subnet-01" subnet_ip = "10.10.10.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" }, { subnet_name = "subnet-02" subnet_ip = "10.10.20.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" subnet_private_access = "true" subnet_flow_logs = "true" }, { subnet_name = "subnet-03" subnet_ip = "10.10.30.0/24" subnet_region = "{{{project_0.default_region | REGION}}}" ... .. }

ルート出力値を定義する

モジュールには出力値もあります。出力値の定義は、キーワード output を使ってモジュール内で行います。出力値にアクセスするには、module.<モジュール名>.<出力名> のように指定します。入力変数と同様、モジュールの出力は Terraform Registry のページの [Outputs] タブに記されています。

通常、モジュールの出力は、構成の他の部分に渡されるか、ルート モジュールで出力として定義されるかのどちらかになります。このラボでは、両方の使用例を紹介します。

• 構成のディレクトリ内にある outputs.tf ファイルを開きます。このファイルに以下の記述があることを確認します。

output "network_name" { value = module.test-vpc-module.network_name description = "作成する VPC の名前" } output "network_self_link" { value = module.test-vpc-module.network_self_link description = "作成する VPC の URI" } output "project_id" { value = module.test-vpc-module.project_id description = "VPC プロジェクト ID" } output "subnets_names" { value = module.test-vpc-module.subnets_names description = "作成するサブネットの名前" } output "subnets_ips" { value = module.test-vpc-module.subnets_ips description = "作成するサブネットの IP および CIDR" } output "subnets_regions" { value = module.test-vpc-module.subnets_regions description = "サブネットを作成するリージョン" } output "subnets_private_access" { value = module.test-vpc-module.subnets_private_access description = "サブネットがパブリック IP なしで Google API にアクセスできるかどうか" } output "subnets_flow_logs" { value = module.test-vpc-module.subnets_flow_logs description = "サブネットで VPC フローログを有効にするかどうか" } output "subnets_secondary_ranges" { value = module.test-vpc-module.subnets_secondary_ranges description = "これらのサブネットに関連付けるセカンダリ範囲" } output "route_names" { value = module.test-vpc-module.route_names description = "この VPC に関連付ける経路" }

インフラストラクチャのプロビジョニング

1. Cloud Shell で、simple_project ディレクトリに移動します。

cd ~/terraform-google-network/examples/simple_project

2. Terraform の構成を初期化します。

terraform init

3. VPC を作成します。

terraform apply

4. 変更を適用して続行するには、プロンプトに「yes」と入力します。

これで、最初のモジュールの利用が完了しました。構成の出力は、次のようになるはずです。

出力: network_name = "example-vpc" network_self_link = "https://www.googleapis.com/compute/v1/projects/qwiklabs-gcp-01-a68489b0625b/global/networks/example-vpc" project_id = "" route_names = [] subnets_flow_logs = [ false, true, true, ] subnets_ips = [ "10.10.10.0/24", "10.10.20.0/24", "10.10.30.0/24", ] subnets_names = [ "subnet-01", "subnet-02", "subnet-03", ] .... ....

モジュールの仕組みを理解する

新しいモジュールを初めて使用する際には、terraform init または terraform get のどちらかを実行してモジュールをインストールする必要があります。これらのコマンドのいずれかを実行すると、構成の作業ディレクトリ内の .terraform/modules ディレクトリにある新しいモジュールが Terraform によってすべてインストールされます。ローカル モジュールの場合は、そのモジュールのディレクトリへのシンボリック リンクが作成されます。そのため、ローカル モジュールに対する変更は terraform get を実行し直さなくてもすぐに有効になります。

インフラストラクチャをクリーンアップする

ここまでは、Terraform Registry にあるモジュールについて、その使用方法、入力変数による構成方法、出力値の取得方法を説明しました。

1. 作成したインフラストラクチャを破棄します。

terraform destroy

2. プロンプトに「yes」と入力します。 作成したインフラストラクチャが Terraform によって破棄されます。

3. リソースを破棄したら、terraform-google-network フォルダを削除します。

cd ~ rm -rd terraform-google-network -f

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 インフラストラクチャのプロビジョニング

タスク 2. モジュールを構築する

前のタスクでは、Terraform Registry にあるモジュールを使って Google Cloud 内に VPC ネットワークを作成しました。既存の Terraform モジュールを正しく使用することは重要なスキルですが、Terraform 技術者ならだれでも、モジュールの作成方法を学ぶメリットはあります。すべての Terraform 構成はモジュールとしての使用を想定して作成することをおすすめします。これにより、柔軟性が高く、再利用や組み合わせが可能な構成を設計できます。

すでに説明したとおり、Terraform ではすべての構成がモジュールとして扱われます。terraform コマンドを実行するか、Terraform Cloud または Terraform Enterprise を使用して Terraform をリモートで実行すると、Terraform 構成が含まれているターゲット ディレクトリがルート モジュールとして扱われます。

このタスクでは、静的ウェブサイトのホスティングに使用されるコンピューティングおよびストレージ バケットを管理するためのモジュールを作成します。

モジュール構造

Terraform は、module ブロックの source 引数で参照されているすべてのローカル ディレクトリをモジュールとして扱います。新しいモジュールの一般的な構造は、次のとおりです。

├── LICENSE ├── README.md ├── main.tf ├── variables.tf ├── outputs.tf 注: これらのファイルはいずれも、モジュールの使用には不要であり、Terraform にとっても特に意味のないものです。モジュールは 1 つの .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 構成としても使用する場合を除き、モジュールと一緒に配布する必要はない。モジュールの入力変数は、構成内のモジュール ブロックへの引数によって設定されるためである。

注: モジュールに対する変更を、Git などのバージョン管理システムで追跡する場合は、これらのファイルを無視するようにバージョン管理システムを構成します。例については、GitHub にある .gitignore ファイルをご覧ください。

モジュールを作成する

ホーム ディレクトリに移動し、新しい構成ファイル main.tf を記述することでルート モジュールを作成します。次に、modules というディレクトリを作成し、その内部に gcs-static-website-bucket という別のフォルダを作成します。gcs-static-website-bucket ディレクトリの内部で 3 つの Terraform 構成ファイル website.tf、variables.tf、outputs.tf を扱います。

1. 新しいモジュール用のディレクトリを作成します。

cd ~ touch main.tf mkdir -p modules/gcs-static-website-bucket

2. このモジュール ディレクトリに移動し、次のコマンドを実行して空のファイルを 3 つ作成します。

cd modules/gcs-static-website-bucket touch website.tf variables.tf outputs.tf

3. gcs-static-website-bucket ディレクトリ内で次のコマンドを実行し、コマンドの後に続く内容で README.md というファイルを作成します。

tee -a README.md <<EOF # GCS 静的ウェブサイト バケット このモジュールは静的ウェブサイトのホスティング用に構成された Cloud Storage バケットをプロビジョニングします。 EOF 注: ご利用のモジュールに対する適切なライセンスの選択は、本ラボでは取り上げません。このラボでは Apache 2.0 オープンソース ライセンスを使用します。

4. LICENSE という別のファイルを作成し、その内容を次のようにします。

tee -a LICENSE <<EOF Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. EOF 注: これらのファイルはいずれも必須ではなく、Terraform によって使用されることもありません。ただし、他の人と共有する可能性があるモジュールでは、これらのファイルを用意することをおすすめします。

この時点で、モジュールのディレクトリの構造は次のようになっているはずです。

main.tf modules/ └── gcs-static-website-bucket ├── LICENSE ├── README.md ├── website.tf ├── outputs.tf └── variables.tf

5. この Cloud Storage バケット リソースを modules/gcs-static-website-bucket ディレクトリ内の website.tf ファイルに追加します。

resource "google_storage_bucket" "bucket" { name = var.name project = var.project_id location = var.location storage_class = var.storage_class labels = var.labels force_destroy = var.force_destroy uniform_bucket_level_access = true versioning { enabled = var.versioning } dynamic "retention_policy" { for_each = var.retention_policy == null ? [] : [var.retention_policy] content { is_locked = var.retention_policy.is_locked retention_period = var.retention_policy.retention_period } } dynamic "encryption" { for_each = var.encryption == null ? [] : [var.encryption] content { default_kms_key_name = var.encryption.default_kms_key_name } } dynamic "lifecycle_rule" { for_each = var.lifecycle_rules content { action { type = lifecycle_rule.value.action.type storage_class = lookup(lifecycle_rule.value.action, "storage_class", null) } condition { age = lookup(lifecycle_rule.value.condition, "age", null) created_before = lookup(lifecycle_rule.value.condition, "created_before", null) with_state = lookup(lifecycle_rule.value.condition, "with_state", null) matches_storage_class = lookup(lifecycle_rule.value.condition, "matches_storage_class", null) num_newer_versions = lookup(lifecycle_rule.value.condition, "num_newer_versions", null) } } } }

プロバイダのドキュメントは、GitHub にあります。

6. モジュール内の variables.tf ファイルを開き、次のコードを追加します。

variable "name" { description = "バケットの名前" type = string } variable "project_id" { description = "バケットを作成するプロジェクトの ID" type = string } variable "location" { description = "バケットの場所" type = string } variable "storage_class" { description = "新しいバケットのストレージ クラス" type = string default = null } variable "labels" { description = "バケットに割り当てる Key-Value ラベルペアの集合" type = map(string) default = null } variable "bucket_policy_only" { description = "バケットに対するバケット ポリシーのみのアクセスを有効にする" type = bool default = true } variable "versioning" { description = "true に設定すると、バージョニングがこのバケットで完全に有効になる" type = bool default = true } variable "force_destroy" { description = "バケットを削除する際、含まれているすべてのオブジェクトが削除されるかどうかがこのブール値オプションで決まる。false の場合、Terraform はオブジェクトが含まれているバケットを削除できない。" type = bool default = true } variable "iam_members" { description = "バケットに対するアクセス許可を与える IAM メンバーのリスト" type = list(object({ role = string member = string })) default = [] } variable "retention_policy" { description = "バケット内のオブジェクトをいつまで保持するかに関するバケットのデータ保持ポリシーの構成" type = object({ is_locked = bool retention_period = number }) default = null } variable "encryption" { description = "このバケットに挿入されるオブジェクトの暗号化に使用される Cloud KMS キー" type = object({ default_kms_key_name = string }) default = null } variable "lifecycle_rules" { description = "バケットのライフサイクル ルールの構成" type = list(object({ # キーを持つオブジェクト: # - タイプ - ライフサイクル ルールのアクションのタイプ。サポートされている値: Delete および SetStorageClass # - storage_class - （アクション タイプが SetStorageClass の場合は必須）このライフサイクル ルールの影響を受けるオブジェクトのターゲット ストレージ クラス action = any # キーを持つオブジェクト: # - age - （オプション）この条件を満たすオブジェクトの最短存続期間（日単位） # - created_before - （オプション）この条件を満たすオブジェクトの作成日。RFC 3339 形式（例: 2017-06-13）で指定 # - with_state - （オプション）ライブ オブジェクトとアーカイブ オブジェクトの両方またはどちらかに一致サポートされている値: "LIVE"、"ARCHIVED"、"ANY" # - matches_storage_class - （オプション）この条件を満たすオブジェクトのストレージ クラスサポートされている値: MULTI_REGIONAL、REGIONAL、NEARLINE、COLDLINE、STANDARD、DURABLE_REDUCED_AVAILABILITY # - num_newer_versions - （オプション）バージョニングされたオブジェクトにのみ関連。この条件を満たすオブジェクトのより新しいバージョンの数 condition = any })) default = [] }

7. モジュール内にある outputs.tf ファイルでモジュールへの出力を追加します。

output "bucket" { description = "作成されたストレージ バケット" value = google_storage_bucket.bucket }

変数と同様、モジュールでの出力もルート モジュールの場合と同じ役割を果たしますが、アクセス方法が異なります。モジュールの出力には、モジュール オブジェクトの読み取り専用属性としてアクセスできます。モジュール オブジェクトは、そのモジュールを呼び出す構成内で参照できます。

8. ルート ディレクトリにある main.tf に戻り、新しいモジュールへの参照を追加します。

module "gcs-static-website-bucket" { source = "./modules/gcs-static-website-bucket" name = var.name project_id = var.project_id location = "{{{project_0.default_region | REGION}}}" lifecycle_rules = [{ action = { type = "Delete" } condition = { age = 365 with_state = "ANY" } }] }

9. ルート ディレクトリで、ルート モジュール用の outputs.tf ファイルを作成します。

cd ~ touch outputs.tf

10. この outputs.tf ファイルに次のコードを追加します。

output "bucket-name" { description = "バケット名" value = "module.gcs-static-website-bucket.bucket" }

11. ルート ディレクトリで、variables.tf ファイルを作成します。

touch variables.tf

12. variables.tf ファイルに次のコードを追加します。変数の project_id と name のデフォルトには、プロジェクト ID を設定します。

variable "project_id" { description = "リソースのプロビジョニングを行うプロジェクトの ID" type = string default = "ここにプロジェクト ID を指定" } variable "name" { description = "作成するバケットの名前" type = string default = "ここに（一意の）バケット名を指定" } 注: ストレージ バケットの名前はグローバルに一意でなければなりません。通常は、作者名と日付を使用すると一意のバケット名を作成できます。 プロジェクト ID を使用することもできます。

ローカル モジュールをインストールする

新しいモジュールが構成に追加されるたびに、Terraform はそのモジュールをインストールして使えるようにする必要があります。terraform get と terraform init の両方のコマンドによってモジュールのインストールと更新を行います。terraform init のコマンドは、バックエンドの初期化とプラグインのインストールも行います。

1. モジュールをインストールします。

terraform init

2. バケットをプロビジョニングします。

terraform apply

3. プロンプトに「yes」と入力します。バケットとその他のリソースがプロビジョニングされます。

バケットにファイルをアップロードする

独自のモジュールを構成して使用し、静的ウェブサイトを作成しました。すぐにこの静的ウェブサイトにアクセスしたいところですが、現時点ではバケットが空なので、このウェブサイトには何も表示されません。なんらかのコンテンツを表示するには、バケットにオブジェクトをアップロードする必要があります。www ディレクトリのコンテンツを GitHub リポジトリでアップロードできます。

1. ホーム ディレクトリにサンプル コンテンツをダウンロードします。

cd ~ curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/master/modules/aws-s3-static-website-bucket/www/index.html > index.html curl https://raw.githubusercontent.com/hashicorp/learn-terraform-modules/blob/master/modules/aws-s3-static-website-bucket/www/error.html > error.html

2. これらのファイルをバケットにコピーし、YOUR-BUCKET-NAME の部分をストレージ バケットの名前で置き換えます。

gsutil cp *.html gs://YOUR-BUCKET-NAME

3. ブラウザの新しいタブで、ウェブサイト https://storage.cloud.google.com/YOUR-BUCKET-NAME/index.html（YOUR-BUCKET-NAME の部分はストレージ バケットの名前で置き換える）にアクセスします。

「ここに表示されるものはありません」と書かれた、簡易 HTML のウェブページが表示されます。

[進行状況を確認] をクリックして、目標に沿って進んでいることを確認します。 モジュールを構築する

ウェブサイトとインフラストラクチャをクリーンアップする

最後に、作成したインフラストラクチャを破棄してプロジェクトをクリーンアップします。

1. Terraform リソースを破棄します。

terraform destroy

プロンプトに「yes」と入力すると、このラボで作成したすべてのリソースが Terraform によって破棄されます。

お疲れさまでした

このラボでは、Terraform モジュールの基礎と、Registry にある既存モジュールの使用方法を学習しました。また、Cloud Storage バケットでホスティングされる静的ウェブサイトを作成するための独自モジュールを構築しました。その際には、構成ファイル用の入力、出力、変数を定義し、モジュール構築のベスト プラクティスを学びました。

次のステップと詳細情報

次のリンクから、Terraform に関するその他の実践演習を行うことができます。

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

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

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

マニュアルの最終更新日: 2024 年 1 月 26 日

ラボの最終テスト日: 2023 年 12 月 11 日

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