Dieses Lab wurde mit unserem Partner Hashicorp entwickelt. Ihre personenbezogenen Daten werden möglicherweise an Hashicorp, den Lab-Sponsor, weitergegeben, wenn Sie zugestimmt haben, Produktupdates, Mitteilungen und Angebote in Ihrem Kontoprofil zu erhalten.

GSP752

Übersicht

Um mit Terraform zu arbeiten, müssen Sie den Zustand der verwalteten Infrastruktur und deren Konfiguration in einer Zustandsdatei speichern. Das ist zwingend erforderlich. Mithilfe dieses sogenannten Terraform-Zustands können Sie dann der Konfiguration reale Ressourcen zuordnen, Metadaten im Blick behalten und die Leistung großer Infrastrukturen verbessern.

Standardmäßig speichern Sie den Terraform-Zustand lokal in einer Zustandsdatei namens terraform.tfstate. Bei Bedarf können Sie diese Datei auch remote speichern, was in Teamumgebungen unter Umständen die bessere Lösung ist.

Auf Grundlage der lokalen Zustandsdatei erstellt Terraform Ausführungspläne und führt diese dann an der Infrastruktur durch. Vor jedem Vorgang aktualisiert das Tool die Informationen in der Zustandsdatei und gleicht sie mit der realen Infrastruktur ab.

Im Terraform-Zustand sind die Bindungen zwischen Objekten in einem Remotesystem und den in der Konfiguration deklarierten Ressourceninstanzen gespeichert. Das ist sein Hauptzweck. Wenn Sie die Konfiguration ändern und Terraform daraufhin ein Remoteobjekt erstellt, wird dessen Identität in der Zustandsdatei einer bestimmten Ressourceninstanz zugeordnet. Bearbeiten Sie dann später die Konfiguration, wird das Objekt im Datensatz entsprechend aktualisiert oder gelöscht.

Lernziele

Aufgaben in diesem Lab:

• Backend „local“ erstellen
• Cloud Storage-Backend erstellen
• Terraform-Zustand aktualisieren
• Terraform-Konfiguration importieren
• Importierte Konfiguration mit Terraform verwalten

Einrichtung und Anforderungen

Vor dem Klick auf „Start Lab“ (Lab starten)

Lesen Sie diese Anleitung. Labs sind zeitlich begrenzt und können nicht pausiert werden. Der Timer beginnt zu laufen, wenn Sie auf Lab starten klicken, und zeigt Ihnen, wie lange die Ressourcen für das Lab verfügbar sind.

In diesem praxisorientierten Lab können Sie die Lab-Aktivitäten in einer echten Cloud-Umgebung selbst durchführen – nicht in einer Simulations- oder Demo-Umgebung. Dazu erhalten Sie neue, temporäre Anmeldedaten, mit denen Sie für die Dauer des Labs auf Google Cloud zugreifen können.

Für dieses Lab benötigen Sie Folgendes:

• Einen Standardbrowser (empfohlen wird Chrome)

Hinweis: Nutzen Sie den privaten oder Inkognitomodus, um dieses Lab durchzuführen. So wird verhindert, dass es zu Konflikten zwischen Ihrem persönlichen Konto und dem Teilnehmerkonto kommt und zusätzliche Gebühren für Ihr persönliches Konto erhoben werden.

• Zeit für die Durchführung des Labs – denken Sie daran, dass Sie ein begonnenes Lab nicht unterbrechen können.

Hinweis: Wenn Sie über ein persönliches Google Cloud-Konto oder -Projekt verfügen, verwenden Sie es nicht für dieses Lab. So werden zusätzliche Kosten für Ihr Konto vermieden.

Lab starten und bei der Google Cloud Console anmelden

1. Klicken Sie auf Lab starten. Wenn Sie für das Lab bezahlen müssen, wird ein Pop-up-Fenster geöffnet, in dem Sie Ihre Zahlungsmethode auswählen können. Auf der linken Seite befindet sich der Bereich Details zum Lab mit diesen Informationen:

   • Schaltfläche Google Cloud Console öffnen
   • Restzeit
   • Temporäre Anmeldedaten für das Lab
   • Ggf. weitere Informationen für dieses Lab

2. Klicken Sie auf Google Cloud Console öffnen (oder klicken Sie mit der rechten Maustaste und wählen Sie Link in Inkognitofenster öffnen aus, wenn Sie Chrome verwenden).

   Im Lab werden Ressourcen aktiviert. Anschließend wird ein weiterer Tab mit der Seite Anmelden geöffnet.

   Tipp: Ordnen Sie die Tabs nebeneinander in separaten Fenstern an.

   Hinweis: Wird das Dialogfeld Konto auswählen angezeigt, klicken Sie auf Anderes Konto verwenden.

3. Kopieren Sie bei Bedarf den folgenden Nutzernamen und fügen Sie ihn in das Dialogfeld Anmelden ein.

   {{{user_0.username | "Username"}}}

   Sie finden den Nutzernamen auch im Bereich Details zum Lab.

4. Klicken Sie auf Weiter.

5. Kopieren Sie das folgende Passwort und fügen Sie es in das Dialogfeld Willkommen ein.

   {{{user_0.password | "Password"}}}

   Sie finden das Passwort auch im Bereich Details zum Lab.

6. Klicken Sie auf Weiter.

   Wichtig: Sie müssen die für das Lab bereitgestellten Anmeldedaten verwenden. Nutzen Sie nicht die Anmeldedaten Ihres Google Cloud-Kontos. Hinweis: Wenn Sie Ihr eigenes Google Cloud-Konto für dieses Lab nutzen, können zusätzliche Kosten anfallen.

7. Klicken Sie sich durch die nachfolgenden Seiten:

   • Akzeptieren Sie die Nutzungsbedingungen.
   • Fügen Sie keine Wiederherstellungsoptionen oder Zwei-Faktor-Authentifizierung hinzu (da dies nur ein temporäres Konto ist).
   • Melden Sie sich nicht für kostenlose Testversionen an.

Nach wenigen Augenblicken wird die Google Cloud Console in diesem Tab geöffnet.

Hinweis: Wenn Sie sich eine Liste der Google Cloud-Produkte und ‑Dienste ansehen möchten, klicken Sie oben links auf das Navigationsmenü.

Cloud Shell aktivieren

Cloud Shell ist eine virtuelle Maschine, auf der Entwicklertools installiert sind. Sie bietet ein Basisverzeichnis mit 5 GB nichtflüchtigem Speicher und läuft auf Google Cloud. Mit Cloud Shell erhalten Sie Befehlszeilenzugriff auf Ihre Google Cloud-Ressourcen.

1. Klicken Sie oben in der Google Cloud Console auf Cloud Shell aktivieren .

Wenn Sie verbunden sind, sind Sie bereits authentifiziert und das Projekt ist auf Ihre Project_ID, eingestellt. Die Ausgabe enthält eine Zeile, in der die Project_ID für diese Sitzung angegeben ist:

Ihr Cloud-Projekt in dieser Sitzung ist festgelegt als {{{project_0.project_id | "PROJECT_ID"}}}

gcloud ist das Befehlszeilentool für Google Cloud. Das Tool ist in Cloud Shell vorinstalliert und unterstützt die Tab-Vervollständigung.

2. (Optional) Sie können den aktiven Kontonamen mit diesem Befehl auflisten:

gcloud auth list

3. Klicken Sie auf Autorisieren.

Ausgabe:

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} Um das aktive Konto festzulegen, führen Sie diesen Befehl aus: $ gcloud config set account `ACCOUNT`

4. (Optional) Sie können die Projekt-ID mit diesem Befehl auflisten:

gcloud config list project

Ausgabe:

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Hinweis: Die vollständige Dokumentation für gcloud finden Sie in Google Cloud in der Übersicht zur gcloud CLI.

Zweck des Terraform-Zustands

Eine Zustandsdatei mit dem Terraform-Zustand ist zwingend erforderlich für das Tool. Manchmal taucht die Frage auf, ob Terraform auch ohne Zustandsdatei funktioniert oder ob es möglich ist, mit dem Tool einfach nur Cloud-Ressourcen zu überprüfen. Um mit Terraform in einer solchen Weise zu arbeiten, müssten Sie aber große Mengen komplexer Einstellungen von einem Ort (nämlich der Zustandsdatei) an einen anderen (dem Alternativkonzept) übertragen. Das ist nicht sinnvoll. In diesem Abschnitt erfahren Sie, wieso der Terraform-Zustand eine notwendige Voraussetzung für das Tool ist.

Reale Ressourcen zuordnen

Terraform braucht eine Art Datenbank, in der die Konfiguration in Terraform den realen Ressourcen zugeordnet ist. Enthält die Konfiguration beispielsweise eine Ressource resource "google_compute_instance" "foo", ist diese in der Terraform-Datenbank der Instanz i-abcd1234 zugeordnet.

In Terraform darf jedes Remoteobjekt nur einer einzigen Ressourceninstanz zugeordnet sein. Im Normalfall ist das auch der Standard, weil Terraform selbstständig die Objekte erstellt und in der Zustandsdatei deren Identität einer Instanz zuordnet. Wenn Sie allerdings Objekte importieren, die nicht in Terraform erstellt wurden, darf beim Import jedem dieser Objekte nur jeweils eine Ressourceninstanz zugewiesen werden.

Falls ein Remoteobjekt mit mehr als einer Ressourceninstanz verknüpft ist, kann es in Terraform zu unerwarteten Aktionen bei diesen Objekten kommen, weil die Zuordnung zwischen der Konfiguration und dem Terraform-Zustand des Remoteobjekts nicht mehr eindeutig ist.

Metadaten

Neben der Zuordnung von Ressourcen und Remoteobjekten benötigen Sie für Terraform auch Metadaten, z. B. Ressourcenabhängigkeiten.

Normalerweise legen Sie in Terraform die Abhängigkeitsreihenfolge über die Konfiguration fest. Falls Sie jedoch eine Ressource aus der Terraform-Konfiguration entfernen, kann Terraform die Ressource nur dann löschen, wenn Informationen darüber vorliegen, wie das Tool dabei vorgehen soll. Terraform erkennt, dass für die Ressource eine Zuordnung in der Zustandsdatei der Ressource existiert, nicht aber in der Konfigurationsdatei, und erstellt daher einen Ausführungsplan, um das Element zu löschen. Wenn die Ressource allerdings nicht mehr existiert, liegen in der Konfiguration nicht genügend Informationen über die Abhängigkeitsreihenfolge vor.

Um einen solchen Vorgang korrekt auszuführen, wird deshalb in Terraform eine Kopie der letzten Abhängigkeiten des vorherigen Zustands aufbewahrt. Wenn Sie dann ein oder mehr Elemente aus der Konfiguration löschen, kann Terraform über die Zustandskopie die richtige Reihenfolge für den Löschvorgang ablesen.

Wären die typischen Abhängigkeiten zwischen den verschiedenen Ressourcentypen in Terraform definiert, wäre dieser Zwischenschritt nicht erforderlich. Dann wäre beispielsweise klar, dass Server immer vor dem Subnetz, in das sie eingebunden sind, gelöscht werden müssen. Dieser Ansatz wäre jedoch schnell viel zu komplex: In Terraform müssten nicht nur Informationen über die Bedeutung jeder Ressource und ihrer Funktion in der Cloud vorliegen, sondern auch über die Unterschiede bei den einzelnen Anbietern und die verschiedenen Abhängigkeitsreihenfolgen zwischen den Plattformen.

Aus einem ähnlichen Grund werden in Terraform auch andere Metadaten gespeichert, z. B. ein Zeiger zur zuletzt für die Ressource verwendeten Anbieterkonfiguration, wenn mehrere Anbieter eingesetzt werden.

Leistung

Zusätzlich zu dieser grundlegenden Zuordnung werden bei Terraform die Attributwerte aller Ressourcen des Zustands im Cache gespeichert. Dies ist eine optionale Funktion des Terraform-Zustands. Sie dient lediglich zur Leistungsverbesserung.

Wenn Sie den Befehl terraform plan ausführen, müssen in Terraform die Informationen über den aktuellen Zustand der Ressourcen vollständig vorliegen. Nur dann kann das Tool die für den von Ihnen konfigurierten Zielzustand nötigen Änderungen ermitteln.

Bei kleinen Infrastrukturen kann Terraform automatisch die aktuellen Attribute aller Ressourcen bei den Anbietern abfragen und synchronisieren. Diese Attributsynchronisierung ist für die Befehle plan und apply das Standardverhalten von Terraform.

Bei großen Infrastrukturen wäre dieses Vorgehen jedoch zu langsam. Viele Cloud-Anbieter stellen keine APIs zur Verfügung, über die sich mehrere Ressourcen gleichzeitig abfragen lassen, und die Umlaufzeit für jede Ressource beträgt mehrere hundert Millisekunden. Außerdem haben Cloud-Anbieter fast immer eine API-Ratenbegrenzung. Daher können über Terraform in einer gewissen Zeitspanne nur eine begrenzte Anzahl an Ressourcen abgefragt werden. Als Workaround verwenden Nutzer mit großen Infrastrukturen deswegen die Flags -refresh=false und -target. In einem solchen Fall gilt der im Cache gespeicherte Zustand als der maßgebliche Datensatz.

Synchronisierung

In der Standardkonfiguration wird die Zustandsdatei im aktuellen Arbeitsverzeichnis gespeichert, über das Terraform ausgeführt wurde. Dieser Ansatz ist für den Einstieg ausreichend. Sobald Sie aber Terraform mit einem Team verwenden, ist es wichtig, dass jeder mit derselben Zustandsdatei arbeitet. Nur dann werden alle Vorgänge auf dieselben Remoteobjekte angewendet.

Die empfohlene Lösung in diesem Fall ist ein Remote-Zustand, also eine remote gespeicherte Datei mit dem aktuellen Zustand. Mit einem voll ausgestatteten Zustands-Backend steht in Terraform eine Remote-Sperre zur Verfügung, über die verhindert wird, dass aus Versehen mehrere Nutzer gleichzeitig Terraform ausführen. Damit ist sichergestellt, dass immer die aktuelle Zustandsdatei als Grundlage genommen wird.

Zustandssperre

Wenn das von Ihnen verwendete Backend diesen Ansatz unterstützt, sperrt Terraform die Zustandsdatei für alle Vorgänge, durch die der Zustand verändert werden könnte. Das verhindert, dass andere Nutzer auf die Datei zugreifen und unter Umständen den Zustand beschädigen.

Die Zustandssperre ist automatisiert und blockiert alle Vorgänge, durch die der Zustand verändert werden könnte. Sie erhalten keine eigene Benachrichtigung darüber, dass der Zustand gesperrt wurde. Wenn Terraform die Zustandssperre nicht durchführen kann, stoppt das Programm. Sie selbst können die Zustandssperre über das Flag -lock bei den meisten Befehlen aufheben. Das wird jedoch nicht empfohlen.

Nur wenn die Wiederfreigabe der Zustandsdatei länger als erwartet dauert, gibt Terraform eine Statusmeldung zurück. Andernfalls ist die Zustandsdatei noch gesperrt.

Nicht mit allen Backends ist eine Zustandssperre möglich. Informationen darüber, welche Backendtypen eine Sperre unterstützen, finden Sie in dieser Liste.

Arbeitsbereiche

Wie Vorgänge ausgeführt werden und wo nichtflüchtige Daten – wie der Terraform-Zustand – gespeichert werden, ist abhängig vom Backend, das Sie verwenden. Mit jeder Terraform-Konfiguration ist jeweils immer nur eines verknüpft.

Die in einem Backend gespeicherten nichtflüchtigen Daten sind einem Arbeitsbereich zugeordnet. Anfangs enthält jedes Backend nur einen Arbeitsbereich mit dem Namen Standard und folglich ist auch nur ein Terraform-Zustand mit dieser Konfiguration verknüpft.

In einigen Backends können Sie mehrere, unterschiedlich benannte Arbeitsbereiche einrichten. Das gibt Ihnen die Möglichkeit, mit einer einzigen Konfiguration mehrere Terraform-Zustände zu verknüpfen. Die Konfiguration selbst enthält jedoch weiterhin nur ein Backend. Sie können dieselbe Konfiguration aber mehrfach in separaten Instanzen einsetzen, ohne ein neues Backend einrichten zu müssen oder die Anmeldedaten für die Authentifizierung zu ändern.

Aufgabe 1: Mit Backends arbeiten

Wie der Zustand geladen und wie ein Befehl wie apply ausgeführt wird, ist in Terraform abhängig vom Backend. Diese Abstraktion ermöglicht Ihnen u. a. Zustandsdateien nicht-lokal zu speichern und remote auszuführen.

Standardmäßig ist in Terraform das Backend „local“ eingestellt. Es bietet die Grundfunktionen, an die Sie gewöhnt sind. Dieses Backend wurde in den vorherigen Labs aufgerufen.

Backends haben folgende Vorteile:

• Arbeit im Team: Über Backends können Sie die Zustandsdatei remote speichern und so mit einer Zustandssperre verhindern, dass der Zustand beschädigt wird. Einige Backends wie Terraform Cloud speichern sogar automatisch einen Versionsverlauf der Zustandsänderungen.
• Keine vertraulichen Daten auf dem Laufwerk: Der Zustand wird über Backends on demand abgerufen und ist nur im Arbeitsspeicher gespeichert.
• Remote-Vorgänge: Bei größeren Infrastrukturen oder bestimmten Änderungen kann die Ausführung von terraform apply viel Zeit in Anspruch nehmen. Mit einigen Backends ist es möglich, Vorgänge remote auszuführen. Sie können dann den Computer ausschalten und der von Ihnen gestartete Vorgang wird trotzdem vollständig durchgeführt. Zusammen mit den anderen oben beschriebenen Vorteilen – Remote-Zustand und Zustandssperre – ist diese Funktion besonders in Teamkonstellationen nützlich.

Vollkommen optional: Sie können Terraform erfolgreich einsetzen, ohne etwas über Backends zu wissen oder sie je zu verwenden. Mithilfe von Backends lassen sich jedoch ab einer bestimmten Größe der Infrastruktur gewisse Problemstellungen leichter lösen. Wenn Sie alleine arbeiten, werden Sie wahrscheinlich mit der Standardeinstellung auskommen.

Aber selbst in diesem Fall können Informationen über die allgemeine Funktionsweise von Backends nützlich sein, denn auch das Verhalten des Backends „local“ können Sie beeinflussen.

Backend „local“ hinzufügen

In diesem Abschnitt konfigurieren Sie das Backend „local“.

Wenn Sie das erste Mal ein Backend konfigurieren und damit vom undefinierten Standard zu einer klar beschriebenen Einstellung wechseln, bietet Ihnen Terraform die Möglichkeit, auch die Zustandsdatei in das neue Backend zu migrieren. Auf diese Weise können Sie bei der Umstellung alle vorhandenen Terraform-Zustände behalten.

Als Vorsichtsmaßnahme empfehlen wir jedoch trotzdem, dass Sie die Zustandsdatei vorher manuell sichern. Speichern Sie dafür einfach eine Kopie der Datei terraform.tfstate an einem anderen Ort. Bei der Initialisierung sollte zwar automatisch ein weiteres Back-up gespeichert werden, aber auf diese Weise sind Sie für den Fall der Fälle abgesichert.

Die erste Konfiguration eines Backends verläuft genau so, wie Sie später auch bei jeder weiteren Bearbeitung der Konfiguration vorgehen werden: Sie erstellen eine neue Konfiguration und führen den Befehl terraform init aus. Danach folgen Sie einfach den Anleitungen in Terraform.

1. Erstellen Sie in Cloud Shell in einem neuen Fenster die Konfigurationsdatei main.tf:

touch main.tf

2. Führen Sie den folgenden Befehl aus, um die Projekt-ID abzurufen:

gcloud config list --format 'value(core.project)'

3. Klicken Sie in der Cloud Shell-Symbolleiste auf Editor öffnen. Wenn Sie zwischen Cloud Shell und dem Code-Editor wechseln möchten, klicken Sie entsprechend auf Editor öffnen oder Terminal öffnen. Sie können auch auf In neuem Fenster öffnen klicken, damit der Editor in einem eigenen Tab geöffnet bleibt.

4. Kopieren Sie den Ressourcencode des Cloud Storage-Buckets in die Konfigurationsdatei main.tf und ersetzen Sie bei den Variablen project und name den Blindtext mit der Projekt-ID:

provider "google" { project = "# HIER PROJEKT-ID EINSETZEN" region = "{{{project_0.default_region | REGION}}}" } resource "google_storage_bucket" "test-bucket-for-state" { name = "# HIER PROJEKT-ID EINSETZEN" location = "US" uniform_bucket_level_access = true }

Weitere Informationen über Cloud Storage-Ressourcen finden Sie in der Terraform-Dokumentation.

5. Fügen Sie das Backend „local“ der Datei main.tf hinzu:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

Dadurch wird eine Datei terraform.tfstate im Verzeichnis terraform/state angelegt. Wenn Sie einen anderen Pfad eingeben möchten, bearbeiten Sie die Variable path.

Beim Backend „local“ wird die Zustandsdatei im lokalen Dateisystem gespeichert. Sie können über System-APIs eine Zustandssperre einrichten. Vorgänge werden lokal ausgeführt.

Bevor Sie das konfigurierte Backend verwenden können, müssen Sie es in Terraform initialisieren. Führen Sie dafür terraform init aus. Der Befehl terraform init sollte bei jeder Terraform-Konfiguration immer der erste Schritt sein. Er kann mehrfach und egal von welchem Teammitglied ausgeführt werden. Mit ihm werden alle erforderlichen Maßnahmen zur Vorbereitung der Terraform-Umgebung eingeleitet, darunter auch die Initialisierung des Backends.

In diesen Fällen müssen Sie den Befehl init ausführen:

• Wenn Sie eine neue Umgebung mit einem konfigurierten Backend einrichten
• Wenn Sie die Backend-Konfiguration bearbeiten und z. B. den Backend-Typ ändern
• Wenn Sie die Backend-Konfiguration vollständig entfernen

Es ist nicht nötig, dass Sie sich diese Anwendungsfälle merken. Terraform erkennt automatisch, wenn eine Initialisierung erforderlich ist. Sie erhalten dann eine Fehlermeldung. Terraform führt die Initialisierung nie automatisch durch, u. a. weil vielleicht zusätzliche Informationen vom Nutzer fehlen oder die Zustandsdatei noch migriert werden muss.

6. Klicken Sie in der Cloud Shell-Symbolleiste auf Terminal öffnen und initialisieren Sie dann Terraform:

terraform init

7. Übernehmen Sie die Änderung. Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein:

terraform apply

Im Cloud Shell-Editor sollten Sie jetzt die Zustandsdatei terraform.tfstate im Verzeichnis terraform/state sehen.

8. Untersuchen Sie die Zustandsdatei:

terraform show

Sie sollten jetzt die Ressource google_storage_bucket.test-bucket-for-state angezeigt bekommen.

Cloud Storage-Backend hinzufügen

Bei einem Cloud Storage-Backend wird der Zustand als Objekt in einem konfigurierbaren Präfix eines beliebigen Buckets in Cloud Storage gespeichert. Mit diesem Backend steht Ihnen auch eine Zustandssperre zur Verfügung. Dabei wird der Zustand für alle Vorgänge gesperrt, durch die er verändert werden könnte. Das verhindert, dass andere Nutzer auf die Datei zugreifen und unter Umständen den Zustand beschädigen.

Die Zustandssperre ist automatisiert und blockiert alle Vorgänge, durch die der Zustand verändert werden könnte. Sie erhalten keine eigene Benachrichtigung darüber, dass der Zustand gesperrt wurde. Wenn Terraform die Zustandssperre nicht durchführen kann, stoppt das Programm. Sie selbst können die Zustandssperre über das Flag -lock bei den meisten Befehlen aufheben. Das wird jedoch nicht empfohlen.

1. Öffnen Sie im Editor noch einmal die Datei main.tf. Sie tauschen jetzt das aktuelle Backend „local“ gegen das Backend gcs aus.

2. Wenn Sie die bestehende Backend-Konfiguration ändern möchten, kopieren Sie die folgende Konfiguration in die Datei und ersetzen Sie damit das bisherige Backend local:

terraform { backend "gcs" { bucket = "# HIER NAME DES BUCKETS EINSETZEN" prefix = "terraform/state" } } Hinweis: Ändern Sie unbedingt die Variablendefinition von Bucket. Wenn Sie die Konfiguration nicht bearbeitet haben, setzen Sie hier Folgendes ein: name der Ressource google_storage_bucket. In diesem Bucket wird die Zustandsdatei gehostet.

3. Damit die Zustandsdatei automatisch dorthin migriert wird, initialisieren Sie noch einmal das Backend.

terraform init -migrate-state

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

4. Klicken Sie in der Cloud Console im Navigationsmenü auf Cloud Storage > Buckets.

5. Klicken Sie auf den Bucket und öffnen Sie die Datei terraform/state/default.tfstate. Die Zustandsdatei ist jetzt in einem Cloud Storage-Bucket gespeichert.

Hinweis: Wenn Sie kein Backend mehr verwenden möchten, können Sie die Konfiguration einfach aus der Datei löschen. Terraform erkennt die Änderung dann automatisch und fordert Sie über eine Meldung dazu auf, die Konfiguration neu zu initialisieren – wie bei jeder anderen Bearbeitung auch.

Wenn Sie dann die Initialisierung ausführen, fragt Sie Terraform, ob Sie die Zustandsdatei wieder zurückmigrieren und lokal speichern möchten. Sobald der Vorgang abgeschlossen ist, gelten in Terraform wieder die Standardeinstellungen.

Zustandsdatei aktualisieren

Mit dem Befehl terraform refresh gleichen Sie den Zustand in Terraform bzw. in der Zustandsdatei mit der realen Infrastruktur ab. Darüber können Sie alle Unterschiede zwischen dem letzten und jetzigen Zustand erkennen und die Zustandsdatei aktualisieren.

Hiermit wird also keine Infrastruktur verändert, sondern lediglich die Zustandsdatei angepasst. Wenn Sie die Zustandsdatei daraufhin tatsächlich bearbeiten, sehen Sie diese Änderungen im nächsten Ausführungsplan und können sie dann mit dem Befehl „apply“ umsetzen.

1. Gehen Sie in der Cloud Console zurück zum Storage-Bucket. Markieren Sie das Kästchen neben dessen Namen.

2. Klicken Sie auf den Tab Labels.

3. Klicken Sie auf Label hinzufügen. Setzen Sie Key 1 = key und Value 1 = value.

4. Klicken Sie auf Speichern.

5. Gehen Sie zurück zu Cloud Shell und aktualisieren Sie die Zustandsdatei mit dem folgenden Befehl:

terraform refresh

6. Prüfen Sie die Änderungen:

terraform show

Das Schlüssel/Wert-Paar "key" = "value" sollte in den Labelattributen der Konfiguration angezeigt werden.

Klicken Sie auf Fortschritt prüfen. Mit Backends arbeiten

Arbeitsbereich aufräumen

Bevor Sie mit der nächsten Aufgabe loslegen, löschen Sie erst die bereitgestellte Infrastruktur.

1. Als Erstes setzen Sie dafür das Backend zurück auf local, damit Sie den Storage-Bucket löschen können. Markieren und ersetzen Sie die gcs-Konfiguration mit dem Folgenden:

terraform { backend "local" { path = "terraform/state/terraform.tfstate" } }

2. Initialisieren Sie noch einmal das Backend local:

terraform init -migrate-state

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

3. Fügen Sie in der Datei main.tf der Ressource google_storage_bucket das Argument force_destroy = true hinzu. Wenn Sie einen Bucket löschen, löschen Sie mit dieser booleschen Option auch alle darin enthaltenen Objekte. Falls Sie versuchen, einen Bucket zu löschen, der noch Objekte enthält, gibt Terraform einen Fehler zurück. Die Ressourcenkonfiguration sollte in etwa so aussehen:

resource "google_storage_bucket" "test-bucket-for-state" { name = "qwiklabs-gcp-03-c26136e27648" location = "US" uniform_bucket_level_access = true force_destroy = true }

4. Übernehmen Sie die Änderung:

terraform apply

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

5. Sie können jetzt die Infrastruktur löschen:

terraform destroy

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

Aufgabe 2: Terraform-Konfiguration importieren

Im folgenden Abschnitt importieren Sie einen bereits vorhandenen Docker-Container und ein bestehendes Docker-Image in einen leeren Terraform-Arbeitsbereich. Sie lernen dabei Strategien und Abwägungen kennen, die wichtig sind, wenn Sie reale Infrastruktur in Terraform importieren.

Standardmäßig arbeiten Sie vollständig in Terraform, das heißt, Sie erstellen und verwalten Infrastruktur ausschließlich direkt in Terraform.

• Schreiben Sie eine Terraform-Konfiguration, mit der Sie die Infrastruktur festlegen, die Sie erstellen möchten.

• Um ganz sicher zu sein, dass die Konfiguration dem Zielzustand und der erwarteten Infrastruktur entspricht, überprüfen Sie den Terraform-Ausführungsplan.

• Wenn Sie den Terraform-Zustand und die Infrastruktur dann erstellen möchten, wenden Sie die Konfiguration an.

Nachdem Sie Infrastruktur mit Terraform erstellt haben, können Sie die Konfiguration bearbeiten sowie die Änderungen im Ausführungsplan überprüfen und anwenden. Wenn Sie die Infrastruktur nicht mehr brauchen, löschen Sie sie abschließend mit Terraform. Dieser Workflow geht jedoch davon aus, dass Sie in Terraform völlig neue Infrastruktur erstellen.

Es kann jedoch sein, dass Sie Infrastruktur verwalten möchten, die nicht in Terraform erstellt wurde. Mit dem Terraform-Befehl „import“ können Sie dieses Problem lösen und unterstützte Ressourcen in die Zustandsdatei des Terraform-Arbeitsbereichs aufnehmen und laden.

Der Befehl „import“ generiert jedoch die für die Verwaltung der Infrastruktur benötigte Konfiguration nicht automatisch. Daher gehen Sie beim Importieren von bereits vorhandener Infrastruktur in Terraform schrittweise vor.

Damit Sie bereits vorhandene Infrastruktur mit Terraform verwalten können, sind fünf Schritte nötig:

• Erkennen, welche vorhandene Infrastruktur Sie importieren möchten
• Infrastruktur in den Terraform-Zustand importieren
• Eine Terraform-Konfiguration schreiben, die mit der Infrastruktur übereinstimmt
• Den Terraform-Ausführungsplan überprüfen, um ganz sicher zu sein, dass die Konfiguration dem Zielzustand und der Infrastruktur entspricht
• Konfiguration anwenden, um den Terraform-Zustand zu aktualisieren

In diesem Abschnitt erstellen Sie zuerst über die Kommandozeile von Docker einen Docker-Container. Dann importieren Sie diesen in einen neuen Terraform-Arbeitsbereich. Anschließend aktualisieren Sie mit Terraform die Konfiguration des Containers. Wenn Sie fertig sind, löschen sie ihn zum Schluss.

Achtung: Wenn Sie Infrastruktur importieren, wird der Terraform-Zustand unter Umständen so verändert, dass vorhandene Terraform-Projekte nicht mehr funktionieren. Bevor Sie den Terraform-Befehl „import“ bei einem realen Terraform-Projekt ausführen, machen Sie ein Back-up der Datei terraform.tfstate und des Verzeichnisses .terraform und speichern Sie sie an einem sicheren Ort.

Docker-Container erstellen

1. Erstellen Sie mit dem NGINX-Image von Docker Hub einen Container namens hashicorp-learn und sehen Sie sich in der virtuellen Maschine von Cloud Shell über den Port 80 (HTTP) die Vorschau des Containers an:

docker run --name hashicorp-learn --detach --publish 8080:80 nginx:latest

2. Prüfen Sie, ob der Container ausgeführt wird:

docker ps

3. Klicken Sie im Cloud Shell-Bereich auf Webvorschau und dann auf Vorschau auf Port 8080.

Cloud Shell öffnet die Vorschau-URL auf dem Proxy-Dienst in einem neuen Browserfenster. Dort wird die NGINX-Standardseite mit dem Index angezeigt. Sie haben jetzt ein Docker-Image und einen Container und können beides in den Arbeitsbereich in Terraform importieren und dort verwalten.

Container in Terraform importieren

1. Klonen Sie das Beispiel-Repository:

git clone https://github.com/hashicorp/learn-terraform-import.git

2. Wechseln Sie in dieses Verzeichnis:

cd learn-terraform-import

Dieses Verzeichnis enthält zwei Terraform-Konfigurationsdateien, aus denen Sie mithilfe der Schritte in dieser Anleitung die Konfiguration erstellen.

• Mit der Datei main.tf konfigurieren Sie den Docker-Anbieter.
• Die Datei docker.tf enthält die Konfiguration, mit der Sie den im letzten Schritt erstellten Docker-Container verwalten können.

3. Initialisieren Sie den Terraform-Arbeitsbereich:

terraform init Hinweis: Wenn Sie eine Fehlermeldung erhalten, wie Error: Failed to query available provider packages, führen Sie diesen Befehl aus: terraform init -upgrade.

4. Öffnen Sie im Cloud Shell-Editor die Datei learn-terraform-import/main.tf.

5. Suchen Sie die Ressource provider: docker und kommentieren Sie das Argument host aus oder löschen Sie es:

provider "docker" { # host = "npipe:////.//pipe//docker_engine" } Hinweis: Das ist ein Workaround, der momentan für ein bekanntes Problem bei der Docker-Initialisierung eingesetzt wird.

6. Öffnen Sie als Nächstes learn-terraform-import/docker.tf.

7. Definieren Sie in der Datei docker.tf unter dem auskommentierten Code eine leere Ressource docker_container. Diesem Docker-Container ist die Terraform-Ressourcen-ID docker_container.web zugeordnet:

resource "docker_container" "web" {}

8. Suchen Sie den Namen des Containers, den Sie importieren möchten – in diesem Beispiel ist das der Container, den Sie im vorherigen Schritt erstellt haben:

docker ps

9. Um den Docker-Container mit der gerade erstellten Ressource docker_container.web zu verknüpfen, führen Sie den Befehl terraform import aus. Für das Importieren benötigen Sie in Terraform die Terraform-Ressourcen-ID und die vollständige Docker-Container-ID. Die SHA256-Hash-ID eines Containers wird Ihnen über den Befehl docker inspect -f {{.ID}} hashicorp-learn zurückgegeben:

terraform import docker_container.web $(docker inspect -f {{.ID}} hashicorp-learn) Hinweis: Welche ID Sie für den Befehl terraform import brauchen, hängt vom Ressourcentyp ab. Informationen zu allen Ressourcen, die in Terraform importiert werden können, finden Sie in der jeweiligen Anbieterdokumentation. Mehr über Docker erfahren Sie zum Beispiel in dieser Dokumentation.

10. Überprüfen Sie, ob der Container in den Terraform-Zustand importiert wurde:

terraform show

In dieser Zustandsdatei sind alle Informationen enthalten, die in Terraform über den eben von Ihnen importierten Container vorhanden sind. Über den Befehl „Import“ wird in Terraform jedoch keine Konfiguration für diese Ressource erstellt.

Konfiguration erstellen

Bevor Sie diesen Container in Terraform also verwalten können, müssen Sie eine Terraform-Konfiguration dafür erstellen.

1. Führen Sie den folgenden Code aus:

terraform plan Hinweis: Sie erhalten wegen der fehlenden, aber notwendigen Argumente image und name eine Fehlermeldung in Terraform. Ohne diese erforderlichen Argumente kann Terraform keinen Ausführungsplan für diese Ressource erstellen.

Es gibt zwei Möglichkeiten, die Konfiguration in der Datei docker.tf so anzupassen, dass sie mit dem importierten Zustand übereinstimmt. Sie können entweder den aktuellen Zustand der Ressource vollständig in die Konfiguration übernehmen oder dort die benötigten Attribute einzeln hinzufügen. Beide Vorgehensweisen können je nach Kontext sinnvoll sein.

• Den aktuellen Zustand einfach zu übernehmen, ist häufig schneller. Die Konfiguration kann dadurch aber zu ausführlich werden, weil jedes Attribut enthalten ist – egal ob Sie es tatsächlich brauchen oder nicht.

• Die einzelnen Attribute gezielt auszuwählen, macht eine Konfiguration schlanker und dadurch unter Umständen leichter zu verwalten. Sie müssen aber dabei eine klare Vorstellung davon haben, welche Attribute Sie in der Konfiguration brauchen.

Für die Aufgabe in diesem Lab verwenden Sie den aktuellen Zustand als Ressource.

2. Kopieren Sie den Terraform-Zustand in die Datei docker.tf:

terraform show -no-color > docker.tf Hinweis: Mithilfe des Symbols > wird der gesamte Inhalt der Datei docker.tf durch die Ausgabe des Befehls terraform show ersetzt. Obwohl das in diesem Beispiel funktioniert, müssen Sie normalerweise die Ausgabe von terraform show bearbeiten. Wenn Sie eine Ressource in eine Konfiguration importieren, in der Sie bereits andere Ressourcen verwalten, ist es erforderlich, dass Sie die Konfiguration der bereits vorhandenen Ressourcen, die Sie nicht vollständig ersetzen möchten, mit der der neuen zusammenführen.

3. Sehen Sie sich die Datei docker.tf an und stellen Sie fest, ob der Inhalt durch die Ausgabe des Terraform-Befehls „show“ ersetzt wurde.

4. Führen Sie den folgenden Code aus:

terraform plan

Ihnen werden in Terraform Warnungen und Fehlermeldungen angezeigt, die sich einerseits auf eingestellte („links“), andererseits auf einige andere Argumente beziehen, bei denen das Programm nur Lesezugriff hat (ip_address, network_data, gateway, ip_prefix_length und id).

Letztere werden im Terraform-Zustand lediglich als Werte für die Docker-Container gespeichert. Sie können diese Argumente aber nicht über die Konfiguration bearbeiten, sondern nur direkt in Docker. Der Wert des Arguments „links“ lässt sich über die Terraform-Konfiguration festlegen. Sie erhalten jedoch weiterhin eine Warnung, weil das Argument eingestellt wurde und in zukünftigen Versionen des Docker-Anbieters unter Umständen nicht mehr unterstützt wird.

Weil bei diesem Ansatz alle Attribute aus dem Terraform-Zustand geladen werden, enthält die Konfiguration optionale Attribute, deren Wert der Standardeinstellung entspricht. Welche das sind, unterscheidet sich bei den verschiedenen Anbietern. Sie finden eine Liste der optionalen Attribute in der Anbieterdokumentation.

5. Sie können jetzt alle optionalen Attribute löschen. Entfernen Sie sie und behalten Sie nur die erforderlichen Attribute: image, name und ports. Danach sollte die Konfiguration so aussehen:

resource "docker_container" "web" { image = "sha256:87a94228f133e2da99cb16d653cd1373c5b4e8689956386c1c12b60a20421a02" name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

Wenn Sie reale Infrastruktur importieren, sehen Sie in der Anbieterdokumentation nach, was die einzelnen Argumente bedeuten. Mit diesem Wissen können Sie dann entscheiden, wie Sie mit den Warnungen und Fehlermeldungen umgehen, die Sie sehen, wenn Sie den Befehl „plan“ ausführen. Weitere Informationen zum Argument links erhalten Sie beispielsweise in der Docker-Anbieterdokumentation.

6. Überprüfen Sie, ob Sie alle Fehler behoben haben:

terraform plan

Der Befehl sollte jetzt keine Fehlermeldungen mehr zurückgeben. Der Ausführungsplan zeigt, dass Terraform den Container aktualisieren und dabei die Attribute attach, logs, must_run und start hinzufügen wird.

Mithilfe dieser Attribute erstellt Terraform Docker-Container, die aber nicht in Docker gespeichert sind. Deshalb wurden deren Werte beim Befehl terraform import nicht in den Zustand geladen. Wenn Sie die Konfiguration im Ausführungsplan überprüfen und anwenden, werden den Attributen ihre Standardwerte über den Docker-Anbieter zugeordnet und sie werden im Zustand gespeichert. Der ausgeführte Container wird aber nicht von ihnen beeinflusst.

7. Übernehmen Sie die Änderung. Damit synchronisieren Sie die aktualisierte Terraform-Konfiguration und den bearbeiteten Terraform-Zustand mit dem Docker-Container, dem sie entsprechen, und schließen den Vorgang ab. Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

terraform apply

Die Konfigurationsdatei, der Terraform-Zustand und der Container wurden jetzt synchronisiert. Sie können den Terraform-Container von nun an mit Terraform auf die übliche Weise verwalten.

Image-Ressource erstellen

In einigen Fällen können Sie Ressourcen auch ohne den Befehl terraform import mit Terraform verwalten. Das gilt beispielsweise häufig für Ressourcen, die eine einzige eindeutige ID oder einen einzigen eindeutigen Tag haben, wie Docker-Images.

Über die SHA256-Hash-ID der Ressource docker_container.web ist in der Datei docker.tf das Image klar angegeben, mit dem der Container erstellt werden soll. Auf diese Weise wird die Image-ID in Docker gespeichert und deshalb können Sie sie damit über terraform import direkt in den Zustand laden. Die Image-ID ist jedoch nicht visuell lesbar – anders als ein Tag oder Name. Deshalb passt dieses Vorgehen unter Umständen nicht zu Ihren Anforderungen. Vielleicht möchten Sie beispielsweise die aktuelle Version des NGINX-Images verwenden.

1. Um den Tagnamen des Images zu ermitteln, führen Sie den folgenden Befehl aus. Ersetzen Sie dabei <IMAGE-ID> mit der Image-ID aus der Datei docker.tf:

docker image inspect -f {{.RepoTags}}

2. Um mit diesem Image eine Ressource darstellen zu lassen, fügen Sie die folgende Konfiguration in die Datei docker.tf ein:

resource "docker_image" "nginx" { name = "nginx:latest" } Hinweis: Ersetzen Sie noch nicht den Image-Wert in der Ressource docker_container.web, ansonsten löscht Terraform den Container und erstellt ihn neu. Da Terraform die Ressource docker_image.nginx noch nicht in den Zustand geladen hat, liegt dem Programm noch keine Image-ID zum Abgleich mit der hartcodierten vor. Das Tool wird daher davon ausgehen, dass der Container ersetzt werden soll. Erstellen Sie daher als Workaround wie in diesem Beispiel zuerst das Image und aktualisieren Sie erst dann den Container, um es zu verwenden.

3. Erstellen Sie die Image-Ressource im Zustand:

terraform apply

Terraform hat jetzt eine Ressource für das Image erstellt und Sie können die zugehörige ID daher in der Container-Konfiguration angeben.

4. Verändern Sie dafür den Image-Wert von docker_container.web:

resource "docker_container" "web" { image = docker_image.nginx.image_id name = "hashicorp-learn" ports { external = 8080 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

5. Sehen Sie nach, ob sich etwas geändert hat:

terraform apply

Weil docker_image.nginx.latest mit der hartcodierten Image-ID übereinstimmt, die Sie ausgetauscht haben, hat sich nichts verändert, als Sie den Befehl terraform apply ausgeführt haben.

Hinweis: Falls Sie den Docker-Container zu einem bestimmten Zeitpunkt erstellt und diesen Befehl erst später ausgeführt haben, sich die Image-ID für das Tag „nginx:latest“ aber in der Zwischenzeit verändert hat, wird der Container gelöscht und mit dem neuen Image noch einmal erstellt.

Container mit Terraform verwalten

Der Docker-Container lässt sich jetzt über Terraform verwalten. Bearbeiten Sie dafür einfach die Konfiguration.

1. Ändern Sie in der Datei docker.tf den externen Port des Containers von 8080 zu 8081:

resource "docker_container" "web" { name = "hashicorp-learn" image = docker_image.nginx.image_id ports { external = 8081 internal = 80 ip = "0.0.0.0" protocol = "tcp" } }

2. Übernehmen Sie die Änderung:

terraform apply

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

Terraform löscht daraufhin den Container und erstellt ihn mit der neuen Portkonfiguration noch einmal.

3. Überprüfen Sie, ob der Container ersetzt wurde und nun die neue Konfiguration aufweist:

docker ps

Die Container-ID hat sich im Verlauf dieses Prozesses verändert, weil Terraform einen vollständig neuen Container erstellt hat.

Infrastruktur löschen

Sie haben jetzt den Docker-Container und das Image, mit dem er erstellt wurde, in Terraform importiert.

1. Löschen Sie den Container und das Image:

terraform destroy

Wenn Sie zur Bestätigung aufgefordert werden, geben Sie yes ein.

2. Prüfen Sie, ob der Container gelöscht wurde:

docker ps --filter "name=hashicorp-learn" Hinweis: Weil Sie das Image sowohl der Terraform-Konfiguration als auch dem Container hinzugefügt haben, wird es in Docker und im Container gelöscht. Falls noch ein anderer Container dasselbe Image enthält, wird dieser Befehl nicht korrekt ausgeführt. Wenn Sie Ressourcen in Terraform importieren, müssen Sie jeden Schritt des Lebenszyklus dieser Ressourcen mit Terraform verwalten, sie dort also auch löschen.

Einschränkungen und weitere Aspekte

Wenn Sie Ressourcen in Terraform importieren, sollten Sie einige wichtige Punkte im Blick behalten.

Der Terraform-Befehl „import“ bezieht sich immer nur auf den aktuellen Zustand der Infrastruktur, wie dieser vom Terraform-Anbieter gemeldet wird. Über andere Aspekte der Infrastruktur liegen Terraform keine Informationen vor, darunter:

• Korrekte Funktionsweise
• Geplanter Einsatz
• Änderungen, die Sie ohne Terraform an ihr vorgenommen haben, z. B. der Zustand des Dateisystems Ihres Docker-Containers

Das Importieren erfordert manuell ausgeführte Schritte und ist deshalb fehleranfällig. Das gilt insbesondere dann, wenn die Person, die die Ressourcen importiert, den Kontext nicht genau kennt und nicht weiß, wofür diese Ressourcen ursprünglich erstellt wurden.

Beim Importieren wird die Terraform-Zustandsdatei verändert. Sie sollten daher vor diesem Schritt eine Sicherung der Datei erstellen.

Beim Terraform-Befehl „import“ werden keine Abhängigkeiten zwischen den einzelnen Elementen der Infrastruktur erkannt oder generiert.

Außerdem erkennt Terraform keine Standardattribute, die in der Konfiguration überflüssig sind.

Der Terraform-Befehl „import“ wird nicht von allen Anbietern und Ressourcen unterstützt.

Wenn Sie Infrastruktur in Terraform importieren, bedeutet das nicht, dass Sie diese auch mit Terraform löschen oder neu erstellen können. Das funktioniert beispielsweise dann nicht, wenn die importierte Infrastruktur von einer nicht verwalteten Infrastruktur oder Konfiguration abhängt.

Wenn Sie die Best Practices für Infrastructure as Code (IaC), wie unveränderliche Infrastruktur, beachten, können Sie diese Probleme leichter vermeiden. Es ist jedoch unwahrscheinlich, dass Ihnen das mit manuell erstellter Infrastruktur möglich ist.

Mit einem Tool wie Terraformer lassen sich die manuellen Schritte beim Importieren von Infrastruktur automatisieren. Diese Tools gehören allerdings nicht zu Terraform und werden von Hashicorp weder empfohlen noch unterstützt.

Glückwunsch!

In diesem Lab haben Sie gelernt, Backends und die Zustandsdatei in Terraform zu verwalten. Sie haben ein Backend „local“ und ein Cloud Storage-Backend erstellt und damit die Zustandsdatei verwaltet und den Zustand aktualisiert. Außerdem haben Sie eine Konfiguration in Terraform importiert. Sie haben die Konfiguration aktualisiert und manuell so bearbeitet, dass Sie mit Terraform den Docker-Container vollständig verwalten können.

Weitere Informationen

In den folgenden Ressourcen finden Sie mehr praktische Übungen für Terraform:

• Hashicorp im Google Cloud Marketplace
• Hashicorp-Tutorials
• Terraform-Community
• Google-Beispiele für Terraform

Google Cloud-Schulungen und -Zertifizierungen

In unseren Schulungen erfahren Sie alles zum optimalen Einsatz unserer Google Cloud-Technologien und können sich entsprechend zertifizieren lassen. Unsere Kurse vermitteln technische Fähigkeiten und Best Practices, damit Sie möglichst schnell mit Google Cloud loslegen und Ihr Wissen fortlaufend erweitern können. Wir bieten On-Demand-, Präsenz- und virtuelle Schulungen für Anfänger wie Fortgeschrittene an, die Sie individuell in Ihrem eigenen Zeitplan absolvieren können. Mit unseren Zertifizierungen weisen Sie nach, dass Sie Experte im Bereich Google Cloud-Technologien sind.

Anleitung zuletzt am 26. Januar 2024 aktualisiert

Lab zuletzt getestet am 11. Dezember 2023

© 2024 Google LLC. Alle Rechte vorbehalten. Google und das Google-Logo sind Marken von Google LLC. Alle anderen Unternehmens- und Produktnamen können Marken der jeweils mit ihnen verbundenen Unternehmen sein.