Infrastrukturänderungen sind zu riskant für blinde Bereitstellungen? Bicep validieren und testen

Eine Bicep-Datei kann erfolgreich kompiliert werden und trotzdem eine unbeabsichtigte Infrastrukturänderung enthalten. Eine einzelne geänderte Zeile könnte beispielsweise die Storage-Redundanz wechseln oder einen Container entfernen, bevor es jemand bemerkt.

CloudTrips benötigt eine wiederholbare Sicherheitsprüfung, die Coderegressionen lokal erkennt, die Vorlage mit Azure prüft und die Auswirkung auf Live-Ressourcen vor der Bereitstellung zeigt.

Dieser Trip baut auf folgendem Trip auf: Bereitstellungsbereiche verwenden. Schließe ihn zuerst ab, da die Prüfungen sowohl den dort erstellten Einstiegspunkt auf Ressourcengruppenebene als auch den auf Abonnementebene validieren.

Die drei Prüfungen verstehen

Jede Prüfung beantwortet eine andere Frage:

Prüfung	Beantwortete Frage
Snapshot	Hat sich das Bicep-Ergebnis gegenüber der genehmigten Codebasis geändert?
Preflight-Validierung	Akzeptiert Azure diese Vorlage, Konfiguration und Zugriffsrechte?
What-if	Wie würde die Bereitstellung die aktuellen Azure-Ressourcen verändern?

Snapshots sind lokal und deterministisch. Preflight und What-if kontaktieren Azure.

Snapshot-Befehl verfügbar machen

Snapshots benötigen Bicep CLI ab Version 0.41.2. Prüfe die installierte Version:

az bicep version

Die in diesem Projekt verwendete Azure-CLI-Installation speichert die Bicep-Programmdatei in $HOME/.azure/bin. Führe Snapshot-Befehle über diese Datei aus:

"$HOME/.azure/bin/bicep" --version

Ist die Datei nicht vorhanden, installiere sie:

az bicep install

Ist die angezeigte Version älter als 0.41.2, führe az bicep upgrade aus.

Genehmigte TEST-Basis erfassen

Erstelle im Verzeichnis cloudtrips-bicep einen Snapshot:

"$HOME/.azure/bin/bicep" snapshot environments/test.bicepparam \
  --mode overwrite \
  --subscription-id 00000000-0000-0000-0000-000000000000 \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --location westeurope \
  --deployment-name deploy-cloudtrips-storage-test

Dadurch entsteht environments/test.snapshot.json. Committe diese Datei, weil sie die genehmigte Testbasis und keine wegwerfbare Build-Ausgabe ist.

Die ausschließlich aus Nullen bestehende Abonnement-ID ist ein Platzhalter und kein Azure-Abonnement, das tatsächlich existieren muss. Der Befehl snapshot wertet den Bicep-Code nur lokal aus. Er stellt keine Ressourcen bereit, kontaktiert Azure nicht und authentifiziert sich nicht mit der angegebenen ID. Bicep benötigt trotzdem einen Wert im Format einer Abonnement-ID, um Ausdrücke mit Bereitstellungskontext zu berechnen. Beispielsweise enthält resourceGroup().id die Abonnement-ID, und der Speicherkontoname verwendet uniqueString() auf Grundlage dieser Ressourcengruppen-ID.

Durch denselben Platzhalter entstehen auf jedem Entwicklercomputer identische berechnete Werte. So führen unterschiedliche echte Abonnement-IDs nicht zu irrelevanten Snapshot-Änderungen. Ein aus der Null-ID berechneter Speicherkontoname ist deshalb für diese lokale Basis korrekt. Die späteren Azure-Validierungs- und what-if-Befehle verwenden das angemeldete TEST-Abonnement und zeigen die tatsächlichen Ressourcennamen.

Bearbeite die generierte JSON-Datei nicht manuell.

Unveränderten Code erfolgreich prüfen

Validiere das aktuelle Bicep-Ergebnis gegen den Snapshot:

"$HOME/.azure/bin/bicep" snapshot environments/test.bicepparam \
  --mode validate \
  --subscription-id 00000000-0000-0000-0000-000000000000 \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --location westeurope \
  --deployment-name deploy-cloudtrips-storage-test

Keine Ausgabe und Exitcode 0 bedeuten, dass das aktuelle Ergebnis mit der Basis übereinstimmt. Verwende beim Validieren immer exakt dieselben Kontextwerte.

Beweisen, dass der Test ein Risiko erkennt

Ändere vorübergehend diese Zeile in environments/test.bicepparam:

param storageSku = 'Standard_GRS'

Führe denselben Snapshot-Befehl mit --mode validate aus. Er sollte fehlschlagen und den Wechsel des Storage-SKU von Standard_LRS zu Standard_GRS anzeigen.

Stelle den genehmigten Wert wieder her:

param storageSku = 'Standard_LRS'

Führe die Snapshot-Validierung erneut aus. Sie sollte nun ohne Ausgabe erfolgreich sein. Verwende --mode overwrite nur, nachdem eine Änderung geprüft und ausdrücklich genehmigt wurde. Überschreibe die Basis niemals nur, um einen fehlgeschlagenen Test zu unterdrücken.

Azure-Preflight-Validierung ausführen

Wähle das echte TEST-Abonnement aus und lasse Azure die Bereitstellung prüfen:

az account set \
  --subscription "<Name oder ID des CloudTrips-TEST-Abonnements>"

az deployment group validate \
  --name validate-cloudtrips-storage-test \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --parameters environments/test.bicepparam \
  --validation-level Provider \
  --query "properties.provisioningState" \
  --output tsv

Provider prüft Vorlage, Ressourcenanbieter und Berechtigungen. Ein erfolgreiches Ergebnis lautet Succeeded, beweist aber noch nicht, dass die Live-Umgebung unverändert bleibt.

Mit der Live-Umgebung vergleichen

Schließe mit What-if ab:

az deployment group what-if \
  --resource-group rg-cloudtrips-bicep-test-weu \
  --parameters environments/test.bicepparam \
  --validation-level Provider

Prüfe jede vorgeschlagene Änderung. Die bekannten Standardwerte des Storage-Anbieters können weiterhin als Rauschen erscheinen. Es darf jedoch keine unerwartete Erstellung, Löschung, Ersetzung oder Änderung an SKU, Containern oder Tags geben.

CloudTrips besitzt nun drei getrennte Prüfungen: Der Snapshot erkennt unbeabsichtigte Codeänderungen, Preflight prüft die Annahme der Bereitstellung durch Azure und What-if vergleicht den genehmigten Code mit Live-Ressourcen. Ein späterer Automatisierungs-Trip kann dieselben Prüfungen für jeden Pull Request ausführen.