Diese Seite wurde von der Cloud Translation API übersetzt.

Grundlagen-Toolkit Teil 1

1. Einführung in CFT 101

Zuletzt aktualisiert:11.02.2022

Was ist das Cloud Foundation Toolkit?

Im Wesentlichen bieten diese Tools Best-Practice-Vorlagen für einen schnellen Einstieg in die Google Cloud Platform. In dieser Anleitung erfahren Sie, wie Sie zum Cloud Foundation Toolkit beitragen können.

Voraussetzungen

Ein GitHub-Konto.
Auf Ihrem Computer installierter Docker oder Cloud Shell ( Mac-Installation, Windows-Installation)
Code-Editor zum Bearbeiten von Code (Beispiel: Visual Studio Code)
Grundkenntnisse in Git und GitHub
Erfahrung mit Terraform und Infrastruktur als Code
Berechtigung zum Zuweisen der Rolle „Projektersteller“ zu einem Dienstkonto
Eine Google Cloud-Organisation, ein Testordner und ein Rechnungskonto

Inhalt

In diesem Codelab erfahren Sie, wie Sie zum Cloud Foundation Toolkit (CFT) beitragen.

Sie werden Folgendes tun:

Entwicklungsumgebung einrichten, um zu CFT beizutragen
Einem CFT-Modul Funktionen hinzufügen
Tests für die hinzugefügte Funktion hinzufügen
Integrationstests in CFT ausführen
Lint-Tests ausführen
Commit des Codes an GitHub und Senden einer Pull-Anfrage (PR)

Alle oben genannten Schritte werden ausgeführt, indem Sie dem CFT-Modul von Google Cloud Storage ein neues Feature hinzufügen. Sie fügen ein Label namens "silly_label" hinzu, das automatisch allen Buckets hinzugefügt wird, die mit dem GCS-CFT-Modul erstellt werden. Außerdem schreiben Sie Tests, um Ihr Feature zu validieren und die End-to-End-Integration sicherzustellen.

2. Entwicklungsumgebung einrichten

Wenn Sie möchten, können Sie Cloud Shell für Ihre Entwicklung verwenden. Wenn Sie Cloud Shell nicht für Beiträge zu CFT verwenden möchten, können Sie Ihre Entwicklungsumgebung auf Ihrem Computer einrichten.

Git einrichten

GitHub basiert auf einem Open-Source-Versionskontrollsystem (VCS) namens Git. Git ist für alles GitHub-bezogene Vorgänge zuständig, was lokal auf Ihrem Computer oder in Cloud Shell geschieht.

Wenn Sie Cloud Shell verwenden, müssen Sie Git nicht installieren, da es vorinstalliert ist.

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

Wenn Sie Ihre Entwicklungsumgebung auf Ihrem Computer einrichten, müssen Sie Git installieren.

Nutzername und E-Mail-Adresse in Git festlegen

Git verwendet einen Nutzernamen, um Commits mit einer Identität zu verknüpfen. Der Git-Nutzername ist nicht mit Ihrem GitHub-Nutzernamen identisch.

Mit dem Befehl „git config“ können Sie den Namen ändern, der Ihren Git-Commits zugeordnet ist. Wenn Sie den Namen ändern, der mit Ihren Git-Commits über git config verknüpft ist, wirkt sich das nur auf zukünftige Commits aus. Der Name, der für frühere Commits verwendet wurde, bleibt davon unberührt.

Sie haben Git erfolgreich eingerichtet und sollten Zweige verzweigen, erstellen und klonen können. Wir werden Git in diesem Codelab intensiv verwenden.

3. GCS-Repository von CFT verzweigen

CFT-Repository verzweigen

Sie haben Git auf Ihrem lokalen Computer oder in Cloud Shell im vorherigen Schritt eingerichtet. Jetzt müssen Sie das CFT-Repository von Google Cloud Storage abspalten, um einen Beitrag zu leisten.

Ein Fork ist eine Kopie eines Repositorys. Durch das Verzweigen eines Repositorys können Sie frei mit Änderungen experimentieren, ohne das ursprüngliche Projekt zu beeinträchtigen.

Meistens werden Gabeln verwendet, um entweder Änderungen an dem Projekt einer anderen Person vorzuschlagen oder das Projekt einer anderen Person als Ausgangspunkt für Ihre eigene Idee zu verwenden.

Sie können beispielsweise Forks verwenden, um Änderungen zur Behebung eines Fehlers vorzuschlagen. So beheben Sie einen Fehler:

Verzweigen Sie das Repository.
Beheben Sie das Problem.
Senden Sie eine Pull-Anfrage an den Projektinhaber.

Schritte zum Verzweigen eines CFT-Repositorys:

Öffnen Sie Ihren Webbrowser und rufen Sie das Repository terraform-google-modules/terraform-google-cloud-storage auf. Wir verwenden dieses Repository für das gesamte Codelab.
Klicken Sie in der rechten oberen Ecke der Seite auf Fork.

Es wird eine Option angezeigt, wo Sie die Verzweigung haben und Ihr Profil auswählen können. Das Repository wird dann verzweigt.

Verzweigung lokal klonen

Die von Ihnen erstellte Verzweigung ist eine Kopie des GCS-Modul-Repositorys. Sie klonen dieses Repository jetzt in Ihre lokale Umgebung, um Ihre neue Funktion hinzuzufügen.

Schritte zum Klonen der Verzweigung:

Öffnen Sie Ihren Webbrowser und gehen Sie zu Ihrer Verzweigung in terraform-google-modules/terraform-google-cloud-storage.
In der oberen rechten Ecke sehen Sie den Code klicken Sie darauf.

Nachdem Sie auf den Link "Code" klicken Sie auf die Schaltfläche "Kopieren" um die URL der Verzweigung zu kopieren. Mit dieser URL klonen Sie die Verzweigung in Ihrer lokalen Umgebung.

Rufen Sie ein Terminal in Ihrem VSCode oder Ihrem Computer auf und klonen Sie die Verzweigung.

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

Nachdem Sie die Verzweigung nun lokal geklont haben, sollten Sie in Ihr Repository wechseln, einen neuen Zweig aus der Verzweigung erstellen und den Code für den temporären Zweig ändern.

Konventionsgemäß können Sie Ihren Zweig wie folgt benennen:

Für Funktionsanfragen: feature/feature-name
Für interne Updates: internal/change-name
Für Fehlerkorrekturen: bugfix/issue-name

Da Sie ein neues Feature hinzufügen, können Sie Ihren temporären Zweig feature/silly_label aufrufen

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

Sie sind jetzt startklar, um mit der Arbeit am Cloud Foundation Toolkit zu beginnen.

4. Testumgebung erstellen

Der standardmäßige Entwicklungsprozess für CFT basiert auf der Verwendung eines isolierten Testprojekts zum Testen. In diesem Schritt erfahren Sie, wie Sie das Testprojekt (basierend auf einer Standardkonfiguration) über ein Dienstkonto erstellen.

0. Docker Engine installieren

Wenn Sie Ihre Maschine zu Entwicklungszwecken verwenden, müssen Sie die Docker Engine installieren.

1. Google Cloud SDK installieren

Wenn Sie Cloud Shell der GCP verwenden, müssen Sie das Google Cloud SDK nicht installieren.

Rufen Sie das Google Cloud SDK auf und laden Sie das interaktive Installationsprogramm für Ihre Plattform herunter.

2. Konfiguration festlegen

Zum Erstellen einer Testumgebung benötigen Sie eine Google Cloud-Organisation, einen Testordner und ein Rechnungskonto. Diese Werte müssen über Umgebungsvariablen festgelegt werden:

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. Dienstkonto einrichten

Bevor Sie eine Testumgebung erstellen, müssen Sie einen Dienstkontoschlüssel für Ihre Testumgebung herunterladen. Dieses Dienstkonto benötigt die Rollen Projektersteller, Rechnungskontonutzer und Organisationsbetrachter. Mit diesen Schritten können Sie ein neues Dienstkonto erstellen. Sie können aber auch ein vorhandenes Konto wiederverwenden.

3.1 Startprojekt in der Google Cloud Platform erstellen oder auswählen

Bevor Sie Ihr Dienstkonto erstellen, müssen Sie ein Projekt zum Hosten auswählen. Sie können auch ein neues Projekt erstellen.

gcloud config set core/project YOUR_PROJECT_ID

3.2 Google Cloud APIs aktivieren

Aktivieren Sie die folgenden Google Cloud APIs in Ihrem Startprojekt:

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

3.3 Dienstkonto erstellen

Erstellen Sie ein neues Dienstkonto zum Verwalten der Testumgebung:

# 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

Prüfen Sie, ob Ihr Dienstkonto erstellt wurde:

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

3.4 Gewähren Sie dem Dienstkonto die Rollen „Projektersteller“, „Rechnungskontonutzer“ und „Organisationsbetrachter“:

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"

Jetzt haben Sie ein Dienstkonto, mit dem Sie die Testumgebung verwalten können.

4. Terraform-Anmeldedaten vorbereiten

Zum Erstellen der Testumgebung müssen Sie den Dienstkontoschlüssel in Ihre Shell herunterladen.

4.1 Dienstkontoschlüssel

Dienstkontoschlüssel für Terraform erstellen und herunterladen

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

4.2 Terraform-Anmeldedaten einrichten

Stellen Sie den Schlüssel mithilfe der Umgebungsvariable SERVICE_ACCOUNT_JSON an Terraform bereit und legen Sie den Wert auf contents Ihres Dienstkontoschlüssels fest.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

Entfernen Sie die Schlüsseldatei, nachdem Sie die Anmeldedaten in der Umgebungsvariablen gespeichert haben. Sie können einen Schlüssel später bei Bedarf mit dem obigen Befehl neu erstellen.

rm -rf cft.json

5. Testprojekt für Terraform-Bereitstellungen erstellen

Jetzt können Sie das Testprojekt mit einem einzigen Befehl erstellen. Führen Sie im Stammverzeichnis des Verzeichnisses „terraform-google-cloud-storage“ den folgenden Befehl aus:

make docker_test_prepare

Wenn Sie make docker_test_prepare ausführen, sehen Sie die folgende Ausgabe. Am Ende erhalten Sie die Test-ID des Felds „project_id“, die erstellt wurde, um das Cloud Storage-Modul mit dem neuen Feature bereitzustellen und zu testen. Falls beim Verknüpfen eines Rechnungskontos Probleme auftreten, lesen Sie die Schritte zur Fehlerbehebung.

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.

Sie haben nun ein Testprojekt erstellt, auf das mit der Projekt-ID „project_id“ verwiesen wird, wie Sie in der Konsolenausgabe sehen können. Ihre Entwicklungs- und Testumgebung ist eingerichtet.

5. Neue Funktion zum CFT-Modul hinzufügen

Ihre Entwicklungs- und Testumgebung sind nun eingerichtet. Fügen Sie jetzt Ihr "silly_label" hinzu. zum CFT-Modul „google-cloud-storage“ hinzu.

Stellen Sie sicher, dass Sie sich im Verzeichnis terraform-google-cloud-storage befinden, und öffnen Sie die Datei "main.tf" in der Ordnerstruktur wie unten gezeigt.

Seit „silly_label“ ein Label ist, fügen Sie das Element in Zeile 27 in der Variablen in "main.tf" verwenden, wie Sie unten sehen:

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

Fügen Sie nun die Variable "silly_label" in die Variable "variable.tf" ein, die Sie in der obigen Ordnerstruktur sehen.

Kopieren Sie den unten stehenden Code und fügen Sie ihn in Zeile 31 in „Variables.tf“ ein. Achten Sie darauf, dass über und unter dem Variablenblock, den Sie hinzufügen, ein Zeilenvorschubzeichen vorhanden ist.

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. Neues Feature zum Beispiel für einen Storage-Bucket hinzufügen

Sie haben Ihre Funktion zur "main.tf" des Moduls hinzugefügt und testen sie nun anhand eines Beispiels.

„silly_label“ müssen der Datei examples/multiple-buckets/main.tf

Dieses Beispiel wird im nächsten Schritt verwendet, um Integrationstests durchzuführen.

Kopieren Sie die folgende Zeile für die Variable „silly_label“ in Zeile 27 in „main.tf“ unter „terraform-google-cloud-storage/examples/multiple-buckets/“, wie in der Ordnerstruktur dargestellt:

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. Blueprint-Test aktualisieren, um Funktion zu prüfen

Sie haben Ihre Funktion in die Datei "main.tf" des Moduls und dann zum Beispiel "multiple_buckets" hinzugefügt. Jetzt müssen Sie Ihre Funktion über einen Blueprint-Integrationstest testen, der in Golang geschrieben wurde.

Sie fügen Ihre neuen Tests in der Datei multiple_buckets_test.go hinzu, die sich in der folgenden Ordnerstruktur befindet:

Du hast das Label „silly_label“ hinzugefügt für alle Buckets, die über das Modul "multiple_buckets" erstellt werden. Jetzt müssen Sie Tests schreiben, um die neue Funktion zu testen.

Im folgenden Code rufen Sie das Label jedes Buckets mit dem Befehl „gcloud alpha storage“ ab und prüfen dann die zurückgegebene Ausgabe des Befehls.

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. Integrationstests in CFT ausführen

Integrationstests

Integrationstests werden verwendet, um das Verhalten des Stammmoduls, der untergeordneten Module und der Beispiele zu überprüfen. Ergänzungen, Änderungen und Fehlerbehebungen sollten mit Tests begleitet werden.

Die Integrationstests werden mit dem Blueprint-Test-Framework geschrieben und über die CFT-CLI ausgeführt. Diese Tools sind der Einfachheit halber in einem Docker-Image verpackt.

Bei diesen Tests wird im Allgemeinen versucht, das Verhalten der Beispielmodule zu überprüfen und so sicherzustellen, dass das Stammmodul, die untergeordneten Module und Beispielmodule alle ordnungsgemäß funktionieren.

Bei der interaktiven Ausführung führen Sie jeden Schritt über mehrere Befehle aus.

Führen Sie make docker_run aus, um den Docker-Testcontainer im interaktiven Modus zu starten.

Make ist ein Tool zur Build-Automatisierung, das automatisch ausführbare Programme und Bibliotheken aus Quellcode erstellt. Dazu werden Dateien namens Makefiles gelesen, in denen festgelegt ist, wie das Zielprogramm abgeleitet wird. Wenn Sie Dateiänderungen vornehmen, muss der Docker-Container automatisch aktualisiert werden.

Wenn Sie make docker_run ausführen, erstellen Sie einen Arbeitsbereich in Ihrem Docker-Container und aktivieren die Anmeldedaten für Ihr Dienstkonto. Der Arbeitsbereich wird in den nächsten Schritten zum Ausführen von Tests verwendet.

Im Terminal wird die folgende Ausgabe angezeigt:

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

Führen Sie cft test list aus, um alle Blueprints-Tests in Ihrem Arbeitsbereich aufzulisten.

Im Terminal wird die folgende Ausgabe angezeigt:

[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

Führen Sie cft test run <EXAMPLE_NAME> --stage init aus, um das Beispiel zu initialisieren. In diesem Fall wird der TestMultipleBuckets-Testlauf cft test run TestMultipleBuckets --stage init initialisiert. Außerdem können Sie das Flag --verbose verwenden, um beim Ausführen von Tests zusätzliche Informationen abzurufen.

In dieser Initialisierungsphase wird das Terraform-Beispiel initialisiert.

Sie sehen die folgende Ausgabe in Ihrem Terminal.

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

Führen Sie cft test run <EXAMPLE_NAME> --stage apply aus, um das Beispielmodul anzuwenden.

Mit diesem Schritt wird das in der vorherigen Phase initialisierte Beispiel auf das zuvor im Codelab erstellte GCP-Projekt angewendet.

Sie sehen die folgende Ausgabe in Ihrem Terminal.

[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

Führen Sie cft test run <EXAMPLE_NAME> --stage verify aus, um zu prüfen, ob im Beispiel die erwartete Infrastruktur erstellt wurde.

Mit diesem Schritt wird die Überprüfungsfunktion in TestMultipleBuckets ausgeführt. In der Regel erfolgt die Überprüfung durch Ausführung eines gcloud-Befehls, um die JSON-Ausgabe für den aktuellen Status einer Ressource abzurufen, und sicherzustellen, dass der aktuelle Status wie im Beispiel deklariert ist.

Wenn Fehler auftreten, sehen Sie, was erwartet wurde und was der Befehl für den Test empfangen hat.

Sie sehen die folgende Ausgabe in Ihrem Terminal.

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

Führen Sie cft test run <EXAMPLE_NAME> --stage teardown aus, um das Beispiel zu löschen.

Mit diesem Schritt wird die Infrastruktur gelöscht, die Sie in den obigen Schritten erstellt haben. Mit diesem Schritt werden auch die im Projekt erstellten GCS-Buckets zusammen mit dem Label gelöscht, das Sie dem GCS-Modul hinzugefügt haben.

Sie können sich die folgende Ausgabe in Ihrem Terminal ansehen.

[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

Führen Sie exit aus, um den Testcontainer zu beenden.

9. Dokumentation für Ein- und Ausgaben generieren

Die Eingabe- und Ausgabetabellen in den README-Dateien des Stammmoduls, der Submodule und der Beispielmodule werden automatisch anhand der variables und outputs der jeweiligen Module generiert. Diese Tabellen müssen aktualisiert werden, wenn die Modulschnittstellen geändert werden.

Ausführen:

make generate_docs
# This will generate new Inputs and Outputs tables

10. Lint-Tests in CFT ausführen

Ein Linter ist ein Tool, das Quellcode analysiert, um Programmierfehler, Programmfehler, stilistische Fehler und verdächtige Konstrukte zu kennzeichnen.

Viele der Dateien im Repository können mit Lint ausgewertet oder formatiert werden, um einen Qualitätsstandard aufrechtzuerhalten. Um die Qualität von CFT zu gewährleisten, verwenden Sie einen Lint-Test.

Ausführen:

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

11. PR auf GitHub einreichen

Nachdem Sie nun Ihren Code lokal geändert und über die Integrationstests getestet haben, sollten Sie diesen Code im Master-Repository veröffentlichen.

Um Ihren Code im Master-Repository zur Verfügung zu stellen, müssen Sie Codeänderungen in Ihrem Zweig per Commit durchführen und ihn per Push in das Master-Repository übertragen. Damit Ihr Code dem Haupt-Repository hinzugefügt wird, das Sie zu Beginn des Codelabs abgespalten haben, lösen Sie eine Pull-Anfrage (Pull Request, PR) im Master-Repository aus, nachdem Sie den Code per Commit an das Repository übergeben haben.

Wenn Sie eine PR-Anfrage stellen, wird der Repository-Administrator aufgefordert, die vorgeschlagenen Codeänderungen zu überprüfen. Außerdem können Sie andere Nutzer als Prüfer hinzufügen, um Feedback zu Ihren Codeänderungen zu erhalten. Die PR löst einen Cloud Build aus, der Tests für das Repository ausführt.

Auf der Grundlage Ihrer Codeänderungen geben Codeprüfer Kommentare zu Ihrem Code und bitten um Änderungen, wenn etwas basierend auf den Best Practices und der Dokumentation geändert werden muss. Der Administrator prüft Ihre Codeänderungen, stellt sicher, dass Ihr Code mit dem Repository kompatibel ist, und fordert Sie möglicherweise noch einmal auf, einige Änderungen vorzunehmen, bevor Sie Ihren Code im Master-Repository zusammenführen.

Führen Sie die folgenden Schritte aus, um Code an den verzweigten Branch per Commit zu übergeben und an den verzweigten Branch per Push zu übertragen:

Der erste Schritt besteht darin, geänderte Dateien in das lokale Repository einzufügen.

$ 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

Ihre Dateien sind jetzt bereit. Als Nächstes übernehmen Sie die Änderungen.

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

Übertragen Sie die per Commit durchgeführten Änderungen in Ihrem lokalen Repository per Push an GitHub, um eine Pull-Anfrage (Pull-Anfrage) zu erstellen.

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

Ihre Codeänderungen können nun per Pull-Anfrage abgerufen werden.

Führen Sie die folgenden Schritte aus, um eine PR-Datei für das Repository terraform-google-modules/terraform-google-cloud-storage zu erstellen:

Rufen Sie in Ihrem Webbrowser die Hauptseite des Repositorys auf.
Sie sehen über ein Banner einen Vorschlag, eine PR aus Ihrer Fork zu öffnen. Klicken Sie auf „Vergleichen und Anfrage abrufen“.

Geben Sie einen Titel und eine Beschreibung für Ihre Pull-Anfrage ein, um Ihre Codeänderungen zu beschreiben. Seien Sie so konkret wie möglich und fassen Sie sich kurz.

Um eine Pull-Anfrage zu erstellen, die überprüft werden kann, klicken Sie auf „Pull-Anfrage erstellen“.
Es werden ausgeführte Cloud Build-Trigger angezeigt, die aufgrund des PR ausgelöst werden.
Falls Probleme auftreten, lesen Sie die offiziellen GitHub-Dokumentation zum Öffnen von Pull-Anfragen aus Forks.

Sie haben Ihre erste Codeänderung erfolgreich an Ihren Forked Branch übertragen und Ihre erste CFT PR gegen den Master-Branch angehoben!

12. Glückwunsch

Herzlichen Glückwunsch! Sie haben einem Modul zu CFT erfolgreich eine Funktion hinzugefügt und eine PR zur Überprüfung eingereicht.

Sie haben einem CFT-Modul eine Funktion hinzugefügt, sie lokal anhand eines Beispiels getestet und Tests durchgeführt, bevor Sie Ihren Code per Commit an GitHub übergeben. Schließlich haben Sie einen PR zur Überprüfung eingereicht und die endgültige Zusammenführung in CFT.

Sie kennen jetzt die wichtigen Schritte zum Einstieg in das Cloud Foundation Toolkit.