Zum Inhalt

Erkennung von Konfigurations-drift bei spokes

Nachdem ein spoke deployt wurde, hindert nichts seine Owner daran, die Baseline-Ressourcen zu ändern. Das ist so gewollt: Es hält die Rollen einfach und den spoke flexibel. Workload-Teams sollen die Baseline-Ressourcen des spoke canvas nicht ändern (Was du bekommst, Einschränkungen). Die pipeline für die spoke-drift-Erkennung zeigt, was trotzdem geändert wurde.

Sie funktioniert wie der wöchentliche drift-Check des hub (Wartungskalender), für jede spoke-Datei: Die pipeline plant jeden spoke und meldet, ob der Plan Ressourcen ändern will. Eine geplante Änderung bedeutet, dass Azure nicht mehr mit dem Code übereinstimmt.

Was sie erkennt

Die Erkennung ist begrenzt. Sie findet, was ein Terraform-Plan findet: eine Abweichung zwischen state und Code in den Baseline-Ressourcen des spoke canvas. Sie prüft nicht, was das Workload-Team zusätzlich zur Baseline im spoke deployt.

Herkunft dieser Seite

Die pipeline stammt aus dem spoke canvas früherer Versionen und ist eine Azure-DevOps-pipeline. Prüfe, ob deine Code-Version sie mitliefert, bevor du sie einrichtest. Die Datei- und Variablennamen unten sind die der Starter-Dateien und können in deiner Plattform abweichen.

Voraussetzungen: wohin die Berichte gehen

Die pipeline schreibt ihre Berichte in einen Storage Account. Wähle eine von zwei Optionen.

Option 1: der Storage Account eines spokes (bevorzugt)

Ein vollständig deployter spoke hat einen passenden Storage Account. Erstelle einen spoke für das Plattform-Team oder nimm einen bestehenden und setze eine Gruppe der Personen, die die Berichte brauchen, als ProductTeamGroupNames in seiner spoke-Datei (Spoke-JSON-Referenz). Dann, nach dem spoke-Deployment:

  1. Erstelle im Storage Account einen Container, zum Beispiel driftdetection.
  2. Gib der Gruppe Readers des Spokes die Rolle Storage Blob Data Reader auf dem Storage Account, damit sie die Dateien lesen kann. Wenn mehr Personen Zugriff brauchen, erstelle eine Gruppe für sie und gib dieser Gruppe die Rolle.
  3. Prüfe den Netzwerkzugriff des Storage Accounts. Er ist normalerweise auf seinen Private Endpoint beschränkt. Du musst ihn eventuell so anpassen, dass die Leser ihn erreichen können, wofür wiederum eine Policy-Ausnahme nötig sein kann.

Option 2: ein anderer Storage Account

Verwende einen normalen Storage Account (kein Data Lake, kein hierarchischer Namespace):

  1. Erstelle einen Container, zum Beispiel driftdetection.
  2. Stelle sicher, dass die Deployment-Agents den Storage Account erreichen, direkt oder, besser, über einen Private Endpoint.
  3. Gib dem Service Principal des spoke-Deployments darauf die Rolle Storage Blob Data Contributor.

Die pipeline erstellen

Die pipeline-Datei gehört zum Konfigurations-Repository der spokes (Starter-Name SpokeConfigurationDriftReporter.yaml im Ordner pipelines).

  1. Erstelle im Azure-DevOps-Projekt eine neue pipeline aus einer bestehenden YAML-Datei im Konfigurations-Repository, Branch main und dem Pfad dieser Datei. Speichere sie, ohne sie auszuführen.
  2. Benenne sie um, zum Beispiel Spoke Configuration-drift Detection.

  3. Setze den Agent-Pool in der Datei auf den Pool, den du verwendest:

    pool: <agent-pool>

  4. Erstelle die unten beschriebene Variable Library.

  5. Führe die pipeline einmal von Hand aus. Azure DevOps fragt nach der Erlaubnis, den Pool und die Library zu verwenden. Ein geplanter Lauf kann das nicht erfragen und schlägt deshalb fehl, bis der erste manuelle Lauf genehmigt ist.

Variable Library

Die pipeline liest den Storage Account und den Container aus einer Variable Group. Die Starter-pipeline erwartet den Namen xms-spoke-driftdetection.

Key Wert
DriftDetectionStorageAccountName Der exakte Name des Storage Accounts. Kleinbuchstaben, keine Leerzeichen am Anfang oder Ende.
DriftDetectionStorageContainerName Der Container. Vorschlag: driftdetection. Dieselben Regeln.

Zeitplan

Der Zeitplan steht in der pipeline-Datei:

schedules:
  - cron: "<minutes> <hours> <days> <months> <days-of-week>"
Feld Bereich
minutes 0 bis 59
hours 0 bis 23
days 1 bis 31
months 1 bis 12 (Namen werden auch akzeptiert)
days of week 0 bis 6, wobei 0 Sonntag ist (Namen werden auch akzeptiert)

* bedeutet jeder Wert. Azure DevOps wertet die Zeit in UTC aus. Führe sie mindestens wöchentlich aus, passend zum Wartungskalender.

Einen Bericht abrufen

Jeder Lauf speichert den Bericht zweimal im Container:

Verwendung Name
Historie: ein eindeutiger Name pro Lauf ConfigurationDriftReport_<yyyy-MM-dd HHmm>.json
Automatisierung: immer der neueste Bericht ConfigurationDriftReport_lastest.json (in der Quelle so geschrieben)

Um einen zu lesen, öffne den Storage Account im Azure-Portal, dann Storage browser, Blob containers und den Container driftdetection. Du brauchst die Rolle Storage Blob Data Reader. Automatisierung kann die Datei latest lesen.

Auf einen Bericht reagieren

Für jeden spoke im Bericht, der Änderungen zeigt:

  1. Finde heraus, wer was geändert hat (Azure Activity Log) und warum.
  2. Wenn die Änderung nötig ist, bring sie in den Code: eine spoke-Änderung.
  3. Wenn nicht, führe das spoke-Deployment aus, das sie zurücksetzt (Spoke-Deployment).
  4. Nimm die Anzahl der spokes mit drift in den monatlichen Health Check auf.