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

1. Введение в курс CFT 101

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

Что такое Cloud Foundation Toolkit?

По сути, 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 и отправьте запрос на слияние (Pull Request, PR).

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

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

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

Настройка Git

GitHub основан на системе контроля версий с открытым исходным кодом под названием Git. Git отвечает за все, что связано с GitHub и происходит локально на вашем компьютере или в вашей облачной оболочке.

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, чтобы начать вносить свой вклад.

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

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

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

• Создайте форк репозитория.
• Исправьте ошибку.
• Отправьте запрос на слияние (pull request) владельцу проекта.

Шаги для создания форка репозитория CFT:

1. Откройте веб-браузер и перейдите в репозиторий terraform-google-modules/terraform-google-cloud-storage . Мы будем использовать этот репозиторий на протяжении всего Codelab.
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.

При использовании 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 Включение 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. Теперь вам нужно протестировать свою функцию с помощью интеграционного теста Blueprint, написанного на Golang.

Новые тесты следует добавить в файл multiple_buckets_test.go, расположенный в указанной ниже структуре папок:

Вы добавили метку "silly_label" ко всем создаваемым с помощью модуля multiple_buckets корзинам, и теперь вам нужно написать тесты для проверки новой функции.

В приведенном ниже коде вы получаете метку каждого сегмента с помощью команды 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.

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

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

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 , чтобы отобразить список всех тестов Blueprint в вашей рабочей области.

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

[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

Помните: всегда запускайте проверку синтаксиса (lint test), потому что сборка Cloud Build завершится с ошибкой, если проверка не будет завершена. Запускайте её перед отправкой кода в локальный репозиторий.

11. Отправка запроса на слияние (Pull Request) на GitHub.

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

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

Чтобы ваш код стал доступен в главном репозитории, вам необходимо зафиксировать изменения кода в вашей ветке и отправить их в главный репозиторий. Для добавления вашего кода в основной репозиторий, который вы создали в начале Codelab, после фиксации кода в вашем репозитории вам нужно будет отправить запрос на слияние (Pull Request, 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 для создания запроса на слияние (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

Ваши изменения в коде готовы к отправке в виде Pull Request!

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

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

3. Введите заголовок и описание для вашего запроса на слияние, чтобы описать изменения в коде. Будьте максимально конкретны, но при этом лаконичны.

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

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

12. Поздравляем!

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

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

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