Ta strona została przetłumaczona przez Cloud Translation API.

Poradnik Cloud Foundation Toolkit

1. Wprowadzenie do CFT 101

Ostatnia aktualizacja: 11.02.2022 r.

Co to jest Cloud Foundation Toolkit?

Mówiąc w skrócie, CFT zawiera szablony ze sprawdzonymi metodami, które pozwalają szybko rozpocząć pracę w Google Cloud Platform. Z tego samouczka dowiesz się, jak wziąć udział w Cloud Foundation Toolkit.

Czego potrzebujesz

konto GitHub.
Docker zainstalowany na komputerze lub użyj Cloud Shell ( instalacja na Macu, instalacja w systemie Windows)
Edytor kodu do edycji kodu (np. Visual Studio Code)
Podstawowa znajomość usług Git i GitHub
Pewne doświadczenie z Terraform i infrastrukturą jako kodem
Uprawnienie do przypisania roli twórcy projektów do konta usługi
Organizacja Google Cloud, folder testowy i konto rozliczeniowe

Co utworzysz

W ramach tego ćwiczenia w Codelabs dowiesz się, jak wnosić wkład w Cloud Foundation Toolkit (CFT).

W ramach ćwiczenia:

Skonfiguruj środowisko programistyczne do wykorzystania w CFT
Dodawanie funkcji do modułu CFT
Dodaj testy dodanej funkcji
Przeprowadzaj testy integracji w CFT
Przeprowadzanie testów lintowania
Zatwierdź kod w GitHubie i prześlij żądanie pull (PR)

Wszystkie powyższe czynności możesz wykonać, dodając nową funkcję do modułu CFT w Google Cloud Storage. Dodasz etykietę "silly_label", która będzie automatycznie dodawana do wszystkich zasobników utworzonych za pomocą modułu GCS CFT. Będziesz też mieć możliwość napisania testów, aby sprawdzić działanie funkcji i zapewnić kompleksową integrację.

2. Skonfiguruj środowisko programistyczne

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

Skonfiguruj Git

Serwis GitHub opiera się na systemie kontroli wersji typu open source (VCS) o nazwie Git. Git jest odpowiedzialny za wszystko, co związane z GitHubem, co dzieje się lokalnie na Twojej maszynie lub w Cloud Shell.

Jeśli używasz Cloud Shell, nie musisz instalować git, bo jest on zainstalowany fabrycznie.

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

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

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

Git używa nazwy użytkownika, aby powiązać zatwierdzenia z tożsamością. Nazwa użytkownika Git różni się od Twojej nazwy użytkownika GitHuba.

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

Udało Ci się skonfigurować Git i powinno być możliwe rozwidlenie, tworzenie i klonowanie gałęzi. W tym ćwiczeniu z programowania będziemy intensywnie korzystać z Git.

3. Oddziel repozytorium GCS CFT

Tworzenie rozwidlenia repozytorium CFT

Konfigurujesz Git na maszynie lokalnej lub w Cloud Shell w poprzednim kroku. Aby zacząć współtworzyć, musisz teraz utworzyć rozwidlenie repozytorium CFT Google Cloud Storage.

Fork to kopia repozytorium. Rozwinięcie repozytorium umożliwia swobodne eksperymentowanie ze zmianami bez wpływu na pierwotny projekt.

Najczęściej używa się ich do proponowania zmian do cudzego projektu lub do wykorzystywania 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 naprawą błędu. Aby naprawić błąd:

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

Instrukcje tworzenia repozytorium CFT:

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

Pojawi się opcja wyboru miejsca, w którym chcesz umieścić widelec, wybierz swój profil, a repozytorium zostanie rozwidlone.

Lokalne sklonowanie rozwidlenia

Utworzony przez Ciebie rozwidlenie jest kopią repozytorium modułu GCS. Aby dodać nową funkcję, sklonujesz to repozytorium do środowiska lokalnego.

Procedura sklonowania widelec:

Otwórz przeglądarkę i przejdź do swojego rozwidlenia na stronie terraform-google-modules/terraform-google-cloud-storage.
W prawym górnym rogu zobaczysz pole „Kod”, kliknij go.

Po kliknięciu linku „Kod” kliknij przycisk „Kopiuj”, aby skopiować adres URL rozwidlenia. Użyjesz tego adresu, aby sklonować swój widelec do środowiska lokalnego.

Przejdź do terminala w VSCode lub na komputerze i skopiuj rozwidlenie.

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

Po sklonowaniu rozwidlenia lokalnie możesz przejść do repozytorium, utworzyć nową gałąź z rozwidlenia i wprowadzić zmiany w kodzie tej gałęzi tymczasowej.

Zgodnie z konwencją możesz nazwać gałąź w następujący sposób:

Prośby o dodanie funkcji: feature/feature-name
Na potrzeby aktualizacji wewnętrznych internal/change-name
Poprawki błędów: bugfix/issue-name

Dodajesz nową funkcję, więc możesz nazwać swoją gałąź tymczasową 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"

Wszystko gotowe do rozpoczęcia pracy z Cloud Foundation Toolkit.

4. Tworzenie środowiska testowego

Standardowy proces tworzenia narzędzia do testowania CFT polega na wykorzystaniu izolowanego projektu testowego do testowania. Ten krok przeprowadzi Cię przez proces tworzenia projektu testowego (w przypadku konfiguracji standardowej) za pomocą konta usługi.

0. Zainstaluj Docker Engine

Jeśli używasz komputera do programowania, musisz zainstalować Docker Engine.

1. Zainstaluj pakiet Google Cloud SDK

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

Otwórz Google Cloud SDK i pobierz interaktywny instalator dla Twojej platformy.

2. Skonfiguruj

Aby utworzyć środowisko testowe, potrzebujesz organizacji Google Cloud, folderu testowego i konta rozliczeniowego. 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. Skonfiguruj konto usługi

Zanim utworzysz środowisko testowe, musisz pobrać klucz konta usługi do środowiska testowego. To konto usługi wymaga ról Twórca projektów, Użytkownik kont rozliczeniowych i Wyświetlający organizację. Te kroki pomogą Ci utworzyć nowe konto usługi, ale możesz też użyć istniejącego konta.

3.1 Utwórz lub wybierz początkowy projekt GCP

Zanim utworzysz konto usługi, musisz wybrać projekt, w którym będziesz je hostować. Możesz też utworzyć nowy projekt.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Włączanie interfejsów Google Cloud APIs

Włącz w projekcie wyjściowym te interfejsy API Google Cloud:

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, aby zarządzać ś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 Przypisz do konta 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. Przygotuj dane 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 danych logowania w zmiennej środowiskowej usuń plik klucza. W razie potrzeby możesz ponownie utworzyć klucz później, korzystając z tego samego polecenia powyżej.

rm -rf cft.json

5. Utwórz projekt testowy dla wdrożeń Terraform

Gdy wszystko jest już przygotowane, 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 make docker_test_prepare zobaczysz poniższe dane wyjściowe. Na końcu otrzymasz utworzony testowy identyfikator projektu (project_id), w którym wdrożysz i przetestujesz swój moduł Cloud Storage z nową funkcją. Jeśli wystąpią problemy z połączeniem konta rozliczeniowego, przeczytaj ten artykuł.

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.

Udało Ci się utworzyć projekt testowy, do którego odwołuje się identyfikator projektu (project_id), tak jak widać w danych wyjściowych konsoli. Środowisko programistyczne i testowe jest skonfigurowane.

5. Dodaj nową funkcję do modułu CFT

Twoje środowisko programistyczne i testowe jest już skonfigurowane, zacznijmy więc dodawać „silly_label” do modułu CFT google-cloud-storage.

Upewnij się, że jesteś w terraform-google-cloud-storage, i otwórz plik main.tf zgodnie ze schematem folderów.

Od „silly_label” jest etykietą, dodasz ją w wierszu 27 w zmiennej „etykiety” 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 plikuvariable.tf widoczny w powyższej strukturze folderów.

Skopiuj poniższy kod i dodaj go w wierszu 31 w zmiennej.tf. Upewnij się, że nad i pod dodanym blokiem zmiennej jest nowy znak 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. Dodaj nową funkcję do przykładowego zasobnika na dane

Twoja funkcja została dodana do pliku main.tf modułu. Teraz przetestujesz na przykładzie tę dodaną funkcję.

Parametr „silly_label” należy dodać do plików example/multiple-buckets/main.tf

Ten przykład zostanie wykorzystany w następnym kroku do testów integracji.

Skopiuj poniższy wiersz zmiennej silly_label do wiersza 27 w pliku main.tf w folderze terraform-google-cloud-storage/examples/multiple-buckets/, tak jak 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. Zaktualizuj test planu, aby sprawdzić funkcję

Twoja funkcja została dodana do pliku main.tf modułu, a następnie do przykładu z wieloma zasobnikami. Teraz musisz przetestować swoją funkcję za pomocą testu integracji planu napisanego w języku Golang.

Nowe testy dodasz do pliku multiple_buckets_test.go znajdującego się w poniższej strukturze folderów:

Dodano atrybut „silly_label” na wszystkich zasobnikach tworzonych w ramach modułu multiple_buckets. Teraz musisz napisać testy, aby przetestować nową funkcję.

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

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. Przeprowadzaj testy integracji w CFT

Testowanie integracji

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

Testy integracji są tworzone przy użyciu platformy testów planowych i uruchamiane za pomocą interfejsu wiersza poleceń CFT. Dla wygody narzędzia te są umieszczone w obrazie Dockera.

Ogólną strategią prowadzenia takich testów jest sprawdzenie działania modułów przykładowych, czyli sprawdzenie, czy moduł główny, moduły podrzędne i moduły przykładowe działają prawidłowo.

W tym przypadku każdy krok wykonujesz za pomocą wielu poleceń.

Uruchom make docker_run, aby przetestować kontener Dockera w trybie interaktywnym.

Make to narzędzie do automatyzacji kompilacji, które automatycznie kompiluje na podstawie kodu źródłowego programy wykonywalne i biblioteki, odczytując pliki o nazwie Makefiles, które określają sposób uzyskania programu docelowego. Po wprowadzeniu zmian w pliku kontener Dockera musi być aktualizowany automatycznie.

Po uruchomieniu make docker_run tworzysz obszar roboczy w kontenerze Dockera i aktywujesz dane logowania dla swojego konta usługi. Ten obszar roboczy zostanie użyty w następnych krokach do przeprowadzenia testów.

W terminalu zobaczysz te dane wyjściowe:

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

Uruchom cft test list, aby wyświetlić listę wszystkich testów planó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

Uruchom cft test run <EXAMPLE_NAME> --stage init, aby zainicjować przykład. W tym przypadku, aby zainicjować uruchomienie testowe TestMultipleBuckets, cft test run TestMultipleBuckets --stage init. Możesz też użyć flagi --verbose, aby podczas przeprowadzania testów uzyskiwać dodatkowe informacje.

Ten etap inicjowania inicjuje przykład Terraform.

W terminalu zobaczysz poniższe 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)

Aby zastosować przykładowy moduł, uruchom polecenie cft test run <EXAMPLE_NAME> --stage apply.

W tym kroku zastosujemy przykład zainicjowany w poprzednim etapie do projektu GCP utworzonego wcześniej w ramach ćwiczeń z programowania.

W terminalu zobaczysz poniższe 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

Uruchom cft test run <EXAMPLE_NAME> --stage verify, aby sprawdzić, czy w przykładzie została utworzona oczekiwana infrastruktura.

Ten krok spowoduje uruchomienie funkcji weryfikacji w TestMultipleBuckets. Zwykle weryfikacja odbywa się za pomocą polecenia gcloud, które pobiera dane wyjściowe JSON dla bieżącego stanu zasobu i potwierdza, że bieżący stan jest zgodny z zadeklarowanym w przykładzie.

Jeśli pojawią się błędy, zobaczysz, co było oczekiwane, a co otrzymało polecenie w ramach testu.

W terminalu zobaczysz poniższe dane wyjściowe.

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

Uruchom cft test run <EXAMPLE_NAME> --stage teardown, aby zamknąć przykład.

Ten krok zniszczy infrastrukturę utworzoną w powyższych krokach. W tym kroku zniszczysz też zasobniki GCS utworzone 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

Uruchom exit, aby wyjść z kontenera testowego.

9. Generowanie dokumentacji danych wejściowych i wyjściowych

Tabele danych wejściowych i wyjściowych w plikach README modułu głównego, modułów podrzędnych i modułów przykładowych są generowane automatycznie na podstawie parametrów variables i outputs odpowiednich modułów. W przypadku zmiany interfejsów modułów należy odświeżyć te tabele.

Uruchomienie:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Przeprowadzanie testów lintowania w CFT

Linter to narzędzie, które analizuje kod źródłowy w celu zgłaszania błędów programowania, błędów, pomyłek stylistycznych i podejrzanych konstrukcji.

Wiele plików w repozytorium można lintować lub formatować, by utrzymać standard jakości. Aby zapewnić odpowiednią jakość w CFT, należy użyć testu lintowego.

Uruchomienie:

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

11. Przesyłanie PR w GitHubie

Po lokalnej zmianie kodu i przetestowaniu go za pomocą testów integracji możesz opublikować go w głównym repozytorium.

Aby udostępnić kod w głównym repozytorium, musisz zatwierdzić zmiany kodu w gałęzi i wypchnąć go do repozytorium głównego. Jeśli chcesz, aby Twój kod został dodany do głównego repozytorium rozgałęzionego na początku ćwiczeń z programowania, musisz wysłać żądanie pull (PR) do repozytorium głównego po wyrażeniu zgody na dodanie kodu do repozytorium.

Gdy zgłosisz prośbę o pomoc, administrator repozytorium zostanie powiadomiony o konieczności sprawdzenia proponowanych zmian w kodzie. Możesz też dodać innych użytkowników jako weryfikatorów, którzy będą otrzymywać ich opinie na temat zmian w Twoim kodzie. PR aktywuje usługę Cloud Build, która przeprowadzi testy w repozytorium.

Na podstawie zmian w kodzie weryfikatorzy będą go komentować i poprosić o wprowadzenie zmian, jeśli na podstawie sprawdzonych metod i dokumentacji trzeba będzie wprowadzić jakieś zmiany. Administrator sprawdzi zmiany w kodzie, upewni się, że kod jest zgodny z repozytorium i może ponownie poprosić Cię o wprowadzenie zmian przed scaleniem kodu z repozytorium głównym.

Wykonaj te czynności, aby zatwierdzić kod w rozwidlonej gałęzi i wypchnąć go do rozwidlonej gałęzi:

Najpierw dodaj zmienione pliki 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

Pliki są teraz podzielone na etapy. W następnym kroku 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.

Przekaż zatwierdzone zmiany z lokalnego repozytorium do GitHuba, aby utworzyć żądanie pull (PR).

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

Zmiany w kodzie są teraz gotowe do użycia w żądaniu pull.

Aby utworzyć PR w repozytorium terraform-google-modules/terraform-google-cloud-storage, wykonaj te czynności:

W przeglądarce otwórz stronę główną repozytorium.
W banerze zobaczysz sugestię dotyczącą otwarcia pola PR z rozwidlenia. Kliknij „Porównaj i pobierz żądanie”.

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

Aby utworzyć żądanie pull, które jest gotowe do sprawdzenia, kliknij „Utwórz żądanie pull”.
Zobaczysz uruchomione aktywatory Cloud Build, które są aktywowane ze względu na PR.
Jeśli wystąpią problemy, zapoznaj się z oficjalnymi dokumentami GitHub dotyczącymi otwierania żądań pull z rozwidleń.

Udało Ci się wprowadzić pierwszą zmianę kodu do rozwidlonej gałęzi i utworzyć pierwszy PR CFT względem gałęzi głównej.

12. Gratulacje

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

Udało Ci się dodać funkcję do modułu CFT, przetestować ją lokalnie za pomocą przykładu i przeprowadzić testy przed zatwierdzeniem kodu w usłudze GitHub. Na koniec przekazałeś(-aś) PR do sprawdzenia i końcowego scalenia w CFT.

Znasz już najważniejsze kroki, które należy wykonać, aby zacząć korzystać z Cloud Foundation Toolkit.