© Adrian Hancu / 123RF.com

Im Cloud-Umfeld haben es Admins oft mit vielen, eher kurzlebigen virtuellen Maschinen zu tun, die sich nicht mehr händisch auf- und abbauen sowie konfigurieren lassen. Eine Strategie, die das Problem lösen soll, heißt Infrastructure as Code.

Die Verlagerung von Infrastruktur und Anwendungen aus firmeneigenen Rechenzentren zu einem oder mehreren Cloud-Anbietern ist in vollem Gange. Das Arbeiten mit Cloud-Ressourcen (virtuelle Maschinen, virtuelle Netzwerke, Datenbanken und so weiter) gehört zum täglichen Brot vieler Administratoren. Im Gegensatz zu langlebigen physischen Servern im Rechnerraum sind die meisten Cloud-Ressourcen viel unbeständiger und kurzlebiger. Statt um handgestreichelte Server mit Namen aus “Herr der Ringe” geht es hier um sehr viele gleichartige und leicht ersetzbare virtuelle Maschinen mit kryptischen Namen.

Das Erstellen, Konfigurieren und später wieder Dekommissionieren von Hunderten oder gar Tausenden virtueller Maschinen erfordert eine ganz andere Herangehensweise als das Management einer Handvoll physischer Server. Eine mögliche Lösung für dieses Problem ist das Konzept Infrastructure as Code (IaC).

Infrastructure as Code

Die Quintessenz von Infrastructure as Code ist es, die Beschreibung der Infrastruktur wie den Quellcode einer Anwendung zu behandeln. In der Softwareentwicklung ist es gang und gäbe, den Quellcode einer Anwendung in einer Versionsverwaltung zu pflegen. Dies erleichtert nicht nur die Nachverfolgbarkeit von Änderungen, sondern ermöglicht auch eine bessere Zusammenarbeit der Entwickler – gerade im Hinblick auf das gegenseitige Begutachten von Code (Review). Bevor der Code in den produktiven Branch übernommen wird, prüfen ihn ein oder mehrere Anwender. Fehler, Ungenauigkeiten oder Code, der nicht den Ansprüchen des Teams genügt, lässt sich so korrigieren und verbessern. Bei Infrastructure as Code wird diese Form der Zusammenarbeit für Code verwendet, der eine Infrastruktur beschreibt.

Eine weitere aus der Softwareentwicklung bekannte Vorgehensweise ist das automatisierte Testen von Quellcode. Neben der Prüfung auf Code-Ebene (Syntaxchecks, Linting, Unittests, …) wird vielfach auch die (kompilierte) Anwendung in einer Testumgebung installiert und ausgeführt. So lässt sich das korrekte Verhalten der Anwendung kontrollieren. Bei Infrastrukturcode ist es ebenfalls möglich, Änderungen am Code vor der Überführung in die Produktion zu testen.

Zusammengefasst erlaubt es Infrastructure as Code, die Infrastruktur versioniert zu verwalten, Änderungen nachvollziehbar zu dokumentieren und die Zuverlässigkeit zu erhöhen, indem man Fehler vermeidet. Das bekannteste Werkzeug aus dem Bereich Infrastructure as Code ist Terraform.

Terraform

Terraform ist ein von der Firma Hashicorp entwickeltes Werkzeug, um Ressourcen deklarativ zu beschreiben, zu erstellen und zu verwalten. Terraform verwendet den Begriff Ressource für alles, was Terraform erstellen oder ändern kann. Dies können virtuelle Maschinen genauso wie Netzwerke oder IP-Adressen sein. Die Ressourcen werden hierbei in den meisten Fällen nicht von Terraform selbst erstellt, sondern von sogenannten Providern. Diese Verbindungsstücke erlauben es Terraform, mit der API anderer Anbieter zu kommunizieren und die von diesen bereitgestellten Ressourcen zu verwalten, zu löschen oder zu konfigurieren. Ob es sich bei der API um die eines Cloud-Anbieters wie AWS, Azure oder GCP handelt, ist für Terraform selbst nicht von Bedeutung. Erst durch den zugehörigen Provider weiß Terraform, welche Ressourcen etwa GCP anbietet und wie man diese erstellt.

Bevor sich die Open-Source-Gemeinde jetzt enttäuscht abwendet und den berüchtigten Vendor Lock-in vermutet: Terraform selbst ist Open-Source-Software (Mozilla Public License 2.0). Außerdem lassen sich mit Terraform nicht nur Ressourcen von den großen Public Clouds wie AWS, Azure und GCP verwalten, sondern auch von Open-Source-Alternativen wie OpenStack (selbst gehostet oder von kommerziellen Anbietern betrieben) oder von Proxmox. So ist das Tool auch für diejenigen Personen, Organisationen oder Unternehmen von Interesse, die gern die volle Hoheit über ihre Daten behalten möchten.

Ein Tool für alle Wolken

Dank der im Design vorgesehenen Erweiterbarkeit ist Terraform flexibel. Bei Erstellung dieses Artikels umfasste die Liste der verfügbaren Provider über 3300 Einträge. Einige dieser Provider betreut und unterstützt Hashicorp selbst, andere werden von den jeweiligen Unternehmen oder von der Community gepflegt.

Die Liste umfasst dabei alle gängigen Clouds wie AWS, GCP und Azure, private Clouds mit OpenStack, aber auch Dienste wie Github, Gitlab oder Microsoft Active Directory sowie Netzwerk-Appliances wie F5 oder Datenbanken wie CockroachDB. Im Prinzip lässt sich alles, was eine API anbietet, an Terraform anbinden und darüber ansprechen.

Installation

Terraform wird von den meisten Linux-Distributionen als Paket angeboten und lässt sich über den jeweiligen Paketmanager des Systems (Dnf, Zypper, Apt und so weiter) installieren. In vielen Fällen wird allerdings nur eine veraltete Version bereitgestellt, was sich beim Aufruf von Terraform zeigt (Listing 1).

$ terraform version
Terraform v1.5.1
on linux_amd64
Your version of Terraform is out of date! The latest version
is 1.5.2. You can update by downloading from
https://www.terraform.io/downloads.html

In diesem Fall können Sie eine ZIP-Datei bei Terraform herunterladen [1] und die darin enthaltene Terraform-Binärdatei zum Beispiel nach »/usr/local/bin/« oder »~/bin/« entpacken. Sofern dieses Verzeichnis in Ihrem Path enthalten ist, sollte ein Aufruf von »terraform version« anschließend die installierte Version anzeigen. Für etwaige Updates sind Sie bei der manuellen Installation jedoch selbst zuständig.

Ein typischer Terraform-Workflow

Sobald Terraform korrekt installiert ist, steht einem ersten Ausprobieren nichts im Wege. Zuerst legen Sie ein neues Verzeichnis an und wechseln in dieses Verzeichnis:

$ mkdir mein_terraform_projekt
$ cd mein_terraform_projekt

Das folgende Beispiel führt Sie durch einen typischen Terraform-Workflow, der aus vier oder fünf Schritten besteht:

• »terraform init«
• »terraform validate«
• »terraform plan«
• »terraform apply«
• »terraform destroy«

Um diesen Workflow zu zeigen, benötigen Sie Code, damit Terraform eine Ressource hat, die es einrichten kann. Erstellen Sie dazu eine Datei namens »versions.tf« wie in Listing 2.

terraform {
  required_providers {
    local = {
      source = "hashicorp/local"
    }
  }
}

Wie beschrieben, stammen fast alle Ressourcen, die Terraform verwalten kann, von Providern. In diesem Codebeispiel weisen Sie Terraform an, den Local-Provider für lokale Dateien zu verwenden. Das Beispiel verzichtet der Einfachheit halber auf Versionsbeschränkungen [2], die die zu nutzende Version des Providers eingrenzen können. Es genügt, dass der Provider vorhanden ist.

Nun folgt der erste Schritt im Workflow: das Initialisieren des Arbeitsverzeichnisses und die Bereitstellung aller benötigten Provider. Dies erfolgt mit dem Aufruf »terraform init«, der die Ausgaben von Listing 3 erzeugt.

$ terraform init
Initializing the backend...
Initializing provider plugins...
- Finding latest version of hashicorp/local...
- Installing hashicorp/local v2.4.0...
- Installed hashicorp/local v2.4.0 (signed by HashiCorp)
Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.
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.

Die Ausgabe zeigt, welche Provider Terraform heruntergeladen und initialisiert hat, hier nur den gewünschten Local-Provider. Zur internen Verwaltung legt Terraform einen versteckten Ordner ».terraform« und eine versteckte Datei ».terraform.lock.hcl« an. Beide sollten weder verändert noch gelöscht werden.

Die Versionsnummer in der Ausgabe kann bei Ihnen anders lauten, was schlicht einer neuen Version des Local-Providers geschuldet ist und kein Problem darstellt. Nachdem das Arbeitsverzeichnis korrekt angelegt wurde, können Sie den ersten Code schreiben. Legen Sie dazu eine weitere Datei namens »main.tf« an und geben ihr den Inhalt wie in Listing 4.

resource "local_file" "meine_erste_datei" {
  content  = "Hallo Linux-Magazin!\n"
  filename = "hallo.txt"
}

Der Code erstellt eine neue Ressource des Typs »local_file«, also eine lokale Datei. Diese Ressource bekommt den internen Namen »meine_erste_datei«. Der Dateiname soll »hallo.txt« sein, der Inhalt der Datei »Hallo Linux-Magazin!« mit einem Zeilenumbruch am Ende. Ihren Codeschnipsel können Sie über den Befehl »terraform validate« auf seine syntaktische Korrektheit prüfen:

$ terraform validate
Success!
 The configuration is valid.

Die Ausgabe bestätigt, dass der Code alle syntaktischen Vorgaben von Terraform einhält und somit gültig ist. Dabei kommuniziert Terraform nicht mit dem verwendeten Provider, sondern prüft nur die Syntax sowie das Vorhandensein aller benötigten Parameter einer Ressource.

Nachdem die Korrektheit des Codes geprüft wurde, ist der nächste Schritt im Workflow das Ausführen von »terraform plan« (Listing 5). Terraform prüft dabei den ihm bekannten Stand an Ressourcen (durch Anfragen an die API) und vergleicht das mit dem vom Benutzer angegebenen Wunschzustand. Dieser deklarative Ansatz, dem beispielsweise auch Ansible folgt, erlaubt es, Zustände zu vergleichen und anzugleichen. Entspricht der Ist-Zustand dem Soll-Zustand, so gibt es für Terraform nichts zu tun. Dieser als Idempotenz bekannte Mechanismus sorgt dafür, dass Terraform gefahrlos mehrfach hintereinander ausgeführt werden kann, ohne dass der Benutzer am Ende Dutzende Duplikate seiner Ressourcen vorfindet.

$ terraform plan
Terraform used the selected providers to generate the following execution plan.
Resource actions are indicated with the following symbols:
  + create
Terraform will perform the following actions:
  # local_file.meine_erste_datei will be created
  + resource "local_file" "meine_erste_datei" {
      + content              = <<-EOT
            Hallo Linux-Magazin!
        EOT
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "hallo.txt"
      + id                   = (known after apply)
    }
Plan: 1 to add, 0 to change, 0 to destroy.
---------------------------------------------------------------------------
Note: You didn't use the -out option to save this plan, so
Terraform can't guarantee to take exactly these actions if you
run "terraform apply" now.

Die Ausgabe von »terraform plan« besteht aus drei Teilen. Der erste Teil ist eine Legende mit Erklärungen, welche Symbole welche Tätigkeiten beschreiben. In Listing 5 wird erklärt, dass ein Pluszeichen für das Erstellen einer neuen Ressource steht. Der zweite Teil ist die detaillierte Ansicht der Änderungen, die Ihnen anzeigt, dass eine neue Ressource »local_file.meine_erste_datei« zu erstellen ist. Abhängig von der Ressource erhalten Sie anschließend die genauen Eigenschaften, die Terraform zu dieser Ressource kennt. Bei einer lokalen Datei sind dies unter anderem der Dateiname und die Berechtigungen.

Am Ende zeigt Terraform eine kurze Zusammenfassung des Plans, der Sie entnehmen können, dass eine Ressource hinzugefügt würde, aber weder Ressourcen geändert noch gelöscht würden. In der Realität kann diese Ausgabe sehr lang werden, wenn viele Ressourcen angelegt, verändert oder gelöscht werden. Sie sollten die Ausgabe dennoch kritisch und genau darauf prüfen, ob die Änderungen Ihren Vorstellungen entsprechen. Ist dies der Fall, können Sie die Änderungen ausführen lassen. Dies erfolgt durch den Befehl »terraform apply«. Dieser zeigt zuerst die von »terraform plan« bekannte Ausgabe, gefolgt von einer Bitte um Bestätigung. Sofern Sie die Nachfrage mit »yes« beantworten, beginnt Terraform damit, die Änderungen umzusetzen (Listing 6).

$ terraform apply
[...]
Plan: 1 to add, 0 to change, 0 to destroy.
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.
  Enter a value: yes
local_file.meine_erste_datei: Creating...
local_file.meine_erste_datei: Creation complete after 0s [id=abc447c601695d6c0423b554743cbbb11fa8980d]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Gratulation, Sie haben soeben Ihre erste Ressource per Terraform erstellt! Um den Inhalt der Datei zu prüfen, können Sie sich diese per »cat hallo.txt« ausgeben lassen. Das sollte, wie zu erwarten, die Ausgabe »Hallo Linux-Magazin!« ergeben.

Löschen Sie als Nächstes die Datei »hallo.txt« und führen »terraform apply« erneut aus, so sehen Sie, dass Terraform bemerkt hat, dass die Datei nicht mehr existiert und sie neu anlegen will. Intern hat Terraform hierzu die API des jeweiligen Providers kontaktiert, in unserem Fall die des Local-Providers.

Möchten Sie die von Terraform erstellten Ressourcen, in Ihrem Fall die Datei »>hallo.txt«, wieder entfernen, führen Sie den Befehl »terraform destroy« aus. Die Ausgabe ähnelt der des Apply-Befehls; sie zeigt zuerst die geplanten Änderungen, fragt nach Bestätigung und entfernt anschließend die Ressourcen. Diesen Befehl sollten Sie nur nutzen, um nach dem Ausprobieren von Terraform die Ressourcen wieder zu entfernen, damit zum Beispiel weiterlaufende virtuelle Maschinen keine unnötigen Kosten verursachen. In produktiven Umgebungen sollte dieser Befehl mit Bedacht zum Einsatz kommen, da er im schlimmsten Fall Ihre komplette Infrastruktur entfernt.

Der bekannte Zustand

Aufmerksamen Anwendern wird nach dem Ausführen von »terraform apply« die neue Datei namens »terraform.tfstate« aufgefallen sein. Diese Datei enthält die Beschreibung des Zustands der Ressourcen, was von Terraform als State bezeichnet wird. Hier merkt sich Terraform die providerspezifischen Metadaten zu allen Ressourcen, um die richtige virtuelle Maschine in einer Cloud adressieren zu können.

Die Datei »terraform.tfstate« sollten Sie mit sehr viel Vorsicht behandeln. Manuelle Änderungen sollten Sie nicht vornehmen, entfernen sollten Sie diese Datei ebenfalls nicht. Da die State-Datei vertrauliche Informationen wie Tokens oder SSH-Schlüssel enthalten kann, sollten Sie diese Datei auch nicht in einer Versionsverwaltung speichern. Das Anlegen einer [».gitignore«-Datei [3] kann hier Abhilfe schaffen.

Da diese Datei zum Ausführen von Terraform-Befehlen essentiell ist, bietet Terraform selbst Möglichkeiten, den Zustand sicher zu speichern. Dies ist auch im Hinblick auf das Zusammenarbeiten im Team wichtig, da beim mehrfachen Ausführen von Terraform durch Sie und Ihre Kollegen ein großes Chaos entstehen könnte. Das zentrale Ablegen der State-Datei zusammen mit einer Zugriffskontrolle – sodass nur eine Änderung gleichzeitig möglich ist – sorgt hier für Abhilfe. Details hierzu finden sich in der Dokumentation zu Remote Backends [4].

Beispiel: VM in Openstack

Im Folgenden soll stellvertretend für alle Clouds eine virtuelle Maschine in einer OpenStack-Cloud erstellt werden. Um das praktisch nachzuvollziehen, benötigen Sie allerdings Zugriff auf eine solche Cloud.

Im vorangegangenen Beispiel haben Sie eine lokale Datei erzeugt. Um stattdessen eine virtuelle Maschine in einer OpenStack-Cloud anzulegen, gilt es, noch einen Schritt vor dem oben skizzierten Workflow zu absolvieren. Für das Erstellen einer lokalen Datei benötigte Terraform keine Berechtigungen, da es die Datei mit Ihrer Benutzerkennung und in Ihrem Namen erstellt hat. Damit Terraform aber auf eine OpenStack-Cloud zugreifen darf, müssen Sie ihm die Zugangsdaten dafür mitteilen. Die Vorgehensweise ist spezifisch für jeden Terraform-Provider. Bei vielen Clouds können Sie die Zugangsdaten nutzen, die auch das vom Cloud-Anbieter bereitgestellte CLI verwendet.

Bei OpenStack lässt sich ein sogenannter Application Credential anlegen, sodass Terraform zwar in Ihrem Namen agieren darf, aber nicht Ihren Benutzernamen und ihr Passwort verwendet. Stattdessen wird ein weiterer Satz Zugangsdaten erstellt, der sich bei Bedarf wieder zurückrufen und damit ungültig machen lässt. In der OpenStack-Oberfläche gelangen Sie über »Identität« in der linken Leiste zu den »Applikations-Zugangsdaten« (Application Credentials).

An dieser Stelle können Sie über die Schaltfläche »Applikations-Zugangsdaten erstellen« einen neuen Satz Zugangsdaten anlegen. Geben Sie in der folgenden Eingabemaske (Abbildung 1) einen Namen ein, und klicken Sie auf »Applikations-Zugangsdaten erstellen«. Die angezeigten Rollen unterscheiden sich unter Umständen von den in der Abbildung gezeigten, abhängig von der Konfiguration der OpenStack-Cloud und den Ihnen zugewiesenen Rollen.

Abbildung 1: Eingabemaske zum Erstellen neuer Applikationszugangsdaten.

Im folgenden Dialog werden die Zugangsdaten angezeigt, und Sie sollten eine »clouds.yaml«-Datei herunterladen. Speichern Sie diese Datei im Verzeichnis »~/.config/openstack/«, das Sie anlegen, sollte es noch nicht existieren. Setzen Sie die Berechtigungen der Datei auf »>600«, sodass nur Ihrem Benutzer der Zugriff erlaubt ist.

Der Terraform-Provider für OpenStack verwendet diese Datei automatisch, sofern Sie im Terraform-Code die verwendete Cloud angeben. Erstellen Sie hierfür eine Datei »provider.tf« mit dem Inhalt aus Listing 7, wobei Sie »CLOUDNAME« durch den Namen Ihrer Cloud in der »clouds.yaml«-Datei ersetzen.

provider "openstack" {
  cloud = "CLOUDNAME"
}

Aufbau der virtuellen Maschine

Wie im ersten Beispiel ist es notwendig, Terraform die zu verwendenden Provider mitzuteilen. Dies erfolgt wiederum über eine Datei namens »>versions.tf«, deren Inhalt Listing 8 zeigt.

terraform {
  required_providers {
    openstack = {
      source = "terraform-provider-openstack/openstack"
    }
  }
}

Um die eigentliche virtuelle Maschine erstellen zu können, benötigten Sie einige Informationen über Ihre OpenStack-Cloud. Dazu gehören die UUID des Netzwerks, die Bezeichnungen der vorhandenen Betriebssystemabbilder (Images) sowie die sogenannten Flavors. Letztere definieren die Dimensionierung der VMs, das heißt die Anzahl der zugewiesenen CPU-Kerne sowie die Größe des Arbeitsspeichers und der virtuellen Festplatte.

All diese Informationen sollten Sie in der OpenStack-Weboberfläche finden oder von den Admins Ihrer OpenStack-Cloud erhalten. Im Beispiel werden »2C-2GB-10GB« als Flavor und »openSUSE Leap 15.4« als Name des Betriebssystemabbilds verwendet. Ein minimaler Code-Schnipsel für eine OpenStack-VM würde aussehen wie in Listing 9.

resource "openstack_compute_instance_v2" "my_instance" {
  name            = "beispiel-instanz"
  flavor_name     = "2C-2GB-10GB"
  image_name      = "openSUSE Leap 15.4"
  network {
    uuid = "12345678-..."
  }
}

Mit diesem Codeschnipsel und dem bekannten Workflow aus »terraform init, terraform validate, terraform plan« und »terraform apply« erhalten Sie eine virtuelle Maschine. Um diese virtuelle Maschine jedoch auch wirklich erreichen und nutzen zu können, sind Dinge wie SSH-Schlüsselpaare, Floating IPs oder Security Groups notwendig, deren Erläuterung an dieser Stelle den Rahmen sprengen würde.

Die Dokumentation des OpenStack-Providers [5] führt alle benötigten und optionalen Parameter wie »key_pair« oder »security_groups« auf und erläutert diese. Auch Ressourcen wie »openstack_networking_secgroup_v2« zum Anlegen einer Security Group werden detailliert erklärt. Bitte vergessen Sie nach dem Ausprobieren nicht, die VM-Ressource mittels »terraform destroy« wieder zu entfernen.

VMs in anderen Clouds

Das Aufbauen von virtuellen Maschinen oder anderen Ressourcen in anderen Clouds wie AWS, GCP oder Azure funktioniert analog zum obigen Beispiel. Die Dokumentation des jeweiligen Providers enthält eine Anleitung, wie Sie die Zugangsdaten für Terraform hinterlegen. Das Erstellen der virtuellen Maschine erfolgt dann über die entsprechende Ressource des Terraform-Providers.

Hier zeigt sich der einzige Wermutstropfen bei der Verwendung von Terraform: Sie können zwar Ressourcen in vielen Clouds mit nur einem Werkzeug anlegen, aber Sie benötigen für jede Cloud respektive jeden Terraform-Provider jeweils unterschiedlichen Code. So heißt eine VM-Ressource bei OpenStack etwa »openstack_compute_instance_v2«, bei GCP dagegen »google_compute_instance«. Die unterstützten Parameter (Abbild, Flavor und so weiter) unterscheiden sich ebenfalls, was auch den unterschiedlichen Möglichkeiten der Cloud-Anbieter geschuldet ist. Je nach Cloud ist das Vorgehen zum Erzeugen von Netzwerken, Netzwerk-Interfaces, Security Groups und ähnlichem abweichend.

Ausblick

Dieser Artikel hat Ihnen die grundlegende Idee hinter und die Bedienung von Terraform gezeigt, dabei aber nur einen Bruchteil der Möglichkeiten von Terraform behandelt. Einen tiefergehenden Einstieg finden Sie im Terraform-Buch der Autoren, das im Rheinwerk-Verlag erschienen ist [6]. (jcb)