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

Cloud Foundation Toolkit 入門ガイド

1. CFT 入門ガイド

最終更新日: 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 リクエスト（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 はユーザー名を使用して commit を ID に関連付けます。Git ユーザー名が GitHub ユーザー名と同じではありません。

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

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] をクリックします。

フォークする場所、プロファイルを選択するオプションが表示されたら、リポジトリをフォークします。

ローカルでフォークのクローンを作成する

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

フォークのクローンを作成する手順:

ウェブブラウザを開き、terraform-google-modules/terraform-google-cloud-storage にあるフォークに移動します。
右上に [コード] が表示されます。クリックします。

[コード]をクリックするとクリックして [コピー] を選択し、アイコンをクリックしてフォークの URL をコピーします。この URL を使用して、フォークのクローンをローカル環境に作成します。

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 APIs を有効にします。

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 に鍵を指定し、値をサービスアカウントキーの contents に設定します。

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 モジュールに新機能を追加する

開発環境とテスト環境のセットアップが完了したので、「silly_label」を追加してみましょう。google-cloud-storage CFT モジュールに追加します。

terraform-google-cloud-storage 内にいることを確認し、以下のフォルダ構造に示すように main.tf ファイルを開きます。

「silly_label」以降特徴を 27 行目の変数「labels」に追加します。以下に示すように、main.tf 内に記述します。

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 行目に追加し、追加する variable ブロックの上と下に改行文字があることを確認します。

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. Storage バケットの例に新しい特徴を追加する

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

「silly_label」example/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 ファイルに新しいテストを追加します。

「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 で統合テストを実行する

統合テスト

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

統合テストは、ブループリントテストフレームワークを使用して記述され、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]

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 出力を取得し、現在の状態が例で宣言されているとおりであることをアサートします。

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

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

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

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

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

ルートモジュール、サブモジュール、サンプルモジュールの README 内の Inputs テーブルと Outputs テーブルは、それぞれのモジュールの 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 で PR を提出する

ローカルでコードを変更し、統合テストでテストしたので、このコードをマスターリポジトリに公開しようと思います。

コードをマスターリポジトリで使用できるようにするには、コードの変更をブランチに commit し、マスターリポジトリに push する必要があります。Codelab の開始時にフォークしたメインリポジトリにコードを追加するには、リポジトリにコードを commit した後にマスターリポジトリで pull リクエスト（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 リクエスト（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

これで、コードを変更して pull リクエストを行う準備が整いました。

次の手順で terraform-google-modules/terraform-google-cloud-storage リポジトリへの PR を作成します。

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

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 入門ガイド

Cloud Foundation Toolkit とは何ですか？

必要なもの

作成するアプリの概要

2. 開発環境の設定

Git を設定する

Git でユーザー名とメールを設定する

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

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

ローカルでフォークのクローンを作成する

これで、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. Storage バケットの例に新しい特徴を追加する

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 で PR を提出する

12. 完了

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

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

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