Набор инструментов Cloud Foundation 101

1. Введение в CFT 101

Последнее обновление: 11.02.2022

Что такое набор инструментов Cloud Foundation?

По сути, CFT предоставляет шаблоны, основанные на передовых практиках, для быстрого начала работы с Google Cloud Platform. В этом руководстве вы узнаете, как внести свой вклад в Cloud Foundation Toolkit.

Что вам понадобится

• Аккаунт GitHub.
• Установите Docker на свой компьютер или используйте Cloud Shell ( установка на Mac , установка на Windows )
• Редактор кода для редактирования кода (пример: Visual Studio Code )
• Базовые знания Git и GitHub
• Некоторый опыт работы с Terraform и инфраструктурой как кодом
• Разрешение на предоставление роли создателя проекта учетной записи службы
• Организация Google Cloud, тестовая папка и платежный аккаунт

Что вы построите

В этой лабораторной работе вы узнаете, как внести свой вклад в Cloud Foundation Toolkit (CFT).

Вы будете:

• Настройте среду разработки для участия в CFT
• Добавить функцию в модуль CFT
• Добавить тесты для добавленной функции
• Выполнение интеграционных тестов в CFT
• Выполнение линтинг-тестов
• Зафиксируйте код на GitHub и отправьте запрос на извлечение (PR)

Вы выполните все вышеперечисленные шаги, добавив новую функцию в модуль Google Cloud Storage CFT . Вам нужно будет добавить метку "silly_label" , которая будет автоматически добавляться ко всем контейнерам, созданным через модуль GCS CFT. Вы также сможете написать тесты для проверки вашей функции и обеспечения сквозной интеграции.

2. Настройка среды разработки

При желании вы можете использовать Cloud Shell для разработки. Если вы не хотите использовать Cloud Shell для работы с CFT, вы можете настроить среду разработки на своём компьютере.

Настроить Git

GitHub основан на системе управления версиями (VCS) с открытым исходным кодом Git. Git отвечает за всё, что связано с GitHub и происходит локально на вашем компьютере или в Cloud Shell.

1. При использовании Cloud Shell вам не нужно устанавливать git, так как он предустановлен.

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

Если вы настраиваете среду разработки на своем компьютере, вам необходимо установить Git.

Загрузите и установите последнюю версию Git

Настройка имени пользователя и адреса электронной почты в Git

Git использует имя пользователя для связывания коммитов с личностью. Имя пользователя Git не совпадает с вашим именем пользователя GitHub.

Вы можете изменить имя, связанное с вашими коммитами Git, с помощью команды git config. Изменение имени, связанного с вашими коммитами Git, с помощью git config повлияет только на будущие коммиты и не изменит имя, используемое для предыдущих коммитов.

Установка имени пользователя Git для каждого репозитория на вашем компьютере

Для Mac/Linux: откройте терминал.

Для Windows: Откройте Git Bash

Задайте имя пользователя Git:

$ git config --global user.name "Your Name"

$ git config --global user.email "[e-mail]"

Убедитесь, что вы правильно установили имя пользователя Git:

$ git config --list

> Your Name

> Your Email

Вы успешно настроили Git и теперь можете создавать, клонировать и создавать ветки. В этой лабораторной работе мы будем активно использовать Git.

3. Форк репозитория GCS CFT

Форк репозитория CFT

Вы настроили Git на локальном компьютере или в Cloud Shell на предыдущем этапе. Теперь вам нужно создать форк репозитория Google Cloud Storage CFT, чтобы начать вносить свой вклад.

Форк — это копия репозитория. Форк репозитория позволяет свободно экспериментировать с изменениями, не затрагивая исходный проект.

Чаще всего форки используются либо для предложения изменений в чужой проект, либо для использования чужого проекта в качестве отправной точки для своей собственной идеи.

Например, вы можете использовать форки, чтобы предложить изменения, связанные с исправлением ошибки. Чтобы исправить ошибку, вы можете:

• Создайте форк репозитория.
• Исправьте ситуацию.
• Отправьте запрос на извлечение владельцу проекта.

Шаги для разветвления CFT-репо:

1. Откройте веб-браузер и перейдите в репозиторий terraform-google-modules/terraform-google-cloud-storage . Мы будем использовать этот репозиторий для всей этой лабораторной работы.
2. В правом верхнем углу страницы нажмите кнопку Fork .

3. Вам будет предложено выбрать, где вы хотите провести форк, выберите свой профиль, и репозиторий будет форкнут.

Клонируйте свою вилку локально

Созданный вами форк — это копия репозитория модулей GCS. Теперь вам нужно клонировать этот репозиторий в свою локальную среду, чтобы добавить новую функцию.

Шаги по клонированию вашей вилки:

1. Откройте веб-браузер и перейдите к вашей ветке terraform-google-modules/terraform-google-cloud-storage .
2. В правом верхнем углу вы найдете кнопку «Код», нажмите на нее.

3. После нажатия кнопки «Код» нажмите значок «Копировать», чтобы скопировать URL-адрес форка. Этот URL-адрес понадобится вам для клонирования форка в локальной среде.

4. Перейдите в терминал в VSCode или на свой компьютер и клонируйте форк.

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

5. Теперь, когда вы клонировали свою ветку локально, вам следует зайти в свой репозиторий, создать новую ветку от ветки и внести изменения в код во временную ветку.

По соглашению вы можете назвать свою ветку следующим образом:

• Для запросов функций: 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 .

Примечание: если вы используете Cloud Shell, вам не нужно устанавливать Docker, так как в Cloud Shell он уже есть.

1. Установите Google Cloud SDK

Вам не нужно устанавливать Google Cloud SDK, если вы используете GCP Cloud Shell .

Перейдите в 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 Включение API Google Cloud

Включите следующие API Google Cloud в вашем начальном проекте:

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

Предоставьте ключ Terraform, используя переменную среды SERVICE_ACCOUNT_JSON , установив значение на содержимое ключа вашей учетной записи службы.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

После сохранения учётной информации в переменной окружения удалите ключевой файл. При необходимости вы сможете создать ключ заново, используя ту же команду, что и выше.

rm -rf cft.json

5. Создайте тестовый проект для развертываний Terraform.

Теперь, когда всё подготовлено, вы можете создать тестовый проект одной командой. Выполните её из корня каталога 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» в модуль CFT google-cloud-storage.

Убедитесь, что вы находитесь в 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(
 <...>
}

Теперь вам нужно добавить переменную silly_label в файл variables.tf, который вы видите в приведенной выше структуре папок.

Скопируйте и вставьте приведенный ниже код и добавьте его в строку 31 в variables.tf, убедившись, что над и под добавляемым вами блоком переменной есть символ новой строки.

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 в строку 27 в файле main.tf в terraform-google-cloud-storage/examples/multiple-buckets/, как показано в структуре папок:

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» для всех контейнеров, создаваемых с помощью модуля multiple_buckets, и теперь вам нужно написать тесты для проверки новой функции.

В приведенном ниже коде вы получаете метку каждого контейнера с помощью команды gcloud alpha storage, а затем проверяете возвращаемый командой вывод.

тест/интеграция/множественные_бакеты/множественные_бакеты_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 Test Framework и запускаются с помощью CFT CLI . Для удобства эти инструменты упакованы в образ Docker.

Общая стратегия этих тестов заключается в проверке поведения примеров модулей , что позволяет гарантировать функциональную корректность корневого модуля, подмодулей и примеров модулей.

При интерактивном выполнении вы выполняете каждый шаг с помощью нескольких команд.

1. Запустите make docker_run , чтобы запустить тестовый Docker-контейнер в интерактивном режиме.

Make — это инструмент автоматизации сборки, который автоматически собирает исполняемые программы и библиотеки из исходного кода, считывая файлы Makefile , которые определяют, как получить целевую программу. При внесении изменений в файлы Docker-контейнер должен автоматически обновляться.

При запуске команды make docker_run вы создаёте рабочее пространство в контейнере Docker и активируете учётные данные вашей учётной записи службы. Это рабочее пространство будет использоваться на следующих этапах для запуска тестов.

В вашем терминале вы увидите следующий вывод:

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

2. Запустите 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

3. Запустите 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 

4. Выполните cft test run <EXAMPLE_NAME> --stage init для инициализации примера. В данном случае для инициализации тестового запуска TestMultipleBuckets cft test run TestMultipleBuckets --stage init . Вы также можете использовать флаг --verbose для получения дополнительной информации при запуске тестов.

На этом этапе инициализируется пример 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)

Примечание: в журналах могут появляться предупреждения, например Skipping fixtures discovery . Эти предупреждения предназначены для отладки и могут быть проигнорированы. Обнаруженные ошибки приведут к провалу теста.

5. Запустите cft test run <EXAMPLE_NAME> --stage apply , чтобы применить пример модуля.

На этом этапе пример, инициализированный на предыдущем этапе, применяется к проекту GCP, созданному ранее в Codelab.

Вы увидите в терминале следующий вывод.

[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

Примечание: Если в журналах вы видите Request violates constraint 'constraints/storage.uniformBucketLevelAccess' , это означает, что в вашем проекте запрещено устанавливать uniform_bucket_level_access в значение false. В этой практической работе вы можете обойти это, установив cloud_storage.bucket_policy_only["two"] в true вместо false и соответствующим образом изменив тест golang.

6. Запустите 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

7. Запустите 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

8. Запустите module-swapper -registry-prefix=terraform-google-modules -restore чтобы отменить изменения в файлах примеров main.tf , внесенные при последнем запуске module-swapper .

[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
 

9. Выполните exit , чтобы выйти из тестового контейнера.

9. Создание документации для входов и выходов

Таблицы «Входы» и «Выходы» в файлах README корневого модуля, подмодулей и модулей-примеров автоматически генерируются на основе variables и outputs соответствующих модулей. Эти таблицы необходимо обновлять при изменении интерфейсов модулей.

Бегать:

make generate_docs
# This will generate new Inputs and Outputs tables

Помните: всегда запускайте generate_docs , чтобы убедиться, что вся документация полна.

10. Выполнение линтинг-тестов в CFT

Линтер — это инструмент, который анализирует исходный код для выявления ошибок программирования, багов, стилистических ошибок и подозрительных конструкций.

Многие файлы в репозитории можно подвергнуть линтингу или форматированию для поддержания стандарта качества. Для обеспечения качества в CFT используется линтинг-тест.

Бегать:

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

Помните: всегда запускайте линтинг, так как сборка Cloud Build завершится ошибкой, если линтинг не будет завершён. Выполняйте его перед публикацией кода в локальном репозитории.

11. Отправка запроса на включение изменений на Github

Примечание: На этом этапе кодлаб завершен. Мы рекомендуем вам создавать запрос на извлечение только тем, кто впервые работает с GitHub и хочет изучить процесс.

Теперь, когда вы изменили свой код локально и протестировали его с помощью интеграционных тестов, вам нужно опубликовать этот код в главном репозитории.

Чтобы ваш код стал доступен в главном репозитории, вам необходимо закоммитить изменения в коде в вашей ветке и отправить их в главный репозиторий. Чтобы ваш код был добавлен в основной репозиторий, созданный в начале Codelab, вам необходимо создать запрос на извлечение (Pull Request, PR) в главном репозитории после коммита кода в ваш репозиторий.

Когда вы отправляете запрос на вынос (PR), администратор репозитория получает уведомление о необходимости проверить предлагаемые изменения кода. Кроме того, вы можете добавить других пользователей в качестве рецензентов для получения отзывов об изменениях кода. PR запускает сборку Cloud Build, которая запускает тестирование репозитория.

На основе изменений в вашем коде рецензенты предоставят комментарии и попросят внести изменения, если что-то необходимо изменить в соответствии с лучшими практиками и документацией. Администратор проверит изменения в вашем коде, убедится в его соответствии требованиям репозитория и может снова попросить вас внести некоторые изменения перед слиянием кода с основным репозиторием.

Выполните следующие шаги, чтобы зафиксировать код в вашей ответвленной ветке и отправить код в вашу ответвленную ветку:

1. Первый шаг — добавить измененные файлы в локальный репозиторий.

$ 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

2. Теперь ваши файлы подготовлены, теперь вам нужно зафиксировать изменения.

$ 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.

3. Отправьте зафиксированные изменения в локальном репозитории на GitHub для создания запроса на извлечение (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

Ваши изменения в коде теперь готовы к запросу на извлечение!

Выполните следующие шаги для создания PR в репозитории terraform-google-modules/terraform-google-cloud-storage :

1. В веб-браузере перейдите на главную страницу репозитория .
2. Вы увидите баннер с предложением открыть пулл-реквест из вашего форка. Нажмите «Сравнить и сделать пулл-реквест».

3. Введите заголовок и описание запроса на включение изменений в код. Опишите изменения в коде максимально конкретно, но лаконично.

4. Чтобы создать запрос на извлечение, готовый к рассмотрению, нажмите «Создать запрос на извлечение».
5. Вы увидите запущенные триггеры Cloud Build, которые срабатывают из-за PR.
6. Если у вас возникли какие-либо проблемы, обратитесь к официальной документации GitHub по открытию запросов на извлечение из форков .

Вы успешно отправили первое изменение кода в свою ответвленную ветку и получили первый CFT PR против главной ветки!

12. Поздравления

Поздравляем, вы успешно добавили функцию в модуль CFT и отправили PR на рассмотрение!

Вы добавили функцию в модуль CFT, протестировали её локально на примере и провели тестирование перед публикацией кода на GitHub. Наконец, вы отправили запрос на пул-реквест (PR) для проверки и окончательного слияния с CFT.

Теперь вы знаете важные шаги для начала работы с Cloud Foundation Toolkit.