このページは Cloud Translation API によって翻訳されました。

Cloud Foundation Toolkit 入門ガイド

1. CFT 101 の概要

最終更新日: 2022 年 2 月 11 日

Cloud Foundation Toolkit とは

CFT は、Google Cloud Platform をすぐに使い始めるためのベストプラクティステンプレートを提供します。このチュートリアルでは、Cloud Foundation Toolkit に貢献する方法について説明します。

必要なもの

GitHub アカウント。
マシンに Docker がインストールされているか、Cloud Shell を使用している（Mac のインストール、Windows のインストール）
コードを編集するためのコードエディタ（例: Visual Studio Code）
Git と GitHub に関する基本的な知識
Terraform と Infrastructure as Code に関する一定の経験
サービスアカウントにプロジェクト作成者のロールを付与する権限
Google Cloud 組織、テストフォルダ、請求先アカウント

作成するアプリの概要

この Codelab では、Cloud Foundation Toolkit（CFT）に貢献する方法を学びます。

次のことを行います。

CFT に貢献するための開発環境をセットアップする
CFT モジュールに機能を追加する
追加された機能のテストを追加する
CFT で統合テストを実行する
lint テストを実行する
GitHub にコードを commit して Pull Request（PR）を送信する

上記のすべての手順は、Google Cloud Storage CFT モジュールに新機能を追加することで実行します。"silly_label" というラベルを追加します。このラベルは、GCS CFT モジュールで作成されたすべてのバケットに自動的に追加されます。また、機能を検証し、エンドツーエンドの統合を保証するためのテストを作成します。

2. 開発環境をセットアップする

必要に応じて、開発目的で Cloud Shell を使用できます。CFT への投稿に Cloud Shell を使用しない場合は、マシンに開発環境を設定できます。

Git を設定する

GitHub は、Git と呼ばれるオープンソースのバージョン管理システム（VCS）に基づいています。Git は、マシンまたは Cloud Shell でローカルに発生する GitHub 関連のすべての処理を担当します。

Cloud Shell を使用する場合、git はプリインストールされているため、インストールする必要はありません。

$ git --version
# This will display the git version on the Cloud Shell.

マシンに開発環境をセットアップする場合は、Git をインストールする必要があります。

Git でユーザー名とメールアドレスを設定する

Git はユーザー名を使用して、コミットを ID に関連付けます。Git ユーザー名は GitHub ユーザー名と同じではありません。

git config コマンドを使用して、Git コミットに関連付けられている名前を変更できます。git config を使用して Git コミットに関連付けられた名前を変更しても、今後のコミットにのみ影響し、過去のコミットで使用された名前は変更されません。

Git の設定が完了し、ブランチのフォーク、作成、クローン作成ができるようになります。この Codelab では Git を多用します。

3. CFT の GCS リポジトリをフォークする

CFT リポジトリをフォークする

前の手順で、ローカルマシンまたは Cloud Shell に Git を設定しました。次に、Google Cloud Storage CFT リポジトリをフォークして、投稿を開始する必要があります。

フォークはリポジトリのコピーです。リポジトリをフォークすると、元のプロジェクトに影響を与えることなく、変更を自由に試すことができます。

通常、フォークは、他のユーザーのプロジェクトに変更を提案する場合や、他のユーザーのプロジェクトを自分のアイデアの出発点として使用する場合に使用されます。

たとえば、バグの修正に関連する変更を提案するためにフォークを使用できます。バグを修正するには:

リポジトリをフォークします。
修正を行います。
プロジェクトオーナーに pull リクエストを送信します。

CFT リポジトリをフォークする手順は次のとおりです。

ウェブブラウザを開き、terraform-google-modules/terraform-google-cloud-storage リポジトリに移動します。この Codelab 全体でこのリポジトリを使用します。
ページの右上隅にある [Fork] をクリックします。

フォークする場所のオプションが表示されるので、プロフィールを選択すると、リポジトリがフォークされます。

fork のクローンをローカルに作成する

作成したフォークは、GCS モジュールリポジトリのコピーです。次に、このリポジトリをローカル環境にクローンして、新機能を追加します。

フォークのクローンを作成する手順は次のとおりです。

ウェブブラウザを開き、terraform-google-modules/terraform-google-cloud-storage のフォークに移動します。
右上にある [Code] ボタンをクリックします。

[Code] ボタンをクリックしたら、[Copy] アイコンをクリックしてフォークの URL をコピーします。この URL を使用して、fork をローカル環境に複製します。

VSCode またはマシンのターミナルを開き、フォークのクローンを作成します。

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

フォークのローカルクローンを作成したら、リポジトリに移動し、フォークから新しいブランチを作成して、一時ブランチにコード変更を加えます。

慣例により、ブランチには次のように名前を付けることができます。

機能リクエストの場合: feature/feature-name
内部アップデートの場合: internal/change-name
バグの修正の場合: bugfix/issue-name

新しい機能を追加するので、一時ブランチを feature/silly_label と呼びます。

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

これで、Cloud Foundation Toolkit の作業を開始する準備が整いました。

4. テスト環境を作成する

標準の CFT 開発プロセスは、テストに分離されたテストプロジェクトを使用することを前提としています。このステップでは、サービスアカウントを使用してテストプロジェクト（標準構成に基づく）を作成する手順について説明します。

0. Docker Engine をインストールする

マシンを開発目的で使用する場合は、Docker Engine をインストールする必要があります。

1. Google Cloud SDK をインストールする

GCP の Cloud Shell を使用している場合は、Google Cloud SDK をインストールする必要はありません。

Google Cloud SDK に移動し、お使いのプラットフォーム用のインタラクティブインストーラをダウンロードします。

2. 構成を設定する

テスト環境を作成するには、Google Cloud 組織、テストフォルダ、請求先アカウントが必要です。これらの値は環境変数で設定する必要があります。

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. サービスアカウントを設定する

テスト環境を作成する前に、サービスアカウントキーをテスト環境にダウンロードする必要があります。このサービスアカウントには、プロジェクト作成者、請求先アカウントユーザー、組織閲覧者のロールが必要です。これらの手順では新しいサービスアカウントを作成しますが、既存のアカウントを再利用することもできます。

3.1 シード GCP プロジェクトを作成または選択する

サービスアカウントを作成する前に、サービスアカウントをホストするプロジェクトを選択する必要があります。新しいプロジェクトを作成することもできます。

gcloud config set core/project YOUR_PROJECT_ID

3.2 Google Cloud APIs を有効にする

シードプロジェクトで、次の Google Cloud API を有効にします。

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

3.3 サービスアカウントを作成する

テスト環境を管理する新しいサービスアカウントを作成します。

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

サービスアカウントが作成されたことを確認します。

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

3.4 サービスアカウントにプロジェクト作成者、課金アカウントユーザー、組織閲覧者のロールを付与する:

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

これで、テスト環境の管理に使用できるサービスアカウントが作成されました。

4. Terraform 認証情報を準備する

テスト環境を作成するには、サービスアカウントキーをシェルにダウンロードする必要があります。

4.1 サービスアカウントキー

Terraform のサービスアカウントキーを作成してダウンロードする

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 Terraform 認証情報を設定する

環境変数 SERVICE_ACCOUNT_JSON を使用して Terraform にキーを指定し、値をサービスアカウントキーのコンテンツに設定します。

export SERVICE_ACCOUNT_JSON=$(< cft.json)

認証情報を環境変数に保存したら、キーファイルを削除します。必要に応じて、上記のコマンドを使用して後で鍵を再作成できます。

rm -rf cft.json

5. Terraform デプロイ用のテストプロジェクトを作成する

これで準備が整ったので、1 つのコマンドでテストプロジェクトを作成できます。terraform-google-cloud-storage ディレクトリのルートから次のコマンドを実行します。

make docker_test_prepare

make docker_test_prepare を実行すると、次の出力が表示されます。最後に、作成されたテストプロジェクトの project_id が返されます。このプロジェクトに、新しい機能を使用して Cloud Storage モジュールをデプロイしてテストします。請求先アカウントのリンクで問題が発生した場合は、トラブルシューティングの手順をご覧ください。

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

これで、コンソール出力に表示されているように、project_id で参照されるテストプロジェクトが作成されました。開発環境とテスト環境が設定されている。

5. CFT モジュールに新しい機能を追加する

開発環境とテスト環境が設定されたので、google-cloud-storage CFT モジュールに silly_label 機能を追加しましょう。

terraform-google-cloud-storage に移動し、フォルダ構造で以下に示すように main.tf ファイルを開きます。

「silly_label」はラベルであるため、次の例に示すように、main.tf の変数「labels」の 27 行目に機能を追加します。

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

次に、上記のフォルダ構造に示されている variables.tf に silly_label 変数を追加します。

次のコードをコピーして variables.tf の 31 行目に追加します。追加する変数ブロックの上下に改行文字があることを確認してください。

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6. ストレージバケットの例に新しい機能を追加

モジュールの main.tf に機能を追加したので、例を通して追加した機能をテストします。

「silly_label」を examples/multiple-buckets/main.tf に追加する必要があります。

この例は、次のステップで統合テストを実行するために使用されます。

次の変数 silly_label 行をコピーして、フォルダ構造に示されているように、terraform-google-cloud-storage/examples/multiple-buckets/ の main.tf の 27 行目に貼り付けます。

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. ブループリントテストを更新して機能をチェック

モジュールの main.tf に機能を追加し、multiple_buckets の例に機能を追加しました。次に、Golang で記述されたブループリント統合テストを使用して、機能をテストする必要があります。

新しいテストは、次のフォルダ構造にある multiple_buckets_test.go ファイルに追加します。

multiple_buckets モジュールで作成されるすべてのバケットに「silly_label」を追加しました。新しい機能をテストするためのテストを作成する必要があります。

次のコードでは、gcloud alpha storage コマンドを使用して各バケットのラベルを取得し、コマンドから返された出力を確認しています。

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. CFT で統合テストを実行する

統合テスト

統合テストは、ルートモジュール、サブモジュール、サンプルの動作を検証するために使用されます。追加、変更、修正にはテストを伴う必要があります。

統合テストは blueprint テストフレームワークを使用して記述され、CFT CLI を使用して実行されます。これらのツールは、便宜上 Docker イメージ内にパッケージ化されています。

これらのテストの一般的な戦略は、サンプルモジュールの動作を検証し、ルートモジュール、サブモジュール、サンプルモジュールがすべて機能的に正しいことを確認することです。

インタラクティブ実行では、複数のコマンドを使用して各ステップを実行します。

make docker_run を実行して、テスト用 Docker コンテナをインタラクティブモードで起動します。

Make は、実行可能プログラムとライブラリをソースコードから自動的にビルドするビルド自動化ツールです。ターゲットプログラムの導出方法を指定する Makefile というファイルを読み取ってビルドします。ファイルに変更を加えた場合は、Docker コンテナが自動的に更新される必要があります。

make docker_run を実行すると、Docker コンテナにワークスペースが作成され、サービスアカウントの認証情報が有効になります。このワークスペースは、次のステップでテストを実行するために使用します。

ターミナルに次の出力が表示されます。

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

module-swapper -registry-prefix=terraform-google-modules を実行して、公開されたモジュールではなくローカルファイルからモジュールをインポートするように、サンプル main.tf ファイルを調整します。

ターミナルに次のような出力が表示されます。

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules
2025/08/04 19:26:29 Module name set from remote to cloud-storage
2025/08/04 19:26:29 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:26:29 --- Original
+++ Modified
@@ -21,7 +21,7 @@
 }
 
 module "cloud_storage" {
-  source = "terraform-google-modules/cloud-storage/google"
+  source = "../.."
   # [restore-marker]   version = "~> 10.0"
 
   project_id = var.project_id

cft test list を実行して、ワークスペース内のすべてのブループリントテストを一覧表示します。

ターミナルに次の出力が表示されます。

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go

cft test run <EXAMPLE_NAME> --stage init を実行して、サンプルを初期化します。この場合、TestMultipleBuckets テスト実行を初期化するには、cft test run TestMultipleBuckets --stage init を使用します。また、テストの実行時に --verbose フラグを使用して追加情報を取得することもできます。

この init ステージでは、Terraform の例を初期化します。

ターミナルに次の出力が表示されます。

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)

cft test run <EXAMPLE_NAME> --stage apply を実行して、サンプルモジュールを適用します。

この手順では、前のステージで初期化された例を、Codelab の前半で作成した GCP プロジェクトに適用します。

ターミナルに次の出力が表示されます。

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s

cft test run <EXAMPLE_NAME> --stage verify を実行して、作成された例が想定どおりのインフラストラクチャであることを確認します。

このステップでは、TestMultipleBuckets の検証関数が実行されます。通常、検証は gcloud コマンドを実行してリソースの現在の状態の JSON 出力を取得し、現在の状態が例で宣言されているとおりであることをアサートすることで行われます。

エラーが発生した場合は、テストのコマンドで想定された内容と受信した内容が表示されます。

ターミナルに次の出力が表示されます。

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s

cft test run <EXAMPLE_NAME> --stage teardown を実行して、サンプルを破棄します。

このステップでは、上記の手順で作成したインフラストラクチャを破棄します。この手順では、プロジェクトで作成された GCS バケットと、GCS モジュールに追加したラベルも破棄されます。

ターミナルで次の出力を確認できます。

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s

module-swapper -registry-prefix=terraform-google-modules -restore を実行して、前回 module-swapper を実行したときにサンプル main.tf ファイルに加えた調整を元に戻します。

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules -restore
2025/08/04 19:30:41 Module name set from remote to cloud-storage
2025/08/04 19:36:32 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:36:32 --- Original
+++ Modified
@@ -21,8 +21,8 @@
 }
 
 module "cloud_storage" {
-  source = "../.."
-   version = "~> 10.0"
+  source  = "terraform-google-modules/cloud-storage/google"
+  version = "~> 10.0"
 
   project_id = var.project_id

exit を実行して、テストコンテナを終了します。

9. 入力と出力のドキュメントを生成する

ルートモジュール、サブモジュール、サンプルモジュールの README の入力テーブルと出力テーブルは、それぞれのモジュールの variables と outputs に基づいて自動的に生成されます。モジュールインターフェースが変更された場合は、これらのテーブルを更新する必要があります。

次のコマンドを実行します。

make generate_docs
# This will generate new Inputs and Outputs tables

10. CFT で lint テストを実行する

リンターは、ソースコードを分析して、プログラミングエラー、バグ、スタイルエラー、疑わしい構造にフラグを設定するツールです。

リポジトリ内の多くのファイルは、品質基準を維持するために lint またはフォーマットできます。CFT の品質を確保するには、lint テストを使用します。

次のコマンドを実行します。

make docker_test_lint
# This will run all lint tests on your repo

11. Github での Pull Request の送信

コードをローカルで変更し、インテグレーションテストでテストしたので、このコードをマスターリポジトリに公開します。

コードをマスターリポジトリで使用できるようにするには、コードの変更をブランチに commit し、マスターリポジトリに push する必要があります。Codelab の開始時にフォークしたメインリポジトリにコードを追加するには、リポジトリにコードを commit した後、マスターリポジトリでプルリクエスト（PR）を送信します。

PR を作成すると、リポジトリ管理者に通知が届き、提案されたコード変更が審査されます。また、他のユーザーをレビュー担当者として追加して、コード変更に関するフィードバックを得ることもできます。PR は Cloud Build をトリガーし、リポジトリでテストを実行します。

コードの変更に基づいて、コードレビュー担当者がコードにコメントを付け、ベストプラクティスとドキュメントに基づいて変更が必要な場合は変更を求めます。管理者はコードの変更を審査し、コードがリポジトリに準拠していることを確認します。コードをマスターリポジトリにマージする前に、変更を再度リクエストされることもあります。

次の手順に沿って、コードをフォークしたブランチに commit し、フォークしたブランチに push します。

まず、変更されたファイルをローカルリポジトリに追加します。

$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE

ファイルがステージングされたので、次に変更を commit します。

$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.

ローカルリポジトリで commit した変更を GitHub に push して、Pull Request（PR）を作成します。

$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

これで、コードの変更をプルリクエストの準備ができました。

次の手順に沿って、terraform-google-modules/terraform-google-cloud-storage リポジトリに PR を作成します。

ウェブブラウザで、repoのメインページに移動します。
フォークから PR を開くための提案がバナーに表示されます。[Compare and pull request] をクリックします。

pull リクエストのタイトルと説明を入力して、コードの変更内容を説明します。簡潔に、できるだけ具体的に説明します。

レビューの準備ができた pull リクエストを作成するには、[Create Pull Request] をクリックします。
PR によってトリガーされた Cloud Build トリガーが実行されていることがわかります。
問題が発生した場合は、フォークから pull リクエストを開くに関する GitHub の公式ドキュメントを参照してください。

最初のコード変更をフォークされたブランチに push し、マスターブランチに対して最初の CFT PR を作成しました。

12. 完了

これで、CFT モジュールに機能を追加し、レビュー用に PR を送信できました。

CFT モジュールに機能を追加し、例を使用してローカルでテストし、GitHub にコードを commit する前にテストを実行しました。最後に、レビュー用の PR を作成し、CFT に最終的にマージしました。

Cloud Foundation Toolkit を使い始めるための重要な手順を理解しました。

Cloud Foundation Toolkit 入門ガイド コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

1. CFT 101 の概要

Cloud Foundation Toolkit とは

必要なもの

作成するアプリの概要

2. 開発環境をセットアップする

Git を設定する

Git でユーザー名とメールアドレスを設定する

3. CFT の GCS リポジトリをフォークする

CFT リポジトリをフォークする

fork のクローンをローカルに作成する

これで、Cloud Foundation Toolkit の作業を開始する準備が整いました。

4. テスト環境を作成する

0. Docker Engine をインストールする

1. Google Cloud SDK をインストールする

2. 構成を設定する

3. サービス アカウントを設定する

4. Terraform 認証情報を準備する

5. Terraform デプロイ用のテスト プロジェクトを作成する

5. CFT モジュールに新しい機能を追加する

terraform-google-cloud-storage/main.tf

terraform-google-cloud-storage/variables.tf

6. ストレージ バケットの例に新しい機能を追加

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

7. ブループリント テストを更新して機能をチェック

test/integration/multiple_buckets/multiple_buckets_test.go

8. CFT で統合テストを実行する

統合テスト

9. 入力と出力のドキュメントを生成する

10. CFT で lint テストを実行する

11. Github での Pull Request の送信

12. 完了

Cloud Foundation Toolkit 入門ガイド

3. サービスアカウントを設定する

5. Terraform デプロイ用のテストプロジェクトを作成する

6. ストレージバケットの例に新しい機能を追加

7. ブループリントテストを更新して機能をチェック