Testen Ihrer Ressourcen nach der Bereitstellung

  • 6 Minuten

Aufgrund der Überprüfungen und Vorschauansicht Ihrer Bicep-Bereitstellung können Sie mit recht hoher Sicherheit davon ausgehen, dass die Bereitstellung Ihrer Bicep-Dateien erfolgreich verlaufen wird. Doch nach der Bereitstellung ist Ihre Arbeit noch nicht erledigt. Sie sollten überprüfen, ob die Bereitstellung wie erwartet verlaufen ist.

In dieser Lerneinheit erfahren Sie mehr über Tests, die Sie nach Abschluss der Bereitstellung durchführen können. Außerdem lernen Sie, wie Sie einen Rollback für Ihre Bereitstellung ausführen, wenn das Bereitstellungsergebnis nicht Ihren Erwartungen entspricht.

Ausführen von Feuerproben und Negativtests

Wenn Sie Ressourcen in einer Bicep-Datei definieren, geht es nicht nur darum, Ressourcen in Azure zu erstellen. Sie möchten Ihrer Organisation auch einen Mehrwert bieten und gleichzeitig die Anforderungen erfüllen. Wenn Sie Ihre Bicep-Dateien überprüfen und eine Vorschau anzeigen, steigt Ihre Gewissheit, dass die Ressourcendefinitionen gültig sind. Sie wissen jedoch nicht unbedingt, ob die Ressourcen die gewünschten Aktionen ausführen.

Stellen Sie sich beispielsweise vor, Sie stellen einen neuen logischen Azure SQL-Server mithilfe einer Bicep-Bereitstellungspipeline bereit. Ihre Bicep-Definition für den Server ist gültig, sodass sie die Linter- und Preflightüberprüfungsphasen besteht. Der Was-wäre-wenn-Befehl zeigt, dass ein Server erstellt wird, was auch Ihren Erwartungen entspricht. Die Bereitstellung wird ebenfalls erfolgreich abgeschlossen. Am Ende des Bereitstellungsprozesses ist es dennoch möglich, dass der Datenbankserver nicht funktioniert bzw. einsatzbereit ist. Das kann unter anderem diese Gründe haben:

  • Sie haben keine Firewallregeln konfiguriert, die Netzwerkdatenverkehr an Ihren Server zulassen.
  • Sie haben die Microsoft Entra-Authentifizierung auf Ihrem Server aktiviert, obwohl Sie es nicht sollten oder umgekehrt.

Selbst wenn Sie nur einfache Bicep-Dateien bereitstellen, sollten Sie überlegen, wie Sie überprüfen können, ob die von Ihnen bereitgestellten Ressourcen tatsächlich funktionieren und Ihre Anforderungen erfüllen. So können Sie dieses Prinzip zum Beispiel so umsetzen:

  • Wenn Sie eine Website bereitstellen, versuchen Sie, die Webanwendung über Ihre Pipeline zu erreichen. Vergewissern Sie sich, dass Ihre Pipeline erfolgreich eine Verbindung mit der Website herstellt und einen gültigen Antwortcode empfängt.
  • Versuchen Sie bei der Bereitstellung eines CDN (Content Delivery Network), eine Verbindung mit einer Ressource über dieses herzustellen. Stellen Sie sicher, dass die Pipeline erfolgreich eine Verbindung mit dem CDN herstellt und einen gültigen Antwortcode empfängt.

Diese Tests werden manchmal als Feuerproben für die Infrastruktur bezeichnet. Die Feuerprobe ist ein einfacher Test, der entwickelt wurde, um größere Probleme in Ihrer Bereitstellung aufzudecken.

Hinweis

Einige Azure-Ressourcen sind über einen von Microsoft gehosteten Pipeline-Agent nicht einfach zu erreichen. Möglicherweise sollten Sie die Verwendung eines selbstgehosteten Agents für die Ausführung von Feuerprobenphasen in Betracht ziehen, wenn diese den Zugriff auf Ressourcen über private Netzwerke erfordern.

Es ist auch eine gute Idee, Negativtests durchzuführen. Durch Negativtests können Sie sicherstellen, dass Ihre Ressourcen kein unerwünschtes Profil aufweisen. Wenn Sie beispielsweise einen virtuellen Computer bereitstellen, ist es eine bewährte Methode, Azure Bastion zu verwenden, um eine sichere Verbindung mit dem virtuellen Computer herzustellen. Sie können Ihrer Pipeline einen Negativtest hinzufügen, um sich davon zu überzeugen, dass Sie mithilfe von Remotedesktopverbindung oder SSH keine direkte Verbindung mit einem virtuellen Computer herstellen können.

Wichtig

Das Ziel dieser Tests besteht nicht darin, zu überprüfen, ob Bicep Ihre Ressourcen ordnungsgemäß bereitgestellt hat. Wenn Sie Bicep verwenden, gehen Sie davon aus, dass die Ressourcen bereitgestellt werden, die Sie in Ihren Bicep-Dateien angeben. Stattdessen soll überprüft werden, ob die von Ihnen definierten Ressourcen für Ihre Situation geeignet sind und Ihre Anforderungen erfüllen.

Ausführen von Tests aus Azure Pipelines

Es gibt viele Möglichkeiten, Tests in Ihrer Pipeline auszuführen. In diesem Modul wird das Open-Source-Tool Pester verwendet, das Tests ausführt, die mit PowerShell geschrieben wurden. Sie können ein anderes Testframework verwenden oder sogar Ihre Tests ohne ein Testtool ausführen. Ein weiteres interessantes Testtool ist beispielsweise PSRule für Azure, das eine Reihe vordefinierter Regeln und Tests für Azure enthält. Es kann die Validierung für Ihre Vorlagen und auch Tests für Ihre bereitgestellten Azure-Ressourcen ausführen. In der Zusammenfassung wird auf PSRule verwiesen.

Wenn Sie ein unterstütztes Testframework verwenden, versteht Azure Pipelines die Ergebnisse der einzelnen Tests. Es zeigt die Testergebnisse zusammen mit der Pipelineausführung an und verfolgt den Verlauf jedes einzelnen Tests im Zeitverlauf. In der nächsten Übung erfahren Sie, wie Sie Azure Pipelines mit Feuerproben für die Infrastruktur verwenden können.

Übergeben von Daten zwischen Schritten und Phasen

Wenn Sie Ihre Pipeline in mehrere Phasen unterteilen, die jeweils ihren eigenen Verantwortungsbereich haben, müssen Sie manchmal Daten zwischen diesen Phasen übergeben. Eine Phase kann beispielsweise eine Azure-Ressource erstellen, mit der eine andere Phase arbeiten muss. Um Daten übergeben zu können, muss die zweite Phase den Namen der erstellten Ressource kennen. Beispielsweise muss unsere Feuerprobenphase auf die Ressourcen zugreifen, die in der Bereitstellungsphase bereitgestellt wurden.

Ihre Bicep-Datei stellt die Ressourcen so bereit, dass sie auf die Ressourceneigenschaften zugreifen und sie als Bereitstellungsausgaben veröffentlichen kann. Sie können auf eine Bereitstellungsausgabe in Ihrer Pipeline zugreifen. In Azure Pipelines gibt es eine spezielle Syntax für die Veröffentlichung von Variablen, um diese phasenübergreifend verfügbar zu machen.

Zunächst müssen Sie eine Ausgabevariable für eine Pipelinephase veröffentlichen. Zur Ausgabe der Variablen schreiben Sie eine speziell formatierte Zeichenfolge in das Pipelineprotokoll, die Azure Pipelines versteht. Im folgenden Beispiel wird eine Variable mit dem Namen myVariable auf den Wert myValue festgelegt:

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines liest und interpretiert die Zeichenfolge aus dem Pipelineprotokoll und macht den Wert der Variablen als Ausgabe verfügbar. Sie können diesen Wert mit weiteren Skripts kombinieren, um den Wert einer Bicep-Bereitstellungsausgabe als Ausgabevariable für eine Pipelinephase zu veröffentlichen. Auf die Skripterstellung wird in der nächsten Übung eingegangen.

Zweitens müssen Sie die Variable dann für den Auftrag Ihrer Feuerprobenphase verfügbar machen. Sie definieren eine Variable für den Auftrag und verwenden eine andere speziell formatierte YAML-Zeichenfolge:

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

Nun können alle Schritte innerhalb des Feuerprobenauftrags auf den Wert myVariable und auf jede andere Variable zugreifen, indem sie die Syntax $(myVariable) verwenden. Sie verwenden diese Variable in der nächsten Übung.

Andere Testtypen

Funktionstests und Integrationstests werden häufig verwendet, um zu überprüfen, ob sich die bereitgestellten Ressourcen wie erwartet verhalten. Beispielsweise kann ein Integrationstest eine Verbindung mit Ihrer Website herstellen, eine Testtransaktion übermitteln und dann warten, ob die Transaktion erfolgreich abgeschlossen wurde und den Erfolg bestätigen. Mithilfe von Integrationstests können Sie die Lösung testen, die Ihr Team erstellt, sowie die Infrastruktur, in der sie ausgeführt wird. In einem zukünftigen Modul erfahren Sie, wie diese Arten von Tests ihrer Pipeline hinzugefügt werden können.

Es ist auch möglich, andere Arten von Tests aus einer Bereitstellungspipeline auszuführen, einschließlich Leistungstests und Sicherheitspenetrationstests. Diese Tests sind nicht Gegenstand des Moduls, können aber einen Mehrwert für einen automatisierten Bereitstellungsprozess schaffen.

Rollback und Rollforward

Angenommen, Ihre Pipeline stellt Ihre Ressourcen erfolgreich bereit, aber Ihre Tests schlagen fehl. Wie sollten Sie dann vorgehen?

Weiter oben in diesem Modul haben Sie gelernt, dass Sie mit Azure Pipelines Rollbackphasen erstellen können, die ausgeführt werden, wenn eine vorherige Phase fehlschlägt. Sie können diesen Ansatz verwenden, um eine Rollbackphase zu erstellen, wenn die Testphase ein unerwartetes Ergebnis meldet. Sie können Ihre Änderungen auch manuell zurücksetzen oder die gesamte Pipeline erneut ausführen, wenn Sie der Meinung sind, dass der Fehler auf ein temporäres Problem zurückzuführen ist, das nun behoben wurde.

Hinweis

Wenn Sie eine Bereitstellung an Azure Resource Manager übermitteln, können Sie festlegen, dass Resource Manager die letzte erfolgreiche Bereitstellung automatisch erneut ausführt, wenn sie fehlschlägt. Dazu müssen Sie den Azure CLI-Schritt zum Bereitstellen Ihrer Datei ausführen und den Parameter --rollback-on-error hinzufügen, wenn Sie die Bereitstellung mithilfe des Befehls az deployment group create übermitteln.

Es ist oft schwierig, die Schritte zu erarbeiten, die eine Rollbackphase ausführen sollte. Im Allgemeinen sind Bicep-Bereitstellungen komplex, und es ist schwierig, Änderungen zurückzusetzen. Ein Rollback ist besonders schwierig, wenn Ihre Bereitstellung andere Komponenten enthält.

Stellen Sie sich beispielsweise vor, dass Ihre Pipeline eine Bicep-Datei bereitstellt, die eine Azure SQL-Datenbank definiert und der Datenbank dann einige Daten hinzufügt. Sollen die Daten gelöscht werden, wenn für Ihre Bereitstellung ein Rollback ausgeführt wird? Soll auch die Datenbank entfernt werden? Es ist nicht leicht, die Auswirkungen von Fehlern und Rollbacks auf Ihre ausgeführte Umgebung vorherzusagen.

Aus diesem Grund bevorzugen viele Organisationen die Ausführung von Rollforward, was bedeutet, dass sie schnell die Ursache des Fehlers beheben und dann erneut bereitstellen. Indem Sie einen qualitativ hochwertigen automatisierten Bereitstellungsprozess erstellen und alle bewährten Methoden befolgen, die Sie in diesen Lernpfaden kennengelernt haben, können Sie Probleme schnell beheben und Ihre Bicep-Dateien erneut bereitstellen und gleichzeitig eine hohe Qualität gewährleisten.

Tipp

Eines der Prinzipien einer DevOps-Mentalität besteht darin, aus Fehlern zu lernen. Wenn Sie einen Rollback für eine Bereitstellung ausführen müssen, überlegen Sie sorgfältig, warum der Fehler aufgetreten ist, und fügen Sie automatisierte Tests hinzu, bevor Sie mit der Bereitstellung beginnen, um das gleiche Problem zu erkennen, wenn es zukünftig erneut auftritt.