Poradnik Cloud Foundation Toolkit

1. Wprowadzenie do CFT 101

Ostatnia aktualizacja: 11.02.2022

Co to jest Cloud Foundation Toolkit?

CFT udostępnia szablony oparte na sprawdzonych metodach, które umożliwiają szybkie rozpoczęcie pracy w Google Cloud Platform. Z tego samouczka dowiesz się, jak współtworzyć Cloud Foundation Toolkit.

Czego potrzebujesz

• Konto GitHub.
• Docker zainstalowany na komputerze lub Cloud Shell ( instalacja na Macu, instalacja w systemie Windows)
• Edytor kodu do edytowania kodu (np. Visual Studio Code)
• Podstawowa znajomość Git i GitHub
• Znajomość Terraform i infrastruktury jako kodu
• Uprawnienia do przypisania roli Twórca projektu do konta usługi
• organizacja Google Cloud, folder testowy i konto rozliczeniowe;

Co utworzysz

Z tego przewodnika dowiesz się, jak współtworzyć Cloud Foundation Toolkit (CFT).

W ramach ćwiczenia:

• Konfigurowanie środowiska programistycznego do współtworzenia CFT
• Dodawanie funkcji do modułu CFT
• Dodawanie testów dla dodanej funkcji
• Przeprowadzanie testów integracji w CFT
• Przeprowadzanie testów lint
• Zatwierdzanie kodu w GitHubie i przesyłanie żądania pull

Wszystkie powyższe kroki wykonasz, dodając nową funkcję do modułu CFT Google Cloud Storage. Dodasz etykietę o nazwie "silly_label", która będzie automatycznie dodawana do wszystkich zasobników utworzonych za pomocą modułu GCS CFT. Będziesz też pisać testy, aby sprawdzić działanie funkcji i zapewnić integrację kompleksową.

2. Konfigurowanie środowiska programistycznego

Jeśli chcesz, możesz używać Cloud Shell do celów programistycznych. Jeśli nie chcesz używać Cloud Shell do współtworzenia CFT, możesz skonfigurować środowisko programistyczne na swoim komputerze.

Konfigurowanie Git

GitHub opiera się na systemie kontroli wersji (VCS) o nazwie Git, który jest dostępny na licencji open source. Git odpowiada za wszystko, co jest związane z GitHubem i dzieje się lokalnie na Twoim komputerze lub w Cloud Shell.

1. Jeśli korzystasz z Cloud Shell, nie musisz instalować Gita, ponieważ jest on już zainstalowany.

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

Jeśli konfigurujesz środowisko deweloperskie na swoim komputerze, musisz zainstalować Git.

Pobierz i zainstaluj najnowszą wersję Gita

Ustawianie nazwy użytkownika i adresu e-mail w Git

Git używa nazwy użytkownika do powiązania zatwierdzeń z tożsamością. Nazwa użytkownika Git jest inna niż nazwa użytkownika GitHub.

Możesz zmienić nazwę powiązaną z zatwierdzeniami Git za pomocą polecenia git config. Zmiana nazwy powiązanej z zatwierdzeniami Git za pomocą git config będzie miała wpływ tylko na przyszłe zatwierdzenia i nie zmieni nazwy używanej w przypadku poprzednich zatwierdzeń.

Ustawianie nazwy użytkownika Git dla każdego repozytorium na komputerze

W systemach Mac/Linux: otwórz terminal.

W systemie Windows: otwórz Git Bash.

Ustaw nazwę użytkownika Git:

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

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

Sprawdź, czy nazwa użytkownika Git jest prawidłowa:

$ git config --list

> Your Name

> Your Email

Git został skonfigurowany. Powinno być możliwe rozwidlanie, tworzenie i klonowanie gałęzi. W tym laboratorium będziemy intensywnie korzystać z Gita.

3. Utwórz rozwidlenie repozytorium GCS zespołu CFT

Tworzenie rozwidlenia repozytorium CFT

W poprzednim kroku skonfigurowano Git na komputerze lokalnym lub w Cloud Shell. Aby zacząć współtworzyć, musisz teraz rozwidlić repozytorium CFT Google Cloud Storage.

Fork to kopia repozytorium. Rozwidlenie repozytorium umożliwia swobodne eksperymentowanie ze zmianami bez wpływu na oryginalny projekt.

Forks są najczęściej używane do proponowania zmian w projekcie innej osoby lub do wykorzystania projektu innej osoby jako punktu wyjścia dla własnego pomysłu.

Możesz na przykład użyć rozwidlenia, aby zaproponować zmiany związane z naprawieniem błędu. Aby naprawić błąd:

• Utwórz rozwidlenie repozytorium.
• Wprowadź poprawkę.
• Prześlij prośbę o scalenie do właściciela projektu.

Instrukcje dotyczące rozwidlenia repozytorium CFT:

1. Otwórz przeglądarkę i przejdź do repozytorium terraform-google-modules/terraform-google-cloud-storage. Będziemy używać tego repozytorium przez całe ćwiczenie z programowania.
2. W prawym górnym rogu strony kliknij Utwórz rozwidlenie.

3. Pojawi się opcja wyboru miejsca, w którym chcesz utworzyć fork. Wybierz swój profil, a repozytorium zostanie rozwidlone.

Sklonuj swój fork lokalnie

Utworzony przez Ciebie fork jest kopią repozytorium modułu GCS. Teraz sklonuj to repozytorium do środowiska lokalnego, aby dodać nową funkcję.

Instrukcje klonowania forka:

1. Otwórz przeglądarkę i przejdź do swojego rozwidlenia w terraform-google-modules/terraform-google-cloud-storage.
2. W prawym górnym rogu znajdziesz przycisk „Code” (Kod). Kliknij go.

3. Po kliknięciu przycisku „Code” (Kod) kliknij ikonę „Copy” (Kopiuj), aby skopiować adres URL rozwidlenia. Użyjesz tego adresu URL, aby sklonować rozwidlenie do środowiska lokalnego.

4. Otwórz terminal w VSCode lub na komputerze i sklonuj fork.

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

5. Po sklonowaniu forka lokalnie przejdź do repozytorium, utwórz nową gałąź z forka i wprowadź zmiany w kodzie w gałęzi tymczasowej.

Zgodnie z konwencją możesz nazwać gałąź w ten sposób:

• W przypadku próśb o dodanie funkcji: feature/feature-name
• W przypadku aktualizacji wewnętrznych internal/change-name
• Poprawki błędów: bugfix/issue-name

Ponieważ dodajesz nową funkcję, możesz nazwać tymczasową gałąź 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"

Możesz już zacząć pracę z zestawem narzędzi Cloud Foundation.

4. Tworzenie środowiska testowego

Standardowy proces tworzenia CFT opiera się na używaniu odizolowanego projektu testowego do testowania. W tym kroku dowiesz się, jak utworzyć projekt testowy (na podstawie standardowej konfiguracji) za pomocą konta usługi.

0. Zainstaluj Docker Engine

Jeśli używasz komputera do celów programistycznych, musisz zainstalować Docker Engine.

Uwaga: jeśli używasz Cloud Shell, nie musisz instalować Dockera, ponieważ jest on już dostępny w Cloud Shell.

1. Zainstaluj pakiet SDK Google Cloud

Jeśli korzystasz z Cloud Shell w GCP, nie musisz instalować pakietu Google Cloud SDK.

Otwórz stronę Google Cloud SDK i pobierz interaktywny instalator dla swojej platformy.

2. Skonfiguruj

Aby utworzyć środowisko testowe, musisz mieć organizację Google Cloud, folder testowy i konto rozliczeniowe. Te wartości należy ustawić za pomocą zmiennych środowiskowych:

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. Konfigurowanie konta usługi

Przed utworzeniem środowiska testowego musisz pobrać do niego klucz konta usługi. To konto usługi będzie wymagać ról twórca projektu, użytkownik konta rozliczeniowego i wyświetlający organizację. Te czynności pomogą Ci utworzyć nowe konto usługi, ale możesz też użyć ponownie istniejącego konta.

3.1 Tworzenie lub wybieranie projektu GCP

Przed utworzeniem konta usługi musisz wybrać projekt, w którym będzie ono hostowane. Możesz też utworzyć nowy projekt.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Włącz interfejsy Google Cloud API

Włącz w projekcie początkowym te interfejsy Google Cloud API:

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

3.3 Tworzenie konta usługi

Utwórz nowe konto usługi do zarządzania środowiskiem testowym:

# 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

Sprawdź, czy konto usługi zostało utworzone:

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

3.4. Przyznaj kontu usługi role Twórca projektu, Użytkownik konta rozliczeniowego i Wyświetlający organizację:

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"

Masz teraz konto usługi, którego możesz używać do zarządzania środowiskiem testowym.

4. Przygotowywanie danych logowania Terraform

Aby utworzyć środowisko testowe, musisz pobrać klucz konta usługi do powłoki.

4.1 Klucz konta usługi

Tworzenie i pobieranie klucza konta usługi dla Terraform

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

4.2 Konfigurowanie danych logowania Terraform

Przekaż klucz do Terraform za pomocą zmiennej środowiskowej SERVICE_ACCOUNT_JSON, ustawiając wartość na zawartość klucza konta usługi.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Po zapisaniu informacji o danych logowania w zmiennej środowiskowej usuń plik klucza. W razie potrzeby możesz później ponownie utworzyć klucz, używając tego samego polecenia co powyżej.

rm -rf cft.json

5. Tworzenie projektu testowego na potrzeby wdrożeń Terraform

Gdy wszystko będzie gotowe, możesz utworzyć projekt testowy za pomocą jednego polecenia. Uruchom to polecenie w katalogu głównym terraform-google-cloud-storage:

make docker_test_prepare

Po uruchomieniu polecenia make docker_test_prepare zobaczysz poniższe dane wyjściowe. Na końcu otrzymasz identyfikator utworzonego projektu testowego , w którym możesz wdrożyć i przetestować moduł Cloud Storage z nową funkcją. Jeśli masz problemy z połączeniem konta rozliczeniowego, zapoznaj się z instrukcjami rozwiązywania problemów.

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.

Utworzyliśmy projekt testowy, do którego odwołuje się identyfikator project_id widoczny w danych wyjściowych konsoli. Środowisko programistyczne i testowe jest skonfigurowane.

5. Dodawanie nowej funkcji do modułu CFT

Środowisko deweloperskie i testowe zostało skonfigurowane. Zacznijmy dodawać funkcję „silly_label” do modułu CFT google-cloud-storage.

Upewnij się, że jesteś w folderze terraform-google-cloud-storage, i otwórz plik main.tf, jak widać poniżej w strukturze folderów.

Ponieważ „silly_label” jest etykietą, dodasz funkcję w wierszu 27 w zmiennej „labels” w pliku main.tf, jak widać poniżej:

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(
 <...>
}

Teraz dodasz zmienną silly_label w pliku variables.tf, który widzisz w strukturze folderów powyżej.

Skopiuj poniższy kod i dodaj go do wiersza 31 w pliku variables.tf. Upewnij się, że nad i pod dodanym blokiem zmiennych znajduje się znak nowego wiersza.

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. Dodawanie nowej funkcji do przykładowego zasobnika

Funkcja została dodana do pliku main.tf modułu. Teraz możesz ją przetestować na przykładzie.

Etykietę „silly_label” należy dodać do pliku examples/multiple-buckets/main.tf.

Ten przykład zostanie użyty w następnym kroku do przeprowadzenia testów integracji.

Skopiuj i wklej poniższy wiersz zmiennej silly_label do wiersza 27 w pliku main.tf w katalogu terraform-google-cloud-storage/examples/multiple-buckets/, jak widać w strukturze folderów:

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. Aktualizowanie testu planu w celu sprawdzenia funkcji

Funkcja została dodana do pliku main.tf modułu, a następnie do przykładu multiple_buckets. Teraz musisz przetestować funkcję za pomocą testu integracji schematu napisanego w języku Golang.

Nowe testy dodasz w pliku multiple_buckets_test.go znajdującym się w tej strukturze folderów:

Wszystkie zasobniki tworzone za pomocą modułu multiple_buckets zostały oznaczone etykietą „silly_label”. Teraz musisz napisać testy, aby sprawdzić nową funkcję.

W poniższym kodzie pobierasz etykietę każdego zasobnika za pomocą polecenia gcloud alpha storage, a następnie sprawdzasz zwrócone dane wyjściowe.

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. Przeprowadzanie testów integracji w CFT

Testowanie integracji

Testy integracji służą do weryfikowania działania modułu głównego, modułów podrzędnych i przykładów. Dodatki, zmiany i poprawki powinny być testowane.

Testy integracji są pisane za pomocą platformy testowej blueprint i uruchamiane za pomocą CFT CLI. Dla wygody narzędzia te są spakowane w obrazie Dockera.

Ogólna strategia tych testów polega na weryfikacji działania przykładowych modułów, co zapewnia prawidłowe działanie modułu głównego, podmodułów i przykładowych modułów.

W przypadku wykonywania interaktywnego każdy krok jest wykonywany za pomocą wielu poleceń.

1. Uruchom make docker_run, aby uruchomić testowy kontener Dockera w trybie interaktywnym.

Make to narzędzie do automatyzacji kompilacji, które automatycznie kompiluje programy wykonywalne i biblioteki z kodu źródłowego, odczytując pliki o nazwie Makefiles, które określają, jak uzyskać program docelowy. Gdy wprowadzisz zmiany w pliku, kontener Dockera musi zostać automatycznie zaktualizowany.

Po uruchomieniu polecenia make docker_run w kontenerze Dockera utworzysz obszar roboczy i aktywujesz dane logowania do konta usługi. Przestrzeń robocza będzie używana w kolejnych krokach do przeprowadzania testów.

W terminalu zobaczysz te dane wyjściowe:

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

2. Uruchom polecenie module-swapper -registry-prefix=terraform-google-modules, aby dostosować przykładowe pliki main.tf i zaimportować moduły z plików lokalnych zamiast z opublikowanych modułów.

W terminalu powinny pojawić się dane wyjściowe podobne do tych:

[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. Uruchom polecenie cft test list, aby wyświetlić listę wszystkich testów projektów w obszarze roboczym.

W terminalu zobaczysz te dane wyjściowe:

[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. Uruchom cft test run <EXAMPLE_NAME> --stage init, aby zainicjować przykład. W tym przypadku, aby zainicjować test TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Podczas przeprowadzania testów możesz też użyć flagi --verbose, aby uzyskać dodatkowe informacje.

Ten etap inicjowania inicjuje przykład Terraform.

W terminalu zobaczysz te dane wyjściowe.

[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)

Uwaga: w dziennikach mogą się wyświetlać ostrzeżenia, np. Skipping fixtures discovery. Są to ostrzeżenia do debugowania, które można zignorować. Jeśli wystąpią błędy, test zakończy się niepowodzeniem.

5. Uruchom cft test run <EXAMPLE_NAME> --stage apply, aby zastosować przykładowy moduł.

W tym kroku przykład zainicjowany w poprzednim etapie zostanie zastosowany do projektu GCP utworzonego wcześniej w ramach Codelabu.

W terminalu zobaczysz te dane wyjściowe.

[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

Uwaga: jeśli w dziennikach widzisz wartość Request violates constraint 'constraints/storage.uniformBucketLevelAccess', oznacza to, że w Twoim projekcie nie można ustawić wartości uniform_bucket_level_access na false. W tym samouczku możesz obejść ten problem, ustawiając wartość cloud_storage.bucket_policy_only["two"] na true zamiast false i odpowiednio zmieniając test w języku Go.

6. Uruchom polecenie cft test run <EXAMPLE_NAME> --stage verify, aby sprawdzić, czy przykład utworzył oczekiwaną infrastrukturę.

Ten krok uruchomi funkcję weryfikacji w TestMultipleBuckets. Weryfikacja zwykle polega na wykonaniu polecenia gcloud w celu pobrania danych wyjściowych JSON dotyczących bieżącego stanu zasobu i sprawdzeniu, czy bieżący stan jest zgodny z tym zadeklarowanym w przykładzie.

Jeśli wystąpią błędy, zobaczysz, czego oczekiwano i co zostało odebrane przez polecenie w ramach testu.

W terminalu zobaczysz te dane wyjściowe.

[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. Uruchom cft test run <EXAMPLE_NAME> --stage teardown, aby zamknąć przykład.

Ten krok usuwa infrastrukturę utworzoną w poprzednich krokach. Ten krok spowoduje też usunięcie zasobników GCS utworzonych w projekcie wraz z etykietą dodaną do modułu GCS.

Poniższe dane wyjściowe możesz wyświetlić w terminalu.

[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. Uruchom polecenie module-swapper -registry-prefix=terraform-google-modules -restore, aby cofnąć zmiany wprowadzone w przykładzie plików main.tf podczas ostatniego uruchomienia polecenia 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. Uruchom exit, aby zamknąć kontener testowy.

9. Generowanie dokumentacji dotyczącej danych wejściowych i wyjściowych

Tabele danych wejściowych i wyjściowych w plikach README modułu głównego, podmodułów i modułów przykładowych są generowane automatycznie na podstawie wartości variables i outputs w odpowiednich modułach. Jeśli interfejsy modułu zostaną zmienione, tabele te należy odświeżyć.

Uruchomienie:

make generate_docs
# This will generate new Inputs and Outputs tables

Pamiętaj: zawsze uruchamiaj polecenie generate_docs, aby mieć pewność, że cała dokumentacja jest kompletna.

10. Przeprowadzanie testów lint w CFT

Linter to narzędzie, które analizuje kod źródłowy, aby oznaczać błędy programowania, błędy, błędy stylistyczne i podejrzane konstrukcje.

Wiele plików w repozytorium można sprawdzić pod kątem błędów lub sformatować, aby zachować standard jakości. Aby zapewnić jakość w CFT, użyjesz testu lint.

Uruchomienie:

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

Pamiętaj: zawsze przeprowadzaj test lint, ponieważ jeśli nie zostanie on ukończony, Cloud Build zakończy się niepowodzeniem. Uruchom to polecenie przed zatwierdzeniem kodu w lokalnym repozytorium.

11. Przesyłanie żądania pull na GitHubie

Uwaga: na tym etapie codelab jest już ukończony. Zachęcamy do tworzenia żądań pull tylko wtedy, gdy dopiero zaczynasz korzystać z GitHuba i chcesz poznać ten proces.

Po wprowadzeniu zmian w kodzie lokalnie i przetestowaniu go za pomocą testów integracyjnych możesz opublikować ten kod w głównym repozytorium.

Aby udostępnić kod w repozytorium głównym, musisz zatwierdzić zmiany w kodzie w gałęzi i wypchnąć je do repozytorium głównego. Aby Twój kod został dodany do głównego repozytorium, które zostało rozwidlone na początku Codelabu, po zatwierdzeniu kodu w swoim repozytorium musisz przesłać żądanie scalenia (PR) do głównego repozytorium.

Gdy zgłosisz prośbę o scalenie, administrator repozytorium otrzyma powiadomienie o konieczności sprawdzenia proponowanych zmian w kodzie. Możesz też dodać innych użytkowników jako weryfikatorów, aby uzyskać opinie na temat zmian w kodzie. Żądanie scalenia wywoła Cloud Build, który uruchomi testy w repozytorium.

Na podstawie zmian w kodzie osoby sprawdzające kod dodadzą komentarze i poproszą o wprowadzenie modyfikacji, jeśli coś wymaga zmiany zgodnie z dokumentacją i sprawdzonymi metodami. Administrator sprawdzi zmiany w kodzie i upewni się, że jest on zgodny z repozytorium. Może też poprosić o wprowadzenie dodatkowych zmian przed scaleniem kodu z głównym repozytorium.

Aby zatwierdzić kod w rozwidlonej gałęzi i przenieść go do niej, wykonaj te czynności:

1. Pierwszym krokiem jest dodanie zmienionych plików do lokalnego repozytorium.

$ 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. Pliki są teraz w poczekalni. Następnie zatwierdzisz zmiany.

$ 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. Prześlij zatwierdzone zmiany w lokalnym repozytorium do GitHuba, aby utworzyć żądanie pull.

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

Zmiany w kodzie są gotowe do wysłania prośby o scalenie.

Aby utworzyć żądanie scalenia w repozytorium terraform-google-modules/terraform-google-cloud-storage, wykonaj te czynności:

1. W przeglądarce otwórz stronę główną repo.
2. Na banerze zobaczysz sugestię otwarcia żądania scalenia z Twojego rozwidlenia. Kliknij „Porównaj i utwórz żądanie scalenia”.

3. Wpisz tytuł i opis żądania scalenia, aby opisać zmiany w kodzie. Podaj jak najwięcej szczegółów, ale zachowaj zwięzłość.

4. Aby utworzyć prośbę o scalenie gotową do sprawdzenia, kliknij „Utwórz prośbę o scalenie”.
5. Zobaczysz uruchomione aktywatory Cloud Build, które zostały wywołane z powodu żądania scalenia.
6. Jeśli napotkasz problemy, zapoznaj się z oficjalną dokumentacją GitHub na temat otwierania żądań pull z forków.

Udało Ci się przesłać pierwszą zmianę kodu do rozwidlonej gałęzi i utworzyć pierwsze żądanie pull CFT w gałęzi głównej.

12. Gratulacje

Gratulacje! Udało Ci się dodać funkcję do modułu CFT i przesłać prośbę o scalenie do sprawdzenia.

Dodano funkcję do modułu CFT, przetestowano ją lokalnie na przykładzie i przeprowadzono testy przed zatwierdzeniem kodu w GitHubie. Na koniec zgłoszono prośbę o sprawdzenie i ostateczne scalenie z CFT.

Znasz już ważne kroki, które należy wykonać, aby rozpocząć korzystanie z Cloud Foundation Toolkit.