1. Einführung in CFT 101
Zuletzt aktualisiert: 11.02.2022
Was ist das Cloud Foundation Toolkit?
Im Wesentlichen bietet CFT 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
- Docker ist auf Ihrem Computer installiert oder Sie verwenden Cloud Shell ( Mac-Installation, Windows-Installation).
- Code-Editor zum Bearbeiten von Code (z. B. Visual Studio Code)
- Grundlegende Kenntnisse von Git und GitHub
- Etwas Erfahrung mit Terraform und Infrastruktur als Code
- Berechtigung zum Zuweisen der Rolle „Projektersteller“ für ein Dienstkonto
- Eine Google Cloud-Organisation, ein Testordner und ein Rechnungskonto
Umfang
In diesem Codelab erfahren Sie, wie Sie zum Cloud Foundation Toolkit (CFT) beitragen können.
Sie werden Folgendes tun:
- Entwicklungsumgebung für Beiträge zu CFT einrichten
- Funktion zu einem CFT-Modul hinzufügen
- Tests für das hinzugefügte Feature hinzufügen
- Integrationstests in CFT ausführen
- Lint-Tests ausführen
- Code in GitHub committen und eine Pull-Anfrage senden
Sie führen alle oben genannten Schritte aus, indem Sie dem Google Cloud Storage CFT-Modul eine neue Funktion hinzufügen. Sie fügen das Label "silly_label" hinzu, das automatisch allen Buckets hinzugefügt wird, die über das GCS-CFT-Modul erstellt wurden. Außerdem können Sie Tests schreiben, um Ihr Feature zu validieren und die End-to-End-Integration sicherzustellen.
2. Entwicklungsumgebung einrichten
Sie können die Cloud Shell für Ihre Entwicklungszwecke verwenden. Wenn Sie Cloud Shell nicht verwenden möchten, um zu CFT beizutragen, können Sie Ihre Entwicklungsumgebung auf Ihrem Computer einrichten.
Git einrichten
GitHub basiert auf einem Open-Source-Versionsverwaltungssystem (VCS) namens Git. Git ist für alles verantwortlich, was lokal auf Ihrem Computer oder in Ihrer Cloud Shell mit GitHub zu tun hat.
- 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.
Nutzernamen und E-Mail-Adresse in Git festlegen
Git verwendet einen Nutzernamen, um Commits einer Identität zuzuordnen. Der Git-Nutzername ist nicht derselbe wie Ihr GitHub-Nutzername.
Mit dem Befehl „git config“ können Sie den Namen ändern, der mit Ihren Git-Commits verknüpft ist. Wenn Sie den Namen ändern, der mit Ihren Git-Commits verknüpft ist, indem Sie git config verwenden, wirkt sich dies nur auf zukünftige Commits aus. Der Name, der für frühere Commits verwendet wurde, wird nicht geändert.
Sie haben Git erfolgreich eingerichtet und sollten in der Lage sein, Branches zu forken, zu erstellen und zu klonen. In diesem Codelab verwenden wir Git sehr häufig.
3. CFT-GCS-Repository forken
CFT-Repository forken
Sie haben Git im vorherigen Schritt auf Ihrem lokalen Computer oder in Cloud Shell eingerichtet. Jetzt müssen Sie das Google Cloud Storage-CFT-Repository forken, um mit der Mitwirkung zu beginnen.
Ein Fork ist eine Kopie eines Repositorys. Wenn Sie ein Repository forken, können Sie Änderungen daran vornehmen, ohne dass das Originalprojekt beeinträchtigt wird.
Forks werden am häufigsten verwendet, um Änderungen an einem Projekt eines anderen Nutzers vorzuschlagen oder das Projekt eines anderen Nutzers als Ausgangspunkt für eine eigene Idee zu verwenden.
Sie können beispielsweise Forks verwenden, um Änderungen vorzuschlagen, die sich auf die Behebung eines Fehlers beziehen. So können Sie einen Fehler beheben:
- Verzweigen Sie das Repository.
- Beheben Sie das Problem.
- Senden Sie eine Pull-Anfrage an den Projektinhaber.
So forken Sie ein CFT-Repository:
- Ö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.
- Sie werden gefragt, wo Sie die Verzweigung erstellen möchten. Wählen Sie Ihr Profil aus. Das Repository wird dann verzweigt.
Verzweigung lokal klonen
Der von Ihnen erstellte Fork ist eine Kopie des GCS-Modul-Repositorys. Sie klonen dieses Repository nun in Ihre lokale Umgebung, um die neue Funktion hinzuzufügen.
So klonen Sie Ihre Verzweigung:
- Öffnen Sie Ihren Webbrowser und rufen Sie Ihren Fork unter terraform-google-modules/terraform-google-cloud-storage auf.
- Klicken Sie rechts oben auf die Schaltfläche „Code“.
- Klicken Sie nach dem Klicken auf die Schaltfläche „Code“ auf das Symbol „Kopieren“, um die URL des Forks zu kopieren. Sie verwenden diese URL, um Ihre Verzweigung in Ihre lokale Umgebung zu klonen.
- Rufen Sie in VSCode oder auf Ihrem Computer ein Terminal auf und klonen Sie den Fork.
$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.
- Nachdem Sie Ihren Fork lokal geklont haben, sollten Sie zu Ihrem Repository wechseln, einen neuen Branch aus dem Fork erstellen und Codeänderungen am temporären Branch vornehmen.
Sie können Ihren Branch folgendermaßen benennen:
- Bei Funktionsanfragen:
feature/feature-name - Für interne Updates:
internal/change-name - Fehlerkorrekturen:
bugfix/issue-name
Da Sie ein neues Feature hinzufügen, können Sie Ihren temporären Branch feature/silly_label nennen.
$ 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 können jetzt mit dem Cloud Foundation Toolkit arbeiten.
4. Testumgebung erstellen
Der Standard-CFT-Entwicklungsprozess basiert auf der Verwendung eines isolierten Testprojekts für Tests. In diesem Schritt wird beschrieben, wie Sie das Testprojekt (basierend auf einer Standardkonfiguration) über ein Dienstkonto erstellen.
0. Docker Engine installieren
Wenn Sie Ihren Computer für Entwicklungszwecke verwenden, müssen Sie die Docker Engine installieren.
1. Google Cloud SDK installieren
Wenn Sie die Cloud Shell von 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
Um eine Testumgebung zu erstellen, 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 in Ihre Testumgebung herunterladen. Für dieses Dienstkonto sind die Rollen Projektersteller, Rechnungskontonutzer und Organisationsbetrachter erforderlich. Mit diesen Schritten können Sie ein neues Dienstkonto erstellen. Sie können aber auch ein vorhandenes Konto wiederverwenden.
3.1 GCP-Ausgangsprojekt erstellen oder auswählen
Bevor Sie ein Dienstkonto erstellen, müssen Sie ein Projekt auswählen, in dem es gehostet werden soll. 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 Seed-Projekt:
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, um die Testumgebung zu verwalten:
# 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 Dienstkonto die Rollen „Projektersteller“, „Abrechnungskontonutzer“ und „Organisationsbetrachter“ zuweisen:
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"
Sie haben jetzt ein Dienstkonto, das zur Verwaltung der Testumgebung verwendet werden kann.
4. Terraform-Anmeldedaten vorbereiten
Um die Testumgebung zu erstellen, 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 für Terraform über die Umgebungsvariable SERVICE_ACCOUNT_JSON bereit und legen Sie den Wert auf den Inhalt Ihres Dienstkontoschlüssels fest.
export SERVICE_ACCOUNT_JSON=$(< cft.json)
Nachdem Sie die Anmeldedaten in der Umgebungsvariable gespeichert haben, entfernen Sie die Schlüsseldatei. Bei Bedarf können Sie einen Schlüssel später mit demselben Befehl wie oben neu erstellen.
rm -rf cft.json
5. Testprojekt für Terraform-Bereitstellungen erstellen
Nachdem alles vorbereitet ist, können Sie das Testprojekt mit einem einzigen Befehl erstellen. Führen Sie diesen Befehl aus dem Stammverzeichnis des Verzeichnisses „terraform-google-cloud-storage“ aus:
make docker_test_prepare
Wenn Sie make docker_test_prepare ausführen, wird die folgende Ausgabe angezeigt. Am Ende erhalten Sie die Test-project_id, die erstellt wurde. Dort können Sie Ihr Cloud Storage-Modul mit dem neuen Feature bereitstellen und testen. Wenn beim Verknüpfen eines Rechnungskontos Probleme auftreten, finden Sie hier 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 jetzt ein Testprojekt erstellt, auf das mit „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
Nachdem Sie Ihre Entwicklungs- und Testumgebung eingerichtet haben, können Sie mit dem Hinzufügen der Funktion „silly_label“ zum CFT-Modul „google-cloud-storage“ beginnen.
Achten Sie darauf, dass Sie sich im Ordner „terraform-google-cloud-storage“ befinden, und öffnen Sie die Datei „main.tf“, wie unten in der Ordnerstruktur zu sehen ist.
Da „silly_label“ ein Label ist, fügen Sie das Attribut in Zeile 27 in der Variablen „labels“ in main.tf hinzu, wie unten zu sehen ist:
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 Datei „variables.tf“ ein, die in der oben gezeigten Ordnerstruktur zu sehen ist.
Kopieren Sie den folgenden Code und fügen Sie ihn in Zeile 31 in „variables.tf“ ein. Achten Sie darauf, dass sich über und unter dem hinzugefügten Variablenblock ein Zeilenumbruch befindet.
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. Neue Funktion zum Beispiel für Speicher-Bucket hinzufügen
Sie haben die Funktion der Datei „main.tf“ des Moduls hinzugefügt und testen sie nun anhand eines Beispiels.
Das „silly_label“ muss den Beispielen/multiple-buckets/main.tf hinzugefügt werden.
Dieses Beispiel wird im nächsten Schritt zum Ausführen von Integrationstests verwendet.
Kopieren Sie die folgende Variable „silly_label“ und fügen Sie sie in Zeile 27 in „main.tf“ unter „terraform-google-cloud-storage/examples/multiple-buckets/“ ein, wie in der Ordnerstruktur zu sehen ist:
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 die Funktion der Datei „main.tf“ des Moduls und dann dem Beispiel „multiple_buckets“ hinzugefügt. Jetzt müssen Sie Ihr Feature über einen in Golang geschriebenen Blueprint-Integrationstest testen.
Sie fügen Ihre neuen Tests in der Datei „multiple_buckets_test.go“ hinzu, die sich in der folgenden Ordnerstruktur befindet:
Sie haben das Label „silly_label“ für alle Buckets hinzugefügt, 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 Bucket über den 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
Mit Integrationstests wird das Verhalten des Stammmoduls, der Untermodule und der Beispiele überprüft. Ergänzungen, Änderungen und Korrekturen sollten mit Tests einhergehen.
Die Integrationstests werden mit dem Blueprint-Testframework geschrieben und mit der CFT-CLI ausgeführt. Diese Tools sind zur Vereinfachung in einem Docker-Image verpackt.
Die allgemeine Strategie für diese Tests besteht darin, das Verhalten der Beispielmodule zu überprüfen, um sicherzustellen, dass das Stammmodul, die Untermodule und die Beispielmodule alle funktional korrekt sind.
Bei der interaktiven Ausführung führen Sie jeden Schritt über mehrere Befehle aus.
- Führen Sie
make docker_runaus, um den Docker-Container für Tests im interaktiven Modus zu starten.
Make ist ein Tool zur Build-Automatisierung, mit dem ausführbare Programme und Bibliotheken automatisch aus Quellcode erstellt werden. Dazu werden Dateien mit dem Namen Makefiles gelesen, in denen angegeben ist, wie das Zielprogramm abgeleitet wird. Wenn Sie Änderungen an Dateien 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
module-swapper -registry-prefix=terraform-google-modulesaus, um die Beispiel-main.tf-Dateien so anzupassen, dass die Module aus Ihren lokalen Dateien anstelle der veröffentlichten Module importiert werden.
Die Ausgabe in Ihrem Terminal sollte in etwa so aussehen:
[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
- Führen Sie
cft test listaus, um alle Blueprint-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 initaus, um das Beispiel zu initialisieren. In diesem Fall wird derTestMultipleBuckets-Testlauf mitcft test run TestMultipleBuckets --stage initinitialisiert. Sie können das Flag--verboseverwenden, um beim Ausführen von Tests zusätzliche Informationen zu erhalten.
In dieser Initialisierungsphase wird das Terraform-Beispiel initialisiert.
Die folgende Ausgabe wird im Terminal angezeigt.
[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 applyaus, um das Beispielmodul anzuwenden.
In diesem Schritt wird das im vorherigen Schritt initialisierte Beispiel auf das GCP-Projekt angewendet, das Sie zuvor im Codelab erstellt haben.
Die folgende Ausgabe wird im Terminal angezeigt.
[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 verifyaus, um zu prüfen, ob die erwartete Infrastruktur erstellt wurde.
In diesem Schritt wird die Funktion „verify“ in TestMultipleBuckets ausgeführt. Die Überprüfung erfolgt in der Regel durch Ausführen eines gcloud-Befehls zum Abrufen der JSON-Ausgabe für den aktuellen Status einer Ressource und durch Bestätigen, dass der aktuelle Status dem im Beispiel deklarierten Status entspricht.
Wenn Fehler auftreten, sehen Sie, was erwartet und was vom Befehl für den Test empfangen wurde.
Die folgende Ausgabe wird im Terminal angezeigt.
[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
- Führen Sie
cft test run <EXAMPLE_NAME> --stage teardownaus, um das Beispiel zu beenden.
In diesem Schritt wird die Infrastruktur zerstört, die Sie in den obigen Schritten erstellt haben. In diesem Schritt werden auch die GCS-Buckets zerstört, die im Projekt erstellt wurden, sowie das Label, das Sie dem GCS-Modul hinzugefügt haben.
Die folgende Ausgabe wird in Ihrem Terminal angezeigt.
[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
module-swapper -registry-prefix=terraform-google-modules -restoreaus, um die Anpassungen an denmain.tf-Beispieldateien rückgängig zu machen, die beim letzten Ausführen vonmodule-swappervorgenommen wurden.
[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
- Führen Sie
exitaus, um den Testcontainer zu verlassen.
9. Dokumentation für Ein- und Ausgaben generieren
Die Tabellen „Eingaben“ und „Ausgaben“ in den README-Dateien des Stammmoduls, der Untermodule und der Beispielmodule werden automatisch auf Grundlage von 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, Bugs, stilistische Fehler und verdächtige Konstrukte zu kennzeichnen.
Viele der Dateien im Repository können gelintet oder formatiert werden, um einen Qualitätsstandard aufrechtzuerhalten. Um die Qualität in 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. Pull-Anfrage auf GitHub senden
Nachdem Sie Ihren Code lokal geändert und mit Integrationstests getestet haben, möchten Sie ihn im Master-Repository veröffentlichen.
Damit Ihr Code im Master-Repository verfügbar ist, müssen Sie Codeänderungen in Ihrem Branch committen und per Push in das Master-Repository übertragen. Damit Ihr Code dem Haupt-Repository hinzugefügt wird, das Sie zu Beginn des Codelabs geforkt haben, erstellen Sie einen Pull-Request (PR) für das Master-Repository, nachdem Sie Code in Ihr Repository übertragen haben.
Wenn Sie einen PR erstellen, wird der Repository-Administrator benachrichtigt, damit er die vorgeschlagenen Codeänderungen überprüfen kann. Außerdem können Sie andere Nutzer als Prüfer hinzufügen, um Feedback zu Ihren Codeänderungen zu erhalten. Der Pull-Request löst einen Cloud Build aus, bei dem Tests für das Repository ausgeführt werden.
Basierend auf Ihren Codeänderungen geben Code-Prüfer Kommentare zu Ihrem Code ab und bitten Sie um Änderungen, wenn etwas gemäß Best Practices und Dokumentation geändert werden muss. Der Administrator prüft Ihre Codeänderungen, stellt sicher, dass Ihr Code den Anforderungen des Repository entspricht, und fordert Sie möglicherweise noch einmal auf, einige Änderungen vorzunehmen, bevor Ihr Code in das Master-Repository übernommen wird.
Führen Sie die folgenden Schritte aus, um Code in Ihren geforkten Branch zu übertragen und Code in Ihren geforkten Branch zu pushen:
- Im ersten Schritt fügen Sie die geänderten Dateien dem lokalen Repository hinzu.
$ 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 bereitgestellt. 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 übernommenen Änderungen in Ihrem lokalen Repository per Push an GitHub, um eine Pull-Anfrage (Pull Request, PR) 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 sind jetzt bereit für eine Pull-Anfrage.
Führen Sie die folgenden Schritte aus, um einen Pull-Request für das terraform-google-modules/terraform-google-cloud-storage-Repository zu erstellen:
- Rufen Sie in Ihrem Webbrowser die Hauptseite des repo auf.
- Über ein Banner wird Ihnen vorgeschlagen, einen Pull-Request aus Ihrem Fork zu öffnen. Klicken Sie auf „Vergleichen und Pull-Anfrage“.
- Geben Sie einen Titel und eine Beschreibung für Ihre Pull-Anfrage ein, um Ihre Codeänderungen zu beschreiben. Sei so konkret wie möglich, aber fasse dich kurz.
- Klicken Sie auf „Pull-Anfrage erstellen“, um eine Pull-Anfrage zu erstellen, die zur Überprüfung bereit ist.
- Sie sehen, dass Cloud Build-Trigger ausgeführt werden, die aufgrund des Pull-Requests ausgelöst wurden.
- Wenn Probleme auftreten, lesen Sie die offizielle GitHub-Dokumentation zum Öffnen von Pull-Anfragen aus Forks.
Sie haben Ihre erste Codeänderung erfolgreich in Ihren geforkten Zweig übertragen und Ihren ersten CFT-Pull-Request für den Master-Zweig erstellt.
12. Glückwunsch
Sie haben einem CFT-Modul erfolgreich eine Funktion hinzugefügt und einen PR zur Überprüfung eingereicht.
Sie haben einem CFT-Modul eine Funktion hinzugefügt, sie anhand eines Beispiels lokal getestet und Tests durchgeführt, bevor Sie Ihren Code in GitHub übertragen haben. Schließlich haben Sie einen PR zur Überprüfung und zum endgültigen Zusammenführen in CFT eingereicht.
Sie kennen jetzt die wichtigsten Schritte für den Einstieg in das Cloud Foundation Toolkit.