このページは 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 リクエスト（PR）を送信する

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

2. 開発環境を設定する

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

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 コミットに関連付けられている名前は、git config コマンドを使用して変更できます。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] をクリックします。

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

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

作成したフォークは、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 にキーを指定し、値をサービスアカウントキーの内容に設定します。

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 が表示されます。この 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 の行 27 の「labels」変数に特徴を追加します。

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 に追加する必要があります。

この例は、次のステップでインテグレーションテストを実施するために使用します。

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

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

統合テスト

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

統合テストはブループリントテストフレームワークを使用して記述され、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 で verify 関数を実行します。通常、検証は 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 の [入力と出力] テーブルは、各モジュールの 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

これで、コードの変更をプルリクエストに送信できるようになりました。

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

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

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

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

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

12. 完了

これで、CFT モジュールに機能を追加し、審査のために PR を送信できました。

CFT モジュールに機能を追加し、サンプルでローカルでテストし、テストを実行してから GitHub にコードを commit しました。最後に、レビューと CFT への最終的な統合のために PR を送信します。

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

Cloud Foundation Toolkit 入門ガイド

1. CFT 101 の概要

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. ストレージ バケットの例に新しい機能を追加。

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 デプロイ用のテストプロジェクトを作成する

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

7. 機能をチェックするようにブループリントテストを更新