In diesem Artikel lernst du die Basics des Terraform State Managements. In Teil 2 (erscheint Ende März 2021) wirst du dann über einen Deep Dive zum Arbeiten mit dem State lesen können.

In meinem IaC Starter Guide hast du bereits die Grundlagen von Terraform gelernt. Du hast gelernt, wie du ganz einfach die Infrastruktur für eine simple Webseite mit AWS S3 aufbauen kannt.

Heute schauen wir uns den Terraform State und das State Management genauer an.

Der State - ein Ort für all deine Ressourcen

States

Mit Terraform erstellst du über ein Skript deine Infrastruktur-Ressourcen für einen Provider bereit - in unserem Fall zum Beispiel für ein Setup in der AWS Cloud. Aber woher weiß Terraform, welche Ressource bereits angelegt ist, was hinzugefügt, gelöscht oder aktualisiert werden muss?

Hier kommt der Terraform State ins Spiel. Terraform sichert damit die erstellten Ressourcen mitsamt ihrer Konfiguration. Es wird alles in der .tfstate Datei gespeichert. Eine Datei mit einer JSON-Struktur.

Der State nimmt somit in deinem Terraform Setup eine sehr wichtige Rolle ein. Ist kein State vorhanden, geht Terraform automatisch davon aus, dass alle Ressourcen neu angelegt werden.

Backends

Der State ist Teil des sogenannten Backends, welches für die Ausführung von Operationen verantwortlich ist. Der gespeicherte State in einem Backend ist also ein Momentaufnahme der von Terraform erstellten Ressourcen. Je nachdem wie du das Backend konfigurierst, verwendest du eine von zwei Arten des States.

Arten von States

Bei Terraform unterscheidet man zwischen zwei Arten von States:

  • Local - also, z.B. auf deinem PC und
  • Remote - nicht lokal gespeichert, z.B. auf einem zentralen Server oder in der Terraform Cloud

Zwei Arten von States

Der Local State

Wenn du keine explizite Kofiguration für das Backend anlegst, erstellt Terraform automatisch einen local state. Die lokale Speicherung eigent sich vor allem für Einsteiger zu. Der local state wird in deinem Terraform Hauptverzeichnis in der terraform.tfstate Datei.

Ich empfehle dir, dich mit der State Datei zu beschäftigen, um zu verstehen, wie die Definitionen und Konfigurationen deiner Ressourcen gespeichert sind.

Konfiguration des lokalen States

Du kannst auch explizit einen lokalen State konfigurieren. Das kann dann nützlich, wenn du deine States lokal an einem zentralen Ort speicherst. Du kannst auch den Dateinamen des States ändern. Das lokale Backend ist wie folgt definiert:

1
2
3
4
5

terraform {
  backend "local" {
    path = "relative/path/to/terraform.tfstate"
  }
}

Ist die Datei, die über path definiert wurde, noch nicht vorhanden, wird sie neu angelegt.

Der Remote State

Ein remote state bezeichnet einen Terraform State, der nicht lokal auf deinem Rechner liegt, sondern an einem anderen, zentral erreichbaren Daten-Speicherort.

Du kannst zwischen verschiedenen Möglichkeiten wählen, deinen State remote zu speichern: z.B. über AWS S3, Azure Blob Storage, eine REST Schnittstelle uvm. Der Remote State wird über ein konfiguriertes Backend implementiert. Eine Übersicht über verschiedene Backends findest du hier: Überblick zu Terraform Remote Backends

Wann solltest du einen Remote State verwenden?

Bei Arbeit in Teams

Wenn mehrere Team-Mitglieder am Infrastruktur-Setup arbeiten, macht es Sinn den State zentral zu speichern und somit auch zusätzlich zu sichern. Zusätzlich unterstützt ein eingerichtetes [State Locking](internal link) dich, dass Änderungen sich nicht gegenseitig korrumpieren.

Bei Aufteilung deines Setups in kleinere Komponenten

Bei einem großen Infrastrukturaufbau kann es sinnvoll sein das Setup in kleinere, wartbare Komponenten aufzuteilen. Der State hilft dir wichtige Daten der jeweiligen Komponente als Output für andere Komponenten bereitzustellen. Das ist auch dann sinnvoll, wenn verschiedene Teams einzelne Komponenten betreuen.

Outputs aus einem State können mit der terraform_remote_state Data Source eingebunden werden. Mehr zur terraform_remote_state Data Source kannst in Part 2 lesen.

Zur sicheren Speicherung und Versionierung

Je nachdem, wo du deinen remote state speicherst, kannst du zusätzlich Verschlüsselung oder Versionierung für den State-Datei nutzen. Wenn du z. B. AWS S3 als Backend verwendest, kannst du S3 Encryption zum Verschlüsseln deiner State-Datei und S3 Versioning zum Speichern jeder Version des States verwenden. Du kannst auch ein Versionskontrollsystem wie Git nutzen um deinen State dezentral zu speichern. Wenn du Gitlab verwendest, kann das eine Möglichkeit sein.

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Beim Einsatz von Continious Integration/ Continious Deployment (CI/CD)

Automatisierung ist ein Muss, wenn man ein erfolgreiches Softwareprojekt umsetzen möchte. Mit einem remote state Status ist dein Setup nicht von einem bestimmten lokalen Speicherort abhängig. Stellen sicher, dass dein CI/CD Pipeline-Tool Zugriff auf die Statusdatei hat und du bist bereit für eine automatisierte Bereitstellung der Infrastruktur. 🚀

Ich arbeiten bei meinen Setups grundsätzlich mit einen Remote State. Somit stelle ich sicher, dass die Ressourcenverwaltung zentral organisiert und in ein automatisiertes Deployment eingebettet ist. Außerdem können so mehrere Leute aus meinem Team an dem Setup arbeiten.

Einen Remote State mit AWS S3 erstellen

💥 Achtung: Der S3 Bucket muss bereits vorhanden sein.

Um deinen State in einem AWS S3 Bucket zu speichern, wird ein backend vom Typ s3 implementiert.

1
2
3
4
5
6
7

terraform {
  backend "s3" {
    bucket = "mybucket" # unique S3 bucket name
    key    = "path/to/my/key" #ex: awesome/s3-backend/terraform.tfstate
    region = "eu-west-1"
  }
}

Bedenke, dass du Zugriff auf den Bucket haben musst.

Arbeiten mit dem State

Der State sichert nicht nur deine Terraform Ressourcen. Du kannst deinen State auch erweitern, modifizieren oder sperren. In Teil 1 der Serie “Terraform Statemanagement like a Boss” zeige ich dir folgende zwei Möglichkeiten mit dem State zu arbeiten.

Ressourcen importieren

Du hast schon Ressourcen wie Server, Datenbanken usw. bei einem Provider erstellt? Kein Problem! Mit einem Import kannt du bereit erstellte Ressourcen in einen State importieren.

Das geht ganz einfach über mit terraform import.

Terraform verwaltet dann zukünftig die Ressource für dich.Das ist sehr nützlich, bei einem Wechsel auf Infrastructure as Code. Manchmal kann es passieren, dass Ressourcen zum Test, aus Zeitnot, Unwissenheit oder auch, weil sie noch nicht für Terraform verfügbar sind, manuell angelegt wurden. Das Importieren gibt dir somit die Sicherheit, dass du auch zukünftig deine Infrastruktur nachhaltig bauen kannst.

Wie kannst du Ressourcen importieren?

Es gibt für jede Ressource eines Provider in der Terraform Doku am Ende das Import Statement unter Import.

So kannst du zum Beispiel einen S3 bucket importeierten:

# Syntax: terraform import <provider resource type>.<resource name> <ident of the resource being imported>
terraform import aws_s3_bucket.bucket my-awesome-bucket-name

💡 Gewusst wie: Damit du Ressourcen erfolgreich importieren kannst, musst du auf einiges achten:

  • Die Ressource, die du impotieren möchtest, muss in Terraform vorher definiert sein. Sie muss also bereits einen Name haben, auf den du referenzieren kannst (siehe Import-Befehl oben).
  • Es werden keine Konfigurationen importiert. Im Planning Step kannst du dann sehen welche Konfiguration verwendet wurde und die Terraform Ressource entsprechend anpassen, falls nötig.

Ein Importhelfer für AWS Resourcen

Um AWS-Ressourcen inklusive ihrer Konfiguration als Terraform-Ressourcen zu importieren kann dir Terraforming von Daisuke Fujita helfen. Es deckt nicht alle AWS Ressourcen ab, kann aber für die gängisten eine super Unterstützung sein.

State Locking

Wenn mehrere Kolleg*innen im Team an der Infratruktur arbeiten, auf den State zugreifen und Dinge ändern, ist ein Locking - also ein Sperren - des Terraform States nötig. Es wird damit verhindert, dass der State beschädigt wird.

State Locking ist nicht für jedes Backend verfügbar. Mit dem S3 Backend kann eine AWS DynamoDB zur Verwaltung des Locking Status verwendet werden.

1
2
3
4
5
6
7
8

terraform {
  backend "s3" {
    bucket = "mybucket" # unique S3 bucket name
    key    = "path/to/my/key" # ex: awesome/s3-backend/terraform.tfstate
    region = "eu-west-1"
   dynamodb_table = "name_oy_my_dynamodb_table"
  }
}

💥Achtung: Die verwendete DynamoDB muss den Primärschlüssel (hash_key) LockID vom Typ String haben. Sonst wird State Locking nicht verwendet.

Ausblick: State Manipulation

Mit der Manipulation des States geifst du aktiv in den State ein. Die Terraform CLI bietet dir die Möglichkeit dazu. Es können Ressourcen gelöscht, verschoben oder auch komplett noch einmal neu angelegt werden. In Teil Zwei der Serie Terraform State Management like a Boss erfährst du mehr zur Manipulation des States.

Tipps und Tricks

Pass auf bei sensiblen Daten und verwende eine Verschlüsselung

Sei vorsichtig, wenn du mit sensiblen Daten (z.B. Passwörter oder IDs) in deinem Terraform Skript arbeitest. Bei lokalen States speichert Terraform alles in Klartext in der State Datei (in terraform.tfstate). Für Remote States gilt: Die State Dateien können je nach verwendetem Backend und Konfiguration verschlüsselt werden. Der State befindet sich nur im Speicher, wenn Terraform ihn verwendet.

Es wird empfohlen Terraform Cloud oder AWS S3 als Backend Konfiguration zu verwenden. Bei beiden kannst eine Verschlüsselung anschalten. Bei einem S3 Backend schaltest du die Encryption über die Eigenschaft encrypt an.

💥Achtung: Der S3 Bucket muss dabei mit der S3 Verschlüsselung (SSE-S3) eingerichtet sein.

1
2
3
4
5
6
7
8

terraform {
  backend "s3" {
    bucket = "mybucket" # unique S3 bucket name
    key    = "path/to/my/key" # ex: awesome/s3-backend/terraform.tfstate
    region = "eu-west-1"
   encrypt = true
  }
}

S3 Backend: Schalte Versioning an

Ein AWS S3 Bucket als Backend bietet nicht nur die Möglichkeit der Verschlüsselung (serverseitung und at REST), sondern auch eine Versionierung. Damit werden alte Versionen deines States beibehalten. Mit einer entsprechenden Lifecycle Policy für den Bucket kannst du dann auch ältere Versionen regelmäßig archivieren - also z.B. in einen andere S3 Speicherklasse sichern.

💡 Acloudguru hat dafür die komplette Einrichtung (inkl. State Locking) ein super Tutorial veröffentlicht: http://aws-cloud.guru/terraform-aws-backend-for-remote-state-files-with-s3-and-dynamodb/

Referenzen:

Wie hat dir dieser Beitrag gefallen? Lass es mich doch gerne mit einem Feedback, Like oder Share auf Twitter wissen.

Happy Coding und bis zum nächsten Beitrag!

Nora See ya!