IaC in der Google Cloud: native Tools versus Terraform

Google Cloud Deployment Manager

Google Cloud Deployment Manager ist das native Infrastructure-as-Code-Tool von GCP. IT-Teams verwenden es für das automatisierte Erstellen und Verwalten von Google-Cloud-Ressourcen. Dieses Tool stellt Ihre Ressourcen systematisch bereit und skaliert sie bedarfsorientiert.

Um Ressourcen bereitzustellen, liest der Deployment Manager die Konfiguration aus einer YAML-Datei (YAML Ain’t Markup Language) aus. Wenn Sie vertraut sind mit Tools wie Ansible und Kubernetes, werden Sie sich mit der YAML-Syntax gleich wie zu Hause fühlen.

Im Folgenden sehen Sie einen Teil einer YAML-Vorlage, die eine virtuelle Maschine (VM) in GCP erstellt. Zunächst definieren Sie die Ressource mit ihrem Namen und Typ:

resources:

- name: my-first-vm

  type: compute.v1.instance

  properties:

    zone: us-east1-d

    machineType: https://www.googleapis.com/compute/v1/projects/random-test-01/zones/us-east1-d/machineTypes/f1-micro

    disks:

    - deviceName: boot

      type: PERSISTENT

  ………

Sie können die Vorlage mit Jinja oder Python weiter modularisieren. Wie Sie in unserem Beispielcode sehen, ist der Maschinentyp hartcodiert, basierend auf der Zone, in der die VM bereitgestellt wird. Das ist nicht ideal, denn Sie brauchen damit für jede Zone, die Sie verwenden möchten, eine eigene Vorlage, die Sie eigens schreiben müssen.

Mit Python und Jinja müssen Sie keine Ihrer Ressourcen mehr hartcodieren. Sie können den Namen einer Ressource auf {{ vm_name }} setzen, so dass Jinja den Namen auf Basis Ihrer Definitionen programmatisch bestimmt.

Wenn Sie zum Beispiel die Ressourcennamen so wählen möchten, dass sie verraten, ob eine Ressource in der Produktions- oder Entwicklungsgruppe ist, können Sie dies mit Umgebungsvariablen erledigen und je nach instanziierter Umgebungsvariable den entsprechenden Namen automatisch generieren.

Terraform auf GCP

Terraform ist eines der führenden Infrastructure-as-Code-Tools, da es Ressourcen von verschiedenen Anbietern provisionieren kann. Terraform ist also nicht auf einen einzigen Cloud-Anbieter beschränkt. Wechseln Sie den Cloud-Anbieter oder haben mehrere zeitgleich im Einsatz, kommt Terraform damit zurecht. Das Tool unterstützt auch On-Premises-Umgebungen wie VMware ESXi.

Zur Definition von Ressourcen verwendet Terraform eine strukturierte Sprache namens HashiCorp Configuration Language (HCL). HCL wird als eigene Programmiersprache betrachtet, weil sie bedingte Logik und Schleifen unterstützt. Diese Eigenschaften erübrigen das Nutzen externer Konfiguration oder einer separaten Programmiersprache wie Jinja und Python.

Wie Sie im Folgenden sehen können, ist HCL syntaktisch ähnlich zu JSON. Terraform hat im Vergleich zum Deployment Manager aufgrund der Verwendung von HCL eine flachere Lernkurve, dafür aber haben Sie mit dieser Sprache mehr Möglichkeit, mit Programmierlogik wie etwa Variablen zu arbeiten:

terraform {

   required_version      = ">= 0.12"

}

provider "google" {

  region      = var.region

  project     = var.project_name

  credentials = file(var.credentials_file_path)

}

resource "google_compute_http_health_check" "default" {

  name                = "tf-www-basic-check"

  request_path        = "/"

  check_interval_sec  = 1

  healthy_threshold   = 1

  unhealthy_threshold = 10

  timeout_sec         = 1

}

  ……

Google Cloud Deployment Manager versus Terraform

Welches Infrastructure-as-Code-Tool ist nun also das richtige für Ihre Google Cloud Deployments? Die Wahl hängt am Ende von Ihren Workloads ab.

Wenn Sie Workloads ausschließlich auf GCP bereitstellen, sollte Deployment Manager alle Ihre Anforderungen erfüllen. Weil es ein integriertes Google Cloud Tool ist, können Sie auch dessen Authentifizierungsfunktionen einfacher nutzen. Andererseits ist Terraform die bessere Option für die Bereitstellung mit mehreren Cloud-Anbietern.

Terraform hat eine eingebaute Programmierlogik innerhalb HCL – im Gegensatz zu YAML, das Jinja und Python benötigt, um seinen Funktionsumfang zu erweitern. Vergessen Sie nicht, dass Terraform relativ neu und noch nicht einmal bei Version 1 angelangt ist: Die (zum Zeitpunkt der Veröffentlichung dieses Artikels) aktuelle Version von Terraform ist 0.14.6. Rechnen Sie also mit einigen umfangreichen Updates.

Die Tools behandeln auch die Ressourcenzustände unterschiedlich. In GCP erzeugt der Deployment Manager eine Manifestdatei, die Details über die bereitgestellten Ressourcen enthält. Sie liegt in GCP und der Nutzer kann sie nicht bearbeiten. Terraform verfügt über ein ähnliches Feature namens States, das einen Einblick in die aktuell bereitgestellten Ressourcen gibt.

Anders als der Deployment Manager werden die State-Dateien von Terraform nicht standardmäßig in der Cloud gespeichert; sie können auch lokal auf dem Rechner eines Entwicklers liegen. Dies kann allerdings bei der Arbeit im Team zum Problem werden: Wenn mehrere Entwickler die Konfigurationsdateien bearbeiten, kann das dazu führen, dass ihre States voneinander abweichen.

Um dem entgegenzuwirken bietet Terraform sogenannte Remote State Locations an. Sie dienen als zentraler Ort für Terraform, um die Konfiguration eines Deployments und den Zustand der aktuell bereitgestellten Infrastruktur abzugleichen. Terraform schreibt den Remote State in einen von den Teammitgliedern gemeinsam nutzbaren Datenspeicher. Zu möglichen Remote State Locations gehören Amazon S3, Azure Blob Storage und Google Cloud Storage.