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 zestaw narzędzi Cloud Foundation?

CFT udostępnia szablony, które zawierają sprawdzone metody i ułatwiają szybkie rozpoczęcie pracy z Google Cloud Platform. Z tego samouczka dowiesz się, jak współtworzyć pakiet narzędzi Cloud Foundation.

Czego potrzebujesz

Konto GitHub.
Docker zainstalowany na komputerze lub Cloud Shell ( instalacja na Macu, instalacja na Windowsie).
edytor kodu do edytowania kodu (np. Visual Studio Code),
Podstawowa znajomość usług Git i GitHub
podstawowe doświadczenie z Terraform i infrastrukturą jako kodem;
Uprawnienia do przypisania roli twórcy projektu do konta usługi
Organizacja Google Cloud, folder testowy i konto rozliczeniowe

Co utworzysz

Z tego modułu dowiesz się, jak przyczynić się do rozwoju pakietu narzędzi Cloud Foundation Toolkit (CFT).

W ramach ćwiczenia:

Skonfiguruj środowisko programistyczne do wykorzystania w CFT
Dodawanie funkcji do modułu CFT
Dodaj testy dodanej funkcji
Wykonywanie testów integracji w CFT
Wykonywanie testów lint
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ę o nazwie "silly_label", która zostanie automatycznie dodana do wszystkich zasobników utworzonych za pomocą modułu GCS CFT. Możesz też napisać testy, aby zweryfikować funkcję i zapewnić kompleksową integrację.

2. Skonfiguruj środowisko programistyczne

Jeśli chcesz, możesz korzystać z Cloud Shell do celów programistycznych. Jeśli nie chcesz korzystać z Cloud Shell do tworzenia w ramach CFT, możesz skonfigurować środowisko programistyczne na swoim komputerze.

Konfigurowanie Git

GitHub opiera się na systemie kontroli wersji open source o nazwie Git. Git odpowiada za wszystko, co dzieje się lokalnie na Twoim komputerze lub w Cloud Shell i jest związane z GitHubem.

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 do powiązania zatwierdzeń z tożsamością. Nazwa użytkownika Git nie jest taka sama jak nazwa użytkownika GitHub.

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żytej w przypadku poprzednich zatwierdzeń.

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

3. Rozwiń repozytorium GCS CFT

Tworzenie rozwidlenia repozytorium CFT

Konfigurujesz Git na maszynie lokalnej lub w Cloud Shell w poprzednim kroku. Aby zacząć tworzyć własne rozwiązania, musisz stworzyć kopię repozytorium CFT Google Cloud Storage.

Fork to kopia repozytorium. Forking repozytorium pozwala swobodnie eksperymentować ze zmianami bez wpływu na pierwotny projekt.

Najczęściej używane są one do proponowania zmian w projekcie innej osoby lub do korzystania z projektu innej osoby jako punktu wyjścia dla własnego pomysłu.

Możesz na przykład używać gałęzi do proponowania zmian związanych z poprawianiem błędów. Aby naprawić błąd:

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

Jak utworzyć fork repozytorium CFT:

Otwórz przeglądarkę i przejdź do repozytorium terraform-google-modules/terraform-google-cloud-storage. Użyjemy tego repozytorium w całym ćwiczeniu Codelab.
W prawym górnym rogu strony kliknij Utwórz rozwidlenie.

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

Klonowanie lokalnie utworzonej przez Ciebie gałęzi

Utworzona przez Ciebie gałąź jest kopią repozytorium modułu GCS. Teraz sklonuj ten repozytorium do środowiska lokalnego, aby dodać nową funkcję.

Jak sklonować swoją gałąź:

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

Po kliknięciu przycisku „Code” kliknij ikonę „Copy”, aby skopiować adres URL gałęzi. Za pomocą tego adresu URL sklonujesz fork 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.

Masz już skopiowany lokalnie fork, więc otwórz repozytorium, utwórz nową gałąź na podstawie forka i wprowadź zmiany w kodzie w gałęzi tymczasowej.

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

Prośby o dodanie funkcji: feature/feature-name
Aktualizacje wewnętrzne: 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ąć korzystać z zestawu narzędzi Cloud Foundation.

4. Tworzenie środowiska testowego

Standardowy proces tworzenia CFT polega na testowaniu odizolowanego projektu testowego. Na tym etapie dowiesz się, jak utworzyć projekt testowy (na podstawie standardowej konfiguracji) za pomocą konta usługi.

0. Instalowanie Docker Engine

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

1. Instalowanie pakietu Google Cloud SDK

Jeśli używasz Cloud Shell w Google Cloud Platform, nie musisz instalować pakietu Google Cloud SDK.

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

2. Konfiguracja

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

Zanim utworzysz środowisko testowe, musisz pobrać klucz konta usługi do środowiska testowego. To konto usługi musi mieć role 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ć istniejącego konta.

3.1 Tworzenie lub wybieranie projektu nasionowego w 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 nasadowym 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, 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 do Terraform

Przekaż klucz do Terraform za pomocą zmiennej środowiskowej SERVICE_ACCOUNT_JSON, ustawiając wartość na treści 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 ponownie utworzyć klucz, używając tego samego polecenia.

rm -rf cft.json

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

Gdy wszystko jest 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 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.

Jak widać na wyjściu konsoli, utworzyliśmy projekt testowy, do którego odwołuje się parametr project_id. Skonfigurowane jest środowisko programistyczne i testowe.

5. Dodawanie nowej funkcji do modułu CFT

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

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

Ponieważ „silly_label” jest etykietą, dodasz tę funkcję w wierszu 27 w zmiennej „labels” w pliku main.tf, jak pokazano 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 dodaj zmienną silly_label w pliku variables.tf, który znajduje się w powyżej pokazanej 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. Dodawanie nowej funkcji do przykładowego zasobnika pamięci

Funkcja została dodana do pliku main.tf modułu. Teraz przetestujesz ją na przykładzie.

Musisz dodać etykietę „silly_label” do pliku examples/multiple-buckets/main.tf.

Ten przykład posłuży w następnym kroku do przeprowadzenia testów integracyjnych.

Skopiuj i wklej podany niżej wiersz zmiennej silly_label do wiersza 27 w pliku main.tf w folderze terraform-google-cloud-storage/examples/multiple-buckets/, zgodnie z strukturą 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:

Dodasz etykietę „silly_label” do wszystkich zasobników utworzonych w ramach modułu multiple_buckets i teraz musisz napisać testy, aby przetestować nową funkcję.

W kodzie poniżej pobierasz etykietę każdego zasobnika za pomocą polecenia gcloud alpha storage, a następnie sprawdzasz zwrócony przez nie wynik.

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

Testowanie integracji

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

Testy integracji są tworzone za pomocą platformy testowej Blueprint i uruchamiane za pomocą CFT CLI. 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 przypadku wykonywania interaktywnego każdy krok jest wykonywany za pomocą wielu poleceń.

Uruchom make docker_run, aby rozpocząć testowanie kontenera Dockera w trybie interaktywnym.

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

Po uruchomieniu make docker_run tworzysz obszar roboczy w kontenerze Dockera i aktywujesz dane logowania dla swojego konta usługi. W kolejnych krokach będzie ona służyć do przeprowadzania 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 projektów w Twoim 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ć test TestMultipleBuckets, użyj funkcji cft test run TestMultipleBuckets --stage init. Aby uzyskać dodatkowe informacje podczas przeprowadzania testów, możesz też użyć flagi --verbose.

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)

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

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

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

Uruchom cft test run <EXAMPLE_NAME> --stage verify, aby sprawdzić, czy przykładowa infrastruktura została utworzona zgodnie z oczekiwaniami.

Na tym etapie funkcja weryfikacji zostanie uruchomiona w TestMultipleBuckets. Zwykle weryfikacja odbywa się przez wykonanie polecenia gcloud, aby pobrać dane wyjściowe w formacie JSON dotyczące bieżącego stanu zasobu i sprawdzić, czy jest on zgodny z deklarowanym w przykładzie.

Jeśli pojawią się błędy, zobaczysz oczekiwany i otrzymany wynik polecenia.

W terminalu zobaczysz te 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 sprawdzić przykład.

Ten krok powoduje usunięcie infrastruktury utworzonej 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

Aby zamknąć testowy kontener, uruchom exit.

9. Generowanie dokumentacji dla 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. Jeśli interfejsy modułów ulegną zmianie, te tabele trzeba odświeżyć.

Uruchomienie:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Wykonywanie testów lint w CFT

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

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

Uruchomienie:

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

11. Przesyłanie propozycji zmian w GitHubie

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

Aby udostępnić kod w master repo, musisz zatwierdzić zmiany kodu w gałęzi i wypchnąć je do repozytorium głównego. Aby Twój kod został dodany do głównego repozytorium, które zostało utworzone na początku Codelab, po skompilowaniu kodu w swoim repozytorium musisz przesłać prośbę o dodanie kodu (Pull Request, PR) do głównego repozytorium.

Gdy prześlesz PR, administrator repozytorium otrzyma powiadomienie z prośbą o sprawdzenie 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 spowoduje uruchomienie Cloud Build, który przeprowadzi testy w repozytorium.

Na podstawie wprowadzonych zmian recenzenci kodu umieszczą w nim komentarze i poproszą o wprowadzenie zmian, jeśli coś wymaga modyfikacji zgodnie ze sprawdzonymi metodami i dokumentacją. Administrator sprawdzi zmiany w kodzie, upewni się, że jest on zgodny z repozytorium, i może poprosić Cię o wprowadzenie pewnych zmian przed połączeniem kodu z głównym repozytorium.

Aby powiązać kod z gałęzi pochodną i przesłać go do tej gałęzi, wykonaj te czynności:

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.

Prześlij zatwierdzone zmiany w lokalnym 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.
Na banerze zobaczysz propozycję otwarcia PR-a z Twojego forkowania. Kliknij „Porównaj i pobierz żądanie”.

Wpisz tytuł i opis żądania połączenia, aby opisać zmiany w kodzie. Podaj jak najwięcej szczegółów, ale w zwięzły sposób.

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

Udało Ci się wypchnąć pierwszą zmianę kodu do gałęzi pobranej i przesłać pierwszy PR CFT do 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. W końcu przesłałeś/przesłałaś PR do sprawdzenia i ostatecznego połączenia z CFT.

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