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 Grunde bietet CFT Best-Practice-Vorlagen für den 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 auf Ihrem Computer installiert oder Cloud Shell verwenden ( Mac-Installation, Windows-Installation)
Code-Editor zum Bearbeiten von Code (Beispiel: Visual Studio Code)
Grundlegende Kenntnisse zu Git und GitHub
Einige Erfahrung mit Terraform und Infrastruktur als Code
Berechtigung, einem Dienstkonto die Rolle „Ersteller von Projekten“ zu erteilen
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 für Beiträge zu CFT einrichten
Einem CFT-Modul eine Funktion hinzufügen
Tests für die hinzugefügte Funktion hinzufügen
Integrationstests in CFT ausführen
Lint-Tests ausführen
Code auf GitHub committen und einen Pull-Request (PR) einreichen

Führen Sie alle oben genannten Schritte aus, indem Sie dem CFT-Modul für Google Cloud Storage eine neue Funktion hinzufügen. Sie fügen ein Label namens "silly_label" hinzu, das automatisch allen über das GCS CFT-Modul erstellten Buckets hinzugefügt wird. Außerdem schreiben Sie Tests, um Ihr Feature zu validieren und die End-to-End-Integration sicherzustellen.

2. Entwicklungsumgebung einrichten

Sie können Cloud Shell auch für Entwicklungszwecke 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 alle GitHub-bezogenen Vorgänge verantwortlich, die lokal auf Ihrem Computer oder in Ihrer Cloud Shell stattfinden.

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 mit einer Identität zu verknüpfen. Der Git-Nutzername ist nicht mit Ihrem GitHub-Nutzernamen identisch.

Sie können den Namen, der mit Ihren Git-Commits verknüpft ist, mit dem Befehl „git config“ ändern. Wenn Sie den mit Ihren Git-Commits verknüpften Namen mit git config ändern, wirkt sich das nur auf zukünftige Commits aus. Der Name, der für bisherige Commits verwendet wurde, bleibt unverändert.

Sie haben Git erfolgreich eingerichtet und sollten nun in der Lage sein, Branches zu forken, zu erstellen und zu klonen. Wir werden Git in diesem Codelab intensiv verwenden.

3. GCS-Repository von CFT verzweigen

CFT-Repository verzweigen

Sie haben Git im vorherigen Schritt auf Ihrem lokalen Computer oder in Cloud Shell 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. Wenn Sie ein Repository forken, können Sie Änderungen frei testen, ohne dass das ursprüngliche Projekt davon betroffen ist.

Am häufigsten werden Forks verwendet, um entweder Änderungen am Projekt einer anderen Person vorzuschlagen oder das Projekt einer anderen Person als Ausgangspunkt für Ihre eigene Idee zu verwenden.

Mithilfe von Forks können Sie beispielsweise Änderungen zur Behebung eines Bugs vorschlagen. So beheben Sie einen Fehler:

Verzweigen Sie das Repository.
Nehmen Sie die Korrektur vor.
Reichen Sie einen Pull-Request an den Projektinhaber ein.

So erstellst du ein Fork 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.

Sie können auswählen, wo die Verzweigung gespeichert werden soll. Wählen Sie Ihr Profil aus und das Repository wird 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 rufen Sie Ihre 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 der Fork zu kopieren. Über diese URL können Sie Ihre Fork in Ihre lokale Umgebung klonen.

Öffnen Sie ein Terminal in VS Code oder auf Ihrem Computer und klonen Sie die Fork.

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

Sie können Ihren Branch gemäß der Konvention so benennen:

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

Da Sie eine neue Funktion 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 der Arbeit am Cloud Foundation Toolkit beginnen.

4. Testumgebung erstellen

Der standardmäßige CFT-Entwicklungsprozess basiert auf der Verwendung eines isolierten Testprojekts. 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

Sie müssen das Google Cloud SDK nicht installieren, wenn Sie die Cloud Shell der Google Cloud verwenden.

Rufen Sie 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 in 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 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 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, 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 das 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"

Sie haben jetzt ein Dienstkonto, das zur Verwaltung der Testumgebung verwendet werden kann.

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

Geben Sie den Schlüssel über die Umgebungsvariable SERVICE_ACCOUNT_JSON an Terraform weiter und legen Sie den Wert auf den Inhalt 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 bei Bedarf später mit demselben Befehl wie oben 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, wird die folgende Ausgabe angezeigt. Am Ende erhalten Sie die Test-Projekt-ID, unter der Sie Ihr Cloud Storage-Modul mit der neuen Funktion bereitstellen und 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. CFT-Modul eine neue Funktion hinzufügen

Nachdem Sie die Entwicklungs- und Testumgebung eingerichtet haben, fügen Sie dem CFT-Modul „google-cloud-storage“ die Funktion „silly_label“ hinzu.

Achten Sie darauf, dass Sie sich im Ordner „terraform-google-cloud-storage“ befinden, und öffnen Sie die Datei „main.tf“, wie in der folgenden Verzeichnisstruktur dargestellt.

Da „silly_label“ ein Label ist, fügen Sie die Funktion in Zeile 27 in der Variablen „labels“ in main.tf hinzu, wie unten dargestellt:

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 jetzt die Variable „silly_label“ in die Datei „variables.tf“ ein, die Sie in der obigen Ordnerstruktur sehen.

Fügen Sie den folgenden Code in Zeile 31 von „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. Beispiel für einen Speicher-Bucket um eine neue Funktion ergänzen

Sie haben die Funktion der main.tf-Datei des Moduls hinzugefügt und testen sie jetzt anhand eines Beispiels.

Das "silly_label" muss zu "examples/multiple-buckets/main.tf" hinzugefügt werden

Dieses Beispiel wird im nächsten Schritt für Integrationstests verwendet.

Fügen Sie die folgende Zeile für die Variable „silly_label“ in Zeile 27 in „main.tf“ unter „terraform-google-cloud-storage/examples/multiple-buckets/“ ein (wie in der Ordnerstruktur zu sehen):

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 zum Prüfen der Funktion aktualisieren

Sie haben die Funktion der main.tf-Datei des Moduls und dann dem Beispiel „multiple_buckets“ hinzugefügt. Jetzt müssen Sie Ihre Funktion mit einem Blueprint-Integrationstest in Golang testen.

Fügen Sie Ihre neuen Tests der Datei „multiple_buckets_test.go“ in der folgenden Ordnerstruktur hinzu:

Sie haben allen über das Modul „multiple_buckets“ erstellten Bucket das Label „silly_label“ hinzugefügt und müssen jetzt Tests schreiben, um die neue Funktion zu testen.

Im folgenden Code wird das Label jedes Buckets über den Befehl „gcloud alpha storage“ abgerufen und dann wird die zurückgegebene Ausgabe des Befehls geprüft.

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 Fehlerkorrekturen sollten mit Tests begleitet werden.

Die Integrationstests werden mit dem Blueprint-Test-Framework geschrieben und mit der CFT-Befehlszeile ausgeführt. Diese Tools sind aus praktischen Gründen in einem Docker-Image verpackt.

Bei diesen Tests wird in der Regel das Verhalten der Beispielmodule überprüft, um sicherzustellen, dass das Stammmodul, die Untermodule und die Beispielmodule funktional korrekt sind.

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 Build-Automatisierungstool, mit dem ausführbare Programme und Bibliotheken automatisch aus dem Quellcode erstellt werden. Dazu werden Dateien namens Makefiles gelesen, in denen angegeben ist, wie das Zielprogramm abgeleitet werden soll. 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 cft test list aus, 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 init aus, um das Beispiel zu initialisieren. In diesem Fall ist das cft test run TestMultipleBuckets --stage init, um den Test TestMultipleBuckets zu initialisieren. Außerdem können Sie das Flag --verbose verwenden, um beim Ausführen von Tests zusätzliche Informationen abzurufen.

In dieser Phase wird das Terraform-Beispiel initialisiert.

In Ihrem Terminal wird die folgende Ausgabe 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 apply aus, um das Beispielmodul anzuwenden.

In diesem Schritt wird das in der vorherigen Phase initialisierte Beispiel auf das GCP-Projekt angewendet, das Sie zuvor im Codelab erstellt haben.

Im Terminal wird die folgende Ausgabe 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 verify aus, um zu prüfen, ob im Beispiel die erwartete Infrastruktur erstellt wurde.

In diesem Schritt wird die Funktion „verify“ 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.

Falls Fehler auftreten, sehen Sie, was erwartet wurde und was vom Befehl für den Test empfangen wurde.

Im Terminal wird die folgende Ausgabe angezeigt.

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. Außerdem werden die im Projekt erstellten GCS-Buckets und das 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 verlassen.

9. Dokumentation für Eingaben und Ausgaben generieren

Die Tabellen „Inputs“ und „Outputs“ in den README-Dateien des Stammmoduls, der Untermodule 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, Bugs, Stilfehler und verdächtige Konstrukte zu melden.

Viele der Dateien im Repository können mit Lint versehen oder formatiert werden, um einen Qualitätsstandard aufrechtzuerhalten. Um die Qualität bei 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 ihn mithilfe der Integrationstests getestet haben, sollten Sie ihn 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 geforkt haben, müssen Sie einen Pull-Request (PR) für das Master-Repository stellen, nachdem Sie Code in Ihr Repository gesendet haben.

Wenn Sie einen Pull-Request stellen, 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 PR löst einen Cloud Build aus, bei dem Tests im Repository ausgeführt werden.

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 übereinstimmt, und bittet Sie möglicherweise noch einmal, einige Änderungen vorzunehmen, bevor Ihr Code in das Master-Repository zusammengeführt wird.

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 dem lokalen Repository hinzuzufü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 Commits in Ihrem lokalen Repository per Push auf GitHub, um einen 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 können nun per Pull-Anfrage abgerufen werden.

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

Rufen Sie in Ihrem Webbrowser die Hauptseite des Repositorys auf.
Sie sehen dann ein Banner mit der Aufforderung, einen 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 dabei so konkret wie möglich, aber prägnant.

Klicken Sie auf „Pull-Anfrage erstellen“, um eine Pull-Anfrage zu erstellen, die zur Überprüfung bereit ist.
Sie sehen Cloud Build-Trigger, die aufgrund des PR ausgelöst werden.
Weitere Informationen finden Sie in der offiziellen GitHub-Dokumentation zum Öffnen von Pull-Anfragen über Forks.

Sie haben Ihre erste Codeänderung erfolgreich in Ihren forkierten Branch gepusht und Ihren ersten CFT-PR für den Master-Branch erstellt.

12. Glückwunsch

Glückwunsch! Sie haben einem CFT-Modul eine Funktion hinzugefügt und einen 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 auf GitHub gesendet haben. Schließlich haben Sie einen PR zur Überprüfung und endgültigen Zusammenführung in CFT eingereicht.

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