29-7 · Kapitel 29 · 7 Min. Lesezeit

Wenn sich die Infrastruktur außerhalb Ihrer Pipeline ändert: Eine Übung zur Drift-Erkennung

Erfahren Sie, wie Infrastruktur-Drift entsteht, wie Sie ihn mit Terraform erkennen und welche Entscheidungen zur Wiederherstellung oder Übernahme der Änderungen nötig sind.

Wenn sich die Infrastruktur außerhalb Ihrer Pipeline ändert: Eine Übung zur Drift-Erkennung

Sie haben eine Terraform-Konfiguration, die eine Security Group definiert. Sie hat den richtigen Namen, die korrekten Inbound-Regeln und die passenden Tags. Ihre Pipeline lief erfolgreich, die Ressource wurde erstellt, und Ihre State-Datei ist sauber. Alles sieht gut aus.

Dann meldet sich jemand in der Cloud-Konsole an und nimmt eine kleine Änderung vor. Vielleicht wird die Security Group umbenannt, weil der Name verwirrend war. Vielleicht wird eine Inbound-Regel hinzugefügt, um schnell etwas zu testen. Vielleicht wird ein Tag entfernt, das unnötig erschien. Keine Code-Änderungen. Kein Pipeline-Durchlauf. Nur eine manuelle Anpassung in der Konsole.

Ihre Infrastruktur ist jetzt anders, als Ihr Code es vorsieht. Dieser Unterschied wird als Drift bezeichnet. Und wenn Sie nicht wissen, dass er passiert ist, könnte Ihre nächste Bereitstellung Dinge auf eine Weise beschädigen, die Sie nicht erwartet haben.

Wie Drift tatsächlich aussieht

Drift tritt auf, wenn der tatsächliche Zustand Ihrer Infrastruktur vom gewünschten Zustand abweicht, der in Ihrem Code definiert ist. Es ist kein theoretisches Problem. Es passiert ständig in echten Teams:

Jemand behebt ein dringendes Problem direkt in der Produktion, weil die Pipeline zu lange dauern würde.
Ein Cloud-Anbieter rotiert automatisch ein Zertifikat oder ändert eine Standardeinstellung.
Ein Teammitglied löscht versehentlich eine Ressource, während es etwas anderes aufräumt.
Eine automatisierte Richtlinie außerhalb Ihrer Pipeline ändert eine Ressource aus Compliance-Gründen.

Das Problem ist nicht, dass Drift existiert. Das Problem ist, dass Sie nichts davon wissen, bis etwas kaputtgeht.

Eine einfache Übung, um Drift in Aktion zu sehen

Sie können Drift in Ihrer eigenen Umgebung mit minimalem Aufwand simulieren. Sie benötigen ein Cloud-Konto mit Free-Tier-Ressourcen oder einen lokalen Simulator wie LocalStack. Selbst eine Mock-State-Datei reicht für Lernzwecke aus.

Erstellen Sie zunächst eine Ressource mit Terraform. Eine Security Group in AWS oder ein Storage-Bucket in einem beliebigen Cloud-Anbieter eignet sich gut. Führen Sie Ihre Pipeline aus, bis die Ressource erstellt und die State-Datei gespeichert ist. Stellen Sie sicher, dass Sie die Ressource in der Cloud-Konsole sehen können.

Hier ist eine minimale Terraform-Konfiguration, die Sie verwenden können:

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_security_group" "web_sg" {
  name        = "web-server-sg"
  description = "Allow HTTP and SSH traffic"

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name = "web-server-sg"
    Env  = "test"
  }
}

Führen Sie terraform init und terraform apply aus, um die Security Group zu erstellen. Benennen Sie dann in der AWS-Konsole die Security Group manuell in web-server-sg-manual um und entfernen Sie das Tag Env. Führen Sie schließlich terraform plan aus, um den Drift zu sehen:

$ terraform plan
aws_security_group.web_sg: Refreshing state... [id=sg-0123456789abcdef0]

Terraform will perform the following actions:

  # aws_security_group.web_sg will be updated in-place
  ~ resource "aws_security_group" "web_sg" {
        id          = "sg-0123456789abcdef0"
      ~ name        = "web-server-sg-manual" -> "web-server-sg"
        tags        = {
          - "Env"  = "test" -> null
            "Name" = "web-server-sg"
        }
        # (6 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Der Plan zeigt, dass Terraform den Namen zurücksetzen und das fehlende Tag wieder hinzufügen wird. Das ist Drift in Aktion.

Öffnen Sie nun, ohne Ihren Terraform-Code zu berühren, die Cloud-Konsole und nehmen Sie eine manuelle Änderung vor. Hier sind ein paar Dinge, die Sie ausprobieren können:

Benennen Sie die Security Group um.
Fügen Sie eine Inbound-Regel hinzu, die in Ihrem Code nicht existiert.
Entfernen Sie ein Tag, das Ihr Code definiert.
Ändern Sie die Einstellung für den öffentlichen Zugriff des Buckets.

Das Ziel ist es, eine Situation zu schaffen, in der die tatsächliche Ressource nicht mehr mit Ihrem Code übereinstimmt. Das ist Drift.

Das folgende Flussdiagramm veranschaulicht die Ereignisabfolge in dieser Drift-Erkennungsübung:

flowchart TD A[Gewünschter Zustand: Terraform Config] --> B[Pipeline erstellt Ressource] B --> C[Tatsächlicher Zustand entspricht Config] C --> D[Manuelle Änderung in der Konsole] D --> E[Tatsächlicher Zustand weicht von Config ab] E --> F[terraform plan ausführen] F --> G{Plan zeigt Änderungen?} G -- Ja --> H[Drift erkannt] G -- Nein --> I[Kein Drift] H --> J{Entscheidung zur Wiederherstellung} J -- Änderung übernehmen --> K[Terraform-Code aktualisieren] J -- Config wiederherstellen --> L[terraform apply ausführen] K --> M[Pipeline läuft, Zustand stimmt überein] L --> M

Terraform Plan nach Drift ausführen

Nachdem Sie die manuelle Änderung vorgenommen haben, führen Sie terraform plan in Ihrem Terminal aus. Sehen Sie sich die Ausgabe genau an. Terraform vergleicht Ihre State-Datei mit der tatsächlichen Ressource und zeigt Ihnen, was es ändern würde, wenn Sie apply ausführen.

Beachten Sie etwas Wichtiges: Der Plan könnte Änderungen zeigen, die Sie nicht erwartet haben. Vielleicht möchte er die Security Group wieder in den ursprünglichen Namen umbenennen. Vielleicht möchte er die Regel entfernen, die jemand hinzugefügt hat. Aber er könnte auch Änderungen an anderen Ressourcen anzeigen, die von der geänderten abhängen. Eine einfache Umbenennung könnte einen Load Balancer, eine Target Group oder eine IAM-Richtlinie betreffen, die die Security Group beim Namen referenziert.

Deshalb können Sie einem Plan nach einem Drift nicht blind vertrauen. Der Plan könnte korrekt sein, aber Sie müssen jede vorgeschlagene Änderung überprüfen. Ein Plan, der an der Oberfläche sauber aussieht, könnte kaskadierende Effekte verbergen, die andere Teile Ihrer Infrastruktur beschädigen.

Drift explizit erkennen

Terraform hat einen Befehl namens terraform refresh, der Ihre State-Datei mit dem tatsächlichen Zustand Ihrer Ressourcen aktualisiert. Führen Sie ihn aus, und führen Sie dann terraform plan erneut aus. Sie werden denselben Drift sehen, aber jetzt spiegelt Ihre State-Datei die Realität wider. Das ist nützlich, um zu verstehen, was sich geändert hat, aber es behebt den Drift nicht. Es bestätigt ihn nur.

Einige Plattformen wie Spacelift oder Terragrunt haben eine integrierte Drift-Erkennung, die nach einem Zeitplan läuft. Sie können Sie benachrichtigen, wenn Drift erkannt wird, und einige können sogar eine automatische Wiederherstellung auslösen. Aber für diese Übung reicht die manuelle Erkennung aus, um die Mechanik zu verstehen.

Notieren Sie, welche Ressourcen abgewichen sind und was sich geändert hat. Diese Aufzeichnung hilft Ihnen, über den nächsten Schritt nachzudenken.

Eine Entscheidung zur Wiederherstellung treffen

Jetzt haben Sie eine Wahl. Sie wissen, dass die Infrastruktur abgewichen ist. Sie wissen, was sich geändert hat. Was tun Sie dagegen?

Stellen Sie sich diese Fragen:

War die manuelle Änderung beabsichtigt? Hat sie jemand aus einem legitimen Grund vorgenommen, z. B. um ein dringendes Problem zu beheben?
Ist die Änderung noch erforderlich? Vielleicht ist der Notfall vorbei und die Ressource sollte in ihren ursprünglichen Zustand zurückversetzt werden.
Ist es sicher, die Änderung rückgängig zu machen? Ein Rückgängigmachen könnte etwas beschädigen, das jetzt von der neuen Konfiguration abhängt.
Weiß jemand im Team, warum die Änderung vorgenommen wurde? Gibt es eine Aufzeichnung in einem Ticket oder einem Chat-Log?

Wenn Sie sich für eine Wiederherstellung entscheiden, führen Sie terraform apply aus. Die Ressource sollte in den in Ihrem Code definierten Zustand zurückkehren. Überprüfen Sie, ob alles wie erwartet funktioniert.

Wenn Sie sich entscheiden, die Änderung zu übernehmen, aktualisieren Sie Ihren Terraform-Code, um dem tatsächlichen Zustand zu entsprechen. Führen Sie dann Ihre Pipeline normal aus. Der Drift ist jetzt behoben, weil Ihr Code und Ihre Infrastruktur wieder übereinstimmen.

Variationen zum Ausprobieren

Sobald Sie das grundlegende Szenario verstanden haben, probieren Sie komplexere Variationen aus:

Nehmen Sie eine temporäre Änderung vor, z. B. die Erhöhung der Instanzkapazität während eines Traffic-Anstiegs. Beobachten Sie, wie die Drift-Erkennung sie nach dem Ende des Anstiegs erfasst.
Ändern Sie eine Ressource mit Abhängigkeiten, z. B. die Konfiguration eines Load Balancers, der mit einer Target Group verbunden ist. Beobachten Sie, wie der Plan kaskadierende Effekte zeigt.
Erstellen Sie eine Änderung, die schwer rückgängig zu machen ist, z. B. das Löschen einer Ressource, von der andere Ressourcen abhängen. Beobachten Sie, wie Terraform die Abhängigkeitskette behandelt.

Jede Variation lehrt Sie etwas darüber, wie sich Drift in realen Systemen verhält. Je komplexer das Szenario, desto klarer wird, dass Drift-Erkennung und -Wiederherstellung sorgfältiges Nachdenken erfordern, nicht nur Automatisierung.

Eine praktische Checkliste für das Drift-Management

Bevor Sie fortfahren, hier eine kurze Checkliste für Ihre eigene Umgebung:

Richten Sie eine automatisierte Drift-Erkennung für Ihre kritischen Infrastrukturressourcen ein.
Definieren Sie einen klaren Prozess für den Umgang mit Drift: wer benachrichtigt wird, wie Entscheidungen getroffen werden und wann eine Wiederherstellung ausgelöst wird.
Führen Sie Aufzeichnungen über manuelle Änderungen, auch über temporäre, damit das Team weiß, warum Drift existiert.
Testen Sie Ihren Wiederherstellungsprozess in einer Nicht-Produktionsumgebung, bevor Sie ihn in der Produktion anwenden.
Überprüfen Sie Drift-Berichte regelmäßig, nicht nur, wenn etwas kaputtgeht.

Was diese Übung lehrt

Drift ist kein theoretisches Konzept. Es ist ein reales operatives Problem, mit dem jedes Team konfrontiert ist, wenn die Infrastruktur durch Code verwaltet wird. Die Übung zeigt Ihnen, dass Drift stillschweigend auftreten kann, dass er mehr als nur die geänderte Ressource betreffen kann und dass Wiederherstellungsentscheidungen immer vom Kontext abhängen.

Sie können nicht allen Drift verhindern. Menschen werden manuelle Änderungen vornehmen. Cloud-Anbieter werden Ressourcen ändern. Notfälle werden passieren. Was Sie tun können, ist, Drift frühzeitig zu erkennen, seine Auswirkungen zu verstehen und fundierte Entscheidungen zu treffen, ob Sie die Änderung rückgängig machen oder übernehmen.

Wenn das nächste Mal jemand sagt: "Ich habe nur schnell eine kleine Korrektur in der Konsole vorgenommen", werden Sie genau wissen, was das für Ihre Infrastruktur bedeutet. Und Sie werden einen Prozess bereit haben, um damit umzugehen.