Grundlagen-Toolkit Teil 1

1. Einführung in CFT 101

Zuletzt aktualisiert:03.03.2020

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

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

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

Neueste Version von Git herunterladen und 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 dies nur auf zukünftige Commits aus. Der Name, der für frühere Commits verwendet wurde, bleibt davon unberührt.

Git-Nutzernamen für jedes Repository auf Ihrem Computer festlegen

Mac/Linux: Öffnen Sie ein Terminal.

Für Windows: Git-Bash öffnen

Legen Sie einen Git-Nutzernamen fest:

$ git config --global user.name "Your Name"

$ git config --global user.email "[e-mail]"

Prüfen Sie, ob Sie den Git-Nutzernamen richtig festgelegt haben:

$ git config --list

> Your Name

> Your Email

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:

1. Ö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.
2. Klicken Sie in der rechten oberen Ecke der Seite auf Fork.

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

Der von Ihnen erstellte Fork 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:

1. Öffnen Sie Ihren Webbrowser und gehen Sie zu Ihrer Verzweigung in terraform-google-modules/terraform-google-cloud-storage.
2. Oben rechts sehen Sie die Option „Klonen oder herunterladen“. klicken Sie darauf.

3. Nachdem Sie auf die Schaltfläche „Klonen oder herunterladen“ klicken Sie auf die Schaltfläche "Editor" um die URL der Verzweigung zu kopieren. Mit dieser URL klonen Sie die Verzweigung in Ihrer lokalen Umgebung.

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

5. Nachdem Sie die Verzweigung 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 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 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.

Hinweis:Wenn Sie Cloud Shell verwenden, müssen Sie Docker nicht installieren, da es in Cloud Shell bereits vorhanden ist.

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 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. Rolle „Rechnungskontonutzer“ für die Rechnungskontoressource zuweisen

4.1 IAM-Richtlinie für Rechnungskonto abrufen

Vorhandene IAM-Richtlinienbindungen für das Rechnungskonto herunterladen

gcloud beta billing accounts get-iam-policy ${TF_VAR_billing_account} | tee policy.yml

4.2 Richtlinie aktualisieren, um das Dienstkonto einzubeziehen

Aktualisieren Sie die Datei policy.yml, um dem Dienstkonto eine neue Bindung mit der Rolle roles/billing.user hinzuzufügen

bindings:
- members:
  - serviceAccount:cft-onboarding@<YOUR_PROJECT_ID>.iam.gserviceaccount.com
  role: roles/billing.user

4.3 Richtlinien für Rechnungskonto aktualisieren

Änderungen auf das Rechnungskonto anwenden

gcloud beta billing accounts set-iam-policy ${TF_VAR_billing_account} policy.yml

5. Terraform-Anmeldedaten vorbereiten

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

5.1 Dienstkontoschlüssel

Dienstkontoschlüssel für Terraform erstellen und herunterladen

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

5.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)

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

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(element(var.names, count.index))}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

Nun fügen Sie 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 29 in „variables.tf“ ein. Achten Sie darauf, dass über und unter dem Variablenblock, den Sie hinzufügen, ein Zeichen für eine neue Zeile 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 von einem Display 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. Inspektionstest zur Prüfung der Funktion schreiben

Sie haben Ihre Funktion zur "main.tf" des Moduls hinzugefügt und dann zum "multiple_buckets"-Beispiel hinzugefügt, um sie über die Befestigung zu testen. Sie müssen Ihr Feature über einen InSpec-Integrationstest testen, der in Ruby geschrieben ist.

Sie fügen Ihre neuen Tests der Datei gsutil.rb 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 die Labels der einzelnen Buckets mit dem gsutil-Befehl ab und prüfen dann die ausgegebene Ausgabe des Befehls.

terraform-google-cloud-storage/test/integration/multiple-buckets/controls/gsutil.rb

control "gsutil" do
 <..>

# CODELAB: Copy paste the below test in gsutil.rb to test silly_label feature.

# command to get the labels for bucket_1
describe command("gsutil label get gs://#{attribute("names_list")[0]}") do
   //check if the command gave a valid response
   its(:exit_status) { should eq 0 }
   its(:stderr) { should eq "" }

   //parse the command's output into JSON
   let!(:data) do
     if subject.exit_status == 0
         JSON.parse(subject.stdout)
     else
         {}
     end
   end

   # check if bucket_1 has the new "silly" label with the value "awesome"
   describe "bucket_1" do
   it "has label" do
       data.each do |bucket|
           expect(data["silly"]).to include("awesome")
       end
     end
   end
 end

8. Integrationstests in CFT ausführen

Integrationstests

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

Die Integrationstests werden mit Kitchen, Kitchen-Terraform und InSpec ausgeführt. Diese Tools sind der Einfachheit halber in einem Docker-Image verpackt.

Bei diesen Tests wird generell das Verhalten der Beispielmodule überprüft und somit sichergestellt, 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.

1. 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]

2. Führen Sie kitchen_do list aus, um alle Instanzen in Ihrem Arbeitsbereich aufzulisten, die Integrationstests enthalten.

    You will see the below output in your terminal.
   

[root@<CONTAINER_ID> workspace]# kitchen_do list
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
Instance                  Driver     Provisioner  Verifier   Transport  Last Action  Last Error
multiple-buckets-default  Terraform  Terraform    Terraform  Ssh        Verified     <None>

3. Führen Sie kitchen_do create <EXAMPLE_NAME> aus, um das Arbeitsverzeichnis für ein Beispielmodul zu initialisieren.

Mit diesem Schritt wird die Küche und Terraform im Arbeitsbereich initialisiert.

Sie sehen die folgende Ausgabe in Ihrem Terminal.

[root@<CONTAINER_ID> workspace]# kitchen_do create multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
-----> Starting Kitchen (v1.24.0)
-----> Creating <multiple-buckets-default>...
       Terraform v0.12.12
       + provider.google v3.10.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from www.terraform.io/downloads.html
$$$$$$ Running command `terraform init -input=false -lock=true -lock-timeout=0s  -upgrade -force-copy -backend=true  -get=true -get-plugins=true -verify-plugins=true` in directory /workspace/test/fi
xtures/multiple_buckets
       Upgrading modules...
       - example in ../../../examples/multiple_buckets
       - example.cloud_storage in ../../..
       
       Initializing the backend...
       
       Initializing provider plugins...
       - Checking for available provider plugins...
       - Downloading plugin for provider "google" (hashicorp/google) 2.18.1...
       - Downloading plugin for provider "random" (hashicorp/random) 2.2.1...
       
       Terraform has been successfully initialized!
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
       Finished creating <multiple-buckets-default> (0m11.01s).
-----> Kitchen is finished. (0m12.62s)

4. Führen Sie kitchen_do converge <EXAMPLE_NAME> aus, um das Beispielmodul anzuwenden.

In diesem Schritt wird der im vorherigen Schritt erstellte Terraform-Arbeitsbereich auf das zuvor im Codelab erstellte GCP-Projekt angewendet.

Sie sehen die folgende Ausgabe in Ihrem Terminal.

[root@<CONTAINER_ID> workspace]# kitchen_do converge multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<YOUR_PROJECT_ID>.iam.gserviceaccount.com]
-----> Starting Kitchen (v1.24.0)
-----> Converging <multiple-buckets-default>...
       Terraform v0.12.20
       + provider.google v3.9.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from https://www.terraform.io/downloads.html
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
$$$$$$ Running command `terraform get -update` in directory /workspace/test/fixtures/multiple_buckets
       - example in ../../../examples/multiple_buckets
       - example.cloud_storage in ../../..
$$$$$$ Running command `terraform validate   ` in directory /workspace/test/fixtures/multiple_buckets
       Success! The configuration is valid.
       
$$$$$$ Running command `terraform apply -lock=true -lock-timeout=0s -input=false -auto-approve=true  -parallelism=10 -refresh=true  ` in directory /workspace/test/fixtures/multiple_buckets
       random_pet.main: Creating...
       random_pet.main: Creation complete after 0s [id=<BUCKET-ID>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Creating...
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Creating...
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Creation complete after 3s [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Creation complete after 3s [id=<BUCKET-ID-02>]
       
       Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
       
       Outputs:
       
       names = {
         "one" = "<BUCKET-ID-01>"
         "two" = "<BUCKET-ID-02>"
       }
       names_list = [
         "<BUCKET-NAME-01>",
         "<BUCKET-NAME-02>",
       ]
       project_id = ci-cloud-storage-ae79
       Finished converging <multiple-buckets-default> (0m7.17s).
-----> Kitchen is finished. (0m8.77s)

5. Führen Sie kitchen_do verify <EXAMPLE_NAME> aus, um das Beispielmodul zu testen.

In diesem Schritt wird die Datei gsutils.rb ausgeführt, die Tests für das Modul multiple_buckets enthält. Für jeden Test gibt es einen gsutil-Befehl, der für das Testprojekt ausgeführt wird, das Sie zuvor mit den Anmeldedaten für das Dienstkonto erstellt haben.

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.

multiple_buckets local: Verifying

Profile: multiple_buckets
Version: (not specified)
Target:  local://

  ✔  gsutil: gsutil
     ✔  Command: `gsutil ls -p <PROJECT_ID>` exit_status should eq 0
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stderr should eq ""
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stdout should include "multiple-buckets-mzgy-eu-one"
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stdout should include "<BUCKET-ID-01>"
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` stdout should include "Enabled: True"
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` stderr should eq ""
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` stdout should include "Enabled: False"
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` bucket_1 has label
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` stderr should eq ""
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` bucket_2 has label
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq "NEARLINE"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq "SetStorageClass"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq 10
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq false
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq ["MULTI_REGIONAL", "STANDARD", "DURABLE_REDUCED_AVAILABILITY"]
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq "NEARLINE"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq "SetStorageClass"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq 10
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq false
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq ["MULTI_REGIONAL", "STANDARD", "DURABLE_REDUCED_AVAILABILITY"]
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` stderr should eq ""


Profile Summary: 1 successful control, 0 control failures, 0 controls skipped
Test Summary: 30 successful, 0 failures, 0 skipped
       Finished verifying <multiple-buckets-default> (0m8.83s).
-----> Kitchen is finished. (0m16.61s)

6. Führen Sie kitchen_do destroy <EXAMPLE_NAME> aus, um den Beispielmodulstatus zu löschen.

Durch diesen Schritt wird der Arbeitsbereich gelöscht, den 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]# kitchen_do destroy multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [[e-mail]]
-----> Starting Kitchen (v1.24.0)
-----> Destroying <multiple-buckets-default>...
       Terraform v0.12.12
       + provider.google v3.10.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from www.terraform.io/downloads.html
$$$$$$ Running command `terraform init -input=false -lock=true -lock-timeout=0s  -force-copy -backend=true  -get=true -get-plugins=true -verify-plugins=true` in directory /workspace/test/fixtures/mu
ltiple_buckets
       Initializing modules...
       
       Initializing the backend...
       
       Initializing provider plugins...
       
       Terraform has been successfully initialized!
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
$$$$$$ Running command `terraform destroy -auto-approve -lock=true -lock-timeout=0s -input=false  -parallelism=10 -refresh=true  ` in directory /workspace/test/fixtures/multiple_buckets
       random_string.prefix: Refreshing state... [id=mzgy]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Refreshing state... [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Refreshing state... [id=<BUCKET-ID-02>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Destroying... [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Destroying... [id=<BUCKET-ID-02>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Destruction complete after 1s
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Destruction complete after 2s
       random_string.prefix: Destroying... [id=mzgy]
       random_string.prefix: Destruction complete after 0s
       
       Destroy complete! Resources: 3 destroyed.
$$$$$$ Running command `terraform workspace select default` in directory /workspace/test/fixtures/multiple_buckets
       Switched to workspace "default".
$$$$$$ Running command `terraform workspace delete kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
       Deleted workspace "kitchen-terraform-multiple-buckets-default"!
       Finished destroying <multiple-buckets-default> (0m6.49s).
-----> Kitchen is finished. (0m8.10s)

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

Hinweis: Führen Sie immer generate_docs aus, damit die gesamte Dokumentation vollständig ist.

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.

Für viele Dateien im Repository können Lint- oder Formatierungsfunktionen genutzt 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

Hinweis: Führen Sie immer den Lint-Test aus, da Cloud Build fehlschlägt, wenn das Lint nicht abgeschlossen ist. Führen Sie diesen Befehl aus, bevor Sie Code per Commit an Ihr lokales Repository übertragen.

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 verfügbar zu machen, 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 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:

1. 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/controls/gsutil.rb
# 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

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

3. Ü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 master
# 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 an das Repository terraform-google-modules/terraform-google-cloud-storage zu senden:

1. Rufen Sie in Ihrem Webbrowser die Hauptseite des Repositorys auf.
2. Wählen Sie im Branch-Menü die Verzweigung aus, die Ihre Commits enthält.
3. Rechts neben „Zweig“ auf "Neue Pull-Anfrage".

4. Die Basis „base“ verwenden Drop-down-Menü zur Auswahl des Zweigs, in dem Sie Ihre Änderungen zusammenführen möchten. In der Regel ist dies der „Master“. da Sie Codeänderungen an Ihrer Verzweigung per Commit übergeben haben.
5. 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.
6. Um eine Pull-Anfrage zu erstellen, die überprüft werden kann, klicken Sie auf „Pull-Anfrage erstellen“.

7. Es werden ausgeführte Cloud Build-Trigger angezeigt, die aufgrund des PR ausgelöst werden.

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.