Zum Inhalt

Erkennung von Konfigurations-Drift

Ein spoke wird an ein workload-Team übergeben, das ändern kann, was in seiner subscription liegt. Diese Freiheit ist gewollt, aber ein Plattform-Team muss sehen, wann sich die Baseline eines spokes von seiner spoke-Datei entfernt hat. Diese Seite hält das Design für einen geplanten Drift-Report pro spoke fest, warum er aus der bestehenden spoke-pipeline aufgebaut wird und was er dir sagen kann und was nicht.

Entscheidungsdokument

Das ist eine Designentscheidung, geschrieben nach einem Architecture Decision Record des spoke canvas. Sie ist eine Empfehlung. Prüfe, ob die Version, die du betreibst, die Drift-pipeline mitliefert und wie sie in deinem Konfigurations-Repository eingebunden ist.

Das Problem

Nichts hindert die Owner eines spokes daran, die canvas-Ressourcen zu ändern. Contributor und Owner werden bewusst vergeben, um die Rollen einfach und das Team flexibel zu halten (Zugriff, Gruppen und PIM). Sie sind nicht dafür gedacht, die canvas-Ressourcen zu ändern, zum Beispiel Subnetze.

Das Plattform-Team will unerwünschte Änderungen sehen. Der Umfang beschränkt sich auf das, was Terraform in seinem eigenen Scope finden kann.

Anforderungen

Anforderung Folge für das Design
Ein Report muss historisch verfügbar sein Jeden Report mit Datum und Uhrzeit im Dateinamen speichern
Ein Report muss verfügbar und aktuell sein Den Report zusätzlich unter einem festen Namen speichern, der immer überschrieben wird
Reports müssen regelmäßig erzeugt werden Eine geplante pipeline, mit dem Zeitplan in der pipeline-Definition

Optionen

Option Anmerkung
Die spoke-pipeline klonen und ihre Komponenten wiederverwenden (gewählt) Wenig zu bauen, und sie bleibt stabil, wenn sich das spoke-Deployment ändert, weil das meiste derselbe Code ist
Eine Function App, die die spoke-Dateien mit der deployten Konfiguration vergleicht Braucht eine neue Komponente und eine eigene Logik dafür, was „anders“ bedeutet
Das Activity Log auf unerwünschte Änderungen analysieren Zeigt, wer was getan hat, vergleicht aber nicht mit dem Sollzustand

Entscheidung

Führe nach Zeitplan einen Plan für jede spoke-Datei aus und melde die spokes, bei denen Änderungen anstehen. Ein Plan, der nicht leer ist, bedeutet, dass die echte Konfiguration von der spoke-Datei abweicht. Das Ergebnis wird als Report in einen Storage Account geschrieben.

Konsequenzen

  • Minimaler Aufwand und minimale Wartung, weil die pipeline das spoke-Deployment wiederverwendet.
  • Der Einblick ist begrenzt. Erkannt wird nur, was in einem Terraform-Plan erscheint. Ressourcen, die das spoke canvas nicht verwaltet, oder Einstellungen, die im Code ignoriert werden, tauchen nicht auf. Behandle den Report als Indikator und nicht als Audit.
  • Der Plan kann Rauschen zeigen, das kein Drift ist. Siehe Bekannte Probleme und Die spoke-Pläne lesen.

So funktioniert es

flowchart LR
    t["Schedule"] --> p["Plan for every spoke file"]
    p --> d["Spokes with changes?"]
    d --> rep["Drift report (JSON)"]
    rep --> h["Timestamped file<br/>(history)"]
    rep --> l["Fixed-name file<br/>(latest)"]
    h --> st[("Storage account:<br/>dedicated container")]
    l --> st
Teil Detail
Storage Ein dedizierter Container in einem Storage Account. Ein vollständig deployter spoke ist ein guter Ort: Sein Storage Account hat bereits Private Endpoints und die Gruppen des spokes. Gib den Lesern des Reports die Rolle Blob Reader auf dem Container
Zugriff Die pipeline-Agents brauchen Netzwerkzugriff auf den Storage Account (am besten über einen Private Endpoint), und die Deployment-Identität braucht das Recht, Blobs zu schreiben. Wenn du dafür Netzwerk- oder Policy-Ausnahmen brauchst, dokumentiere sie als Exemptions (Governance)
Reports Jeder Lauf speichert denselben Report zweimal: einmal mit Datum und Uhrzeit im Namen, für die Historie, und einmal unter einem festen Namen, der überschrieben wird, für die Automatisierung
Zeitplan Ein Cron-Ausdruck in der pipeline. Starte die pipeline einmal manuell, weil ein Zeitplan nicht um die Genehmigung zur Nutzung des Agent Pools bitten kann

Drift im Hub

Der Hub hat keine eigene Drift-pipeline. Drift im Hub findest du, indem du hub im Plan-Modus ausführst: Jede Änderung, die du nicht committet hast, ist Drift (Monatlicher Health Check, Verantwortlichkeiten im Betrieb). Ein geplanter spoke-Drift-Report überträgt dieselbe Idee auf die spokes.

Was du mit einem Report tust

Befund Aktion
Eine Änderung, die von Hand gemacht wurde und gewollt ist Übernimm sie per pull request in die spoke-Datei (Spoke ändern)
Eine Änderung, die von Hand gemacht wurde und nicht gewollt ist Mach sie rückgängig. Ein normaler spoke-Lauf stellt den definierten Zustand wieder her
Eine spoke-Datei, die aus unklarem Grund nicht mehr zum Plan passt Prüfe zuerst das Plan-Rauschen in den Bekannten Problemen