Wie verwaltet man den Terraform-Status?

Hinweis der Redaktion: Dieser Beitrag erschien ursprünglich auf CloudSkiff.com. CloudSkiff wurde Teil von Snyk im Oktober 2021.

Wie verwaltet man den Terraform-Status? Und was ist eigentlich eine TFState-Datei? Wie unterscheidet sich Terraform-Code dadurch von anderen Konfigurationsmanagement-Tools, und welche Best Practices gibt es dafür?

Wie verwaltet man den Terraform-Status?

Zu wissen, wie man den Terraform-Status verwaltet, ist entscheidend. Doch zunächst: Was genau ist ein TFState?

Die TFState-Datei unterscheidet Terraform von anderen Systemen. Mit anderen Konfigurationsmanagement-Tools wie Chef, Saltstack und Ansible können Sie Infrastrukturen bereitstellen und starten. Der größte Unterschied bei Terraform liegt jedoch in diesem Status.

Sie können sich Ihre TFState-Datei als große JSON-Struktur vorstellen, die den tatsächlichen Zustand Ihrer Infrastruktur abbildet. Zusammen mit dem Terraform-Code definiert sie den sogenannten „gewünschten Zustand“, den Sie erreichen möchten.

Dieser gewünschte Zustand ist deklarativ. Das bedeutet: Wenn Sie in Ihrem Code eine bestimmte Ressource mit einer bestimmten Konfiguration definieren und diesen Code mit apply anwenden, „spricht“ Terraform mit der API Ihres Cloud-Anbieters und erstellt anschließend all diese Ressourcen. Sobald der Vorgang abgeschlossen ist, schreibt Terraform den tatsächlichen Zustand der Bereitstellung aufseiten des Cloud-Anbieters in diese JSON-Datei.

Am Ende haben Sie drei Zustände und drei Instanzen:

• Ihren Code

• den tatsächlichen Zustand in Ihrem Cloud-Anbieterkonto

• die Statusdatei

Die Statusdatei ist genau das Abbild des letzten erfolgreichen apply Ihres Codes. Sie funktioniert mit allen Arten von Ressourcen. Das heißt: Sie können sie mit Ihrem Cloud-Anbieter verwenden, wenn Sie Infrastrukturressourcen bereitstellen möchten, aber auch mit beliebigen anderen Anbietern.

Angenommen, Sie stellen Helm-Charts mit Terraform bereit. Dann erhalten Sie auch eine Statusdatei für Ihre Bereitstellungen. Bei GitHub ist es genauso. Wenn Sie den GitHub-Provider verwenden, Benutzer definieren und derselbe Benutzer für ein Projekt in Google Cloud sowie als IAM in AWS als GitHub-Benutzer verwendet wird, wird dieser Benutzer in der Terraform-Statusdatei erfasst – alle Verknüpfungen sind dort festgehalten.

Betrachten Sie sie als Referenz für den tatsächlichen Zustand der bestehenden Infrastruktur, auf die Sie in Ihrem Code Bezug nehmen können.

Kurz gesagt: Eine Statusdatei bildet den tatsächlichen Zustand Ihrer Bereitstellung bei Ihrem Cloud-Anbieter ab, basierend auf der Absicht, die in Ihrem Terraform-Code festgelegt ist.

Wie gehen Sie damit um und wo speichern Sie Ihren Terraform-Status?

Standardmäßig gibt es keine Option. Wenn Sie Ihr Git-Repository zum ersten Mal mit Terraform-Code initialisieren und einen kleinen Terraform-Code anwenden, wird die TFState-Datei direkt im Stammverzeichnis Ihres GitHub-Repositorys erstellt. Sie müssen sie irgendwo einchecken. Standardmäßig könnten Sie versucht sein, sie auf GitHub hochzuladen – das machen viele. Das gehört jedoch nicht zu den Best Practices, denn die Datei kann Geheimnisse enthalten, die Sie wahrscheinlich nicht auf GitHub hochladen möchten.

Trotzdem müssen Sie Ihre Statusdatei speichern. Wenn Sie sie nicht speichern, verlieren Sie den Zustand, den Terraform als „bestehende Infrastruktur“ betrachtet. Wenn Sie die Datei also löschen und erneut ein Apply ausführen, versucht Terraform, die gesamte Infrastruktur erneut als „neu“ bereitzustellen. Das möchten Sie wahrscheinlich vermeiden.

Best Practice ist, sie an einem gemeinsam genutzten Speicherort abzulegen, üblicherweise in einem Amazon-S3-Bucket oder einem anderen Speicher-Bucket auf AWS, Azure oder Google Cloud:

1resource "aws_instance" "vm" {
2  ami                    = data.aws_ami.amazon-linux.id
3  instance_type          = var.instance_type
4  tags = {
5    Name = "DEMO VM DESTROY ME - ${terraform.workspace}",
6    Terraform = "true"
7  }
8}
9
10data "aws_ami" "amazon-linux" {
11  most_recent = true
12  owners = ["amazon"]
13
14  filter {
15    name   = "name"
16    values = ["amzn-ami-hvm-*"]
17  }
18
19}

Im Grunde deklarieren Sie also Ihr Backend. In diesem Beispiel handelt es sich um einfachen Code, der eine einzelne VM bereitstellt. Er dient nur zu Demonstrationszwecken. Ich verwende ihn, um mit meinen Terraform-Workspaces zu experimentieren und sie zu testen. Verwenden Sie ihn also nicht für umfangreiche Arbeiten.

Sie können Terraform mit dem Terraform-Schlüsselwort konfigurieren und angeben: „Für Terraform soll mein Backend S3 sein, und der S3-Bucket soll dieser hier sein.“

Sie geben an, wo Ihre Statusdatei gespeichert werden soll. Mehr ist nicht nötig. Beim nächsten Terraform apply verwendet Terraform lokal eine temporäre Statusdatei und lädt sie anschließend in Ihren S3-Bucket hoch.

Bei jeder weiteren Arbeit damit wird dann diese Datei verwendet.

1terraform {
2  backend "s3" {
3    bucket = "cs-tfstates-demo-sj-frankfurt-1"
4    key    = "tfstates/terraform.tfstate"
5  }
6}

Ein letzter Tipp: Vergessen Sie nicht, auch eine Sperrdatei in einer Datenbank anzulegen. So können nicht zwei Personen gleichzeitig eine destruktive Aktion starten oder ein Apply in Terraform ausführen, solange diese Sperre besteht.

Sichern Sie Ihren Terraform-Code

Snyk IaC sichert Ihre Terraform-Konfigurationen (sowie Kubernetes-, CloudFormation- und ARM-Vorlagen!) direkt beim Schreiben – mit konkreten Lösungsvorschlägen, damit Sie Ihre Änderungen zusammenführen und weitermachen können. Testen Sie Ihren Code schon während der Entwicklung, überwachen Sie Änderungen in Ihren Git-Repositorys und automatisieren Sie Tests in Ihren Build-Pipelines vor der Bereitstellung. Mit einem kostenlosen Tarif sind Sie in wenigen Minuten startklar. Eine Sicherheitsverletzung aufgrund einer IaC-Fehlkonfiguration kann hingegen lebenslange Folgen haben. Registrieren Sie sich und sichern Sie Ihre Konfigurationen noch heute.