Jemand hat in der Konsole geklickt:

Es ist 16 Uhr. - Ich bin nicht hier. Die Produktion ist langsam. Jemand öffnet die Cloud-Konsole und erhöht die Größe der Datenbank, nur um das Wochenende zu überstehen. Es funktioniert. Alle gehen erleichtert nach Hause.

Drei Wochen später läuft jemand terraform apply für eine unabhängige Änderung. Terraform sieht, dass die Datenbank größer ist, als der Code sagt, und schrumpft hilfreich zurück. Die Produktion verlangsamt sich wieder, und niemand versteht, warum.

Das ist Drift: der Unterschied zwischen dem, was der Infrastrukturcode sagt und dem, was tatsächlich existiert.

Woher kommt der Drift

• Handliche Schnellbehebungen in der Konsole während Vorfällen.
• Schnelle Experimente Das sollte vorübergehend sein.
• Andere Werkzeuge Ändern der gleichen Ressourcen: Autoscaler, Cloud-verwaltete Standardeinstellungen, Sicherheitswerkzeuge, die Tags hinzufügen.
• Leute, die es nicht wissen. eine Ressource wird durch Code verwaltet.
• Nicht oder teilweise angewendet Das hat die Dinge halb verändert.

Ein wenig Drift ist harmlos. Einige sind gefährlich: eine Sicherheitsgruppe wurde "vorübergehend" geöffnet, eine Verschlüsselungseinstellung wurde zum Debugged off.

Drift ist kein technisches Problem. Es ist eine Lücke zwischen der Art und Weise, wie Menschen unter Druck arbeiten und wie Ihr Prozess von ihnen erwartet, dass sie arbeiten.

Finden

Pläne. Der einfachste Ansatz: laufen terraform plan Sie werden auf einem Zeitplan (täglich ist üblich) für jeden Staat angezeigt und alarmiert, wenn Änderungen auftreten. Verwenden Sie den Ausgangscode:

terraform plan -detailed-exitcode -lock=false
# exit code 0 = no changes
# exit code 1 = error
# exit code 2 = changes detected (drift, or unapplied code)

Ein kleiner Informantenjob, der das über deine Stacks und Posts auf Slack läuft, ist oft genug.

Nur für die Erneuerung. terraform plan -refresh-only zeigt nur, was sich in der realen Welt geändert hat, ohne Änderungen aus Ihrem Code einzubeziehen.

Plattformen. HCP Terraform, Spacelift, env0, Scalr und andere haben eine eingebaute Drift-Detektion mit Armaturenbrett und geplanten Kontrollen.

Cloud-native Tools. Das ist ein sehr schwieriger Fall. AWS Config, Azure Policy und ähnliche Dienste können Änderungen an Ressourcen und nicht konformen Konfigurationen kennzeichnen, einschließlich Ressourcen, die überhaupt nicht durch Code verwaltet werden.

Ich repariere es.

Wenn man Drift findet, gibt es zwei Richtungen:

1. Code gewinntDie manuelle Umstellung war ein Fehler. Lauf ! apply Zur Wiederherstellung des deklarierten Zustands.
2. Die Realität gewinnt: die manuelle Änderung war richtig (wie die größere Datenbank). Aktualisieren Sie den Code, um zu entsprechen, dann apply zeigt keine Veränderungen.

Der wichtige Teil ist, bewusst zu entscheiden. Du rennst nie einfach weg. apply Blind auf einem treibenden Stapel, ohne zu verstehen, was sich ändern wird. Lesen Sie den Plan.

Für Ressourcen, die vollständig von Hand erstellt wurden, werden sie unter der Leitung von Einfuhrblöcke:

import {
  to = aws_s3_bucket.legacy_logs
  id = "acme-legacy-logs"
}

Dann ... terraform plan -generate-config-out=generated.tf Ich kann sogar einen ersten Entwurf der Konfiguration für Sie schreiben.

Sie zu verhindern

Die Erkennung ist gut. Vorbeugung ist besser:

• Standardmäßig nur Lesekonsole-Zugriff. Die meisten Leute brauchen keinen Schreibzugriff auf Produktionskonsolen. Verwenden Sie Glasbrecherrollen für Notfälle, mit Protokollen und Warnungen.
• Ein schneller Weg für dringende Veränderungen. Wenn das Codewechseln und Anwenden eine Stunde dauert, benutzen die Leute die Konsole. Der Code ist schnell genug für Zwischenfälle.
• Nach den Vorfällen. Wenn jemand manuell repariert hat, heißt es in der Obduktion "Update Code".
• Verwaltete Ressourcen mit Tags (managed_by = terraformDamit die Leute wissen, dass man sie nicht anfassen darf.
• Politiken mit AWS SCPs, Azure Policy oder ähnlichem, um die gefährlichsten manuellen Änderungen vollständig zu blockieren.
• Verwendung ignore_changes Vorsicht ! für Attribute, die andere Systeme legitim verwalten, wie z. B. die gewünschte Kapazität einer Autoscaling-Gruppe.

lifecycle {
  ignore_changes = [desired_capacity]
}

Wie viel Drift ist akzeptabel?

Es wird immer etwas passieren, besonders bei Unfällen. Das Ziel ist nicht Null-Drift. Es ist, es innerhalb eines Tages zu wissen und es absichtlich zu lösen. Ein nächtlicher Drift-Check plus die Gewohnheit, Code nach manuellen Korrekturen zu aktualisieren, bringt dich fast durch.

Meine Meinung: Die Konsole ist nicht der Feind. Vergessen, was du darin gemacht hast, ist. Entdecken Sie die Drift früh und machen Sie den Code zum Ort, an dem die Wahrheit lebt.

Desly