Testen Ihrer Ressourcen nach der Bereitstellung

6 Minuten

Aufgrund der Überprüfung 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 ein 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 ihre Anforderungen erfüllen. Wenn Sie Ihre Bicep-Dateien überprüfen und als Vorschau anzeigen, können Sie sicherstellen, dass die Ressourcendefinitionen gültig sind. Sie wissen jedoch nicht unbedingt, ob die Ressourcen auch wie gewünscht funktionieren.

Stellen Sie sich beispielsweise vor, Sie stellen einen neuen logischen Azure SQL-Server mithilfe eines Bicep-Bereitstellungsworkflows bereit. Ihre Bicep-Definition für den Server ist gültig, sodass sie die Aufträge für Linting und Preflightvalidierung 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 z. B. umsetzen:

Wenn Sie eine Website bereitstellen, versuchen Sie, die Webanwendung über Ihren Workflow zu erreichen. Vergewissern Sie sich, dass Ihr Workflow erfolgreich eine Verbindung mit der Website herstellt und einen gültigen Antwortcode empfängt.
Versuchen Sie bei der Bereitstellung eines CDN (Content Delivery Network), über dieses eine Verbindung mit einer Ressource herzustellen. Vergewissern Sie sich, dass der Workflow 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 nicht einfach von in GitHub gehosteten Runnern aus erreichbar. Möglicherweise sollten Sie die Verwendung eines selbst gehosteten Runners für die Ausführung von Feuerprobenaufträgen 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 Ihrem Workflow einen Negativtest hinzufügen, um sich davon zu überzeugen, dass Sie mithilfe von Remotedesktopverbindung oder SSH keine direkte Verbindung mit einer VM 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 GitHub-Workflows

Es gibt viele Möglichkeiten, Tests in Ihrem Workflow auszuführen. In diesem Modul wird das Open-Source-Tool Pester verwendet, das Tests ausführt, die mit PowerShell geschrieben wurden. Pester ist auf in GitHub gehosteten Runnern vorinstalliert. Sie müssen keine besonderen Vorkehrungen treffen, um sie in einem Skriptschritt zu verwenden.

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. Wir verweisen in der Zusammenfassung noch einmal auf PSRule.

Wenn Sie Tests aus einem Workflow heraus ausführen, sollten alle Testfehler die Fortsetzung des Workflows unterbrechen. In der nächsten Übung erfahren Sie, wie Sie Workflows mit Feuerproben für die Infrastruktur verwenden können.

Die Testergebnisse werden in das Workflowprotokoll geschrieben. Der GitHub Marketplace enthält auch Aktionen, die nicht von Microsoft stammen, mit denen Testergebnisse angezeigt und über einen Zeitraum nachverfolgt werden können.

Übergeben von Daten zwischen Aufträgen

Wenn Sie Ihren Workflow in mehrere Aufträge unterteilen, die jeweils ihren eigenen Verantwortungsbereich haben, müssen Sie manchmal Daten zwischen diesen Aufträgen übergeben. Ein Auftrag kann beispielsweise eine Azure-Ressource erstellen, mit der ein anderer Auftrag arbeiten muss. Um Daten übergeben zu können, muss der zweite Auftrag den Namen der erstellten Ressource kennen. Beispielsweise muss unser Feuerprobenauftrag auf die Ressourcen zugreifen, die im Bereitstellungsauftrag bereitgestellt wurden.

Ihre Bicep-Datei stellt die Ressourcen so bereit, dass sie auf die Ressourceneigenschaften zugreifen und sie als Bereitstellungsausgaben veröffentlichen kann. Wenn Sie Ihre Bicep-Bereitstellung über die Aktion arm-deploy ausführen, werden diese Ausgaben der Bicep-Bereitstellung in ihren Schrittausgaben gespeichert. Als Nächstes kann der Auftrag, der die Aktion arm-deploy enthält, diese Schrittausgaben als Auftragsausgaben veröffentlichen. Der Auftrag verweist auf die Eigenschaft des Schritts id, die wir auf deploy festlegen:

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - uses: azure/login@v1
    name: Sign in to Azure
    with:
      client-id: ${{ secrets.AZURE_CLIENT_ID }}
      tenant-id: ${{ secrets.AZURE_TENANT_ID }}
      subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
  - uses: azure/arm-deploy@v1
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

Sie können auf die Ausgabe eines Auftrags in jedem nachfolgenden Auftrag zugreifen, solange dieser von dem Auftrag abhängt, der die Ausgabe erzeugt:

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

Sie können die Ausgaben eines Workflowskripts auch mithilfe einer speziellen Syntax übergeben. Links zu weiteren Informationen finden Sie in der Zusammenfassung.

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 Ihrem Workflow hinzugefügt werden können.

Es ist auch möglich, andere Arten von Tests aus einem Bereitstellungsworkflow 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, Ihr Workflow stellt Ihre Ressourcen erfolgreich bereit, aber Ihre Tests verursachen Fehler. Wie sollten Sie dann vorgehen?

Weiter oben in diesem Modul haben Sie gelernt, dass Sie mit GitHub Actions Rollbackaufträge erstellen können, die ausgeführt werden, wenn ein vorheriger Auftrag zu Fehlern führt. Sie können diesen Ansatz verwenden, um einen Rollbackauftrag zu erstellen, wenn der Testauftrag ein unerwartetes Ergebnis meldet. Sie können Ihre Änderungen auch manuell zurücksetzen oder den gesamten Workflow erneut ausführen, wenn Sie der Meinung sind, dass der Fehler auf ein temporäres Problem zurückzuführen ist, das bereits 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 zu einem Fehler führt. Verwenden Sie hierzu den Parameter --rollback-on-error, wenn Sie die Bereitstellung mit dem Befehl az deployment group create der Azure-Befehlszeilenschnittstelle übermitteln.

Beispielsweise können Sie Ihrem Workflow einen Rollbackauftrag hinzufügen. Der Rollbackauftrag wird ausgeführt, wenn der Feuerprobenauftrag Fehler verursacht:

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

Der Auftrag hängt vom Feuerprobenauftrag ab. Er wird nur ausgeführt, wenn die Feuerprobe Fehler verursacht. Standardmäßig beendet GitHub Actions den Workflow immer dann, wenn ein vorheriger Auftrag Fehler verursacht. Die if-Bedingung enthält eine always()-Überprüfung, um dieses Verhalten zu überschreiben. Ohne always() im Ausdruck wird der Rollbackauftrag übersprungen, wenn ein vorheriger Auftrag Fehler verursacht.

Es ist oft schwierig, die Schritte zu erarbeiten, die ein Rollbackauftrag 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 Ihr Workflow eine Bicep-Datei bereitstellt, die eine Azure SQL-Datenbank definiert, und dann der Datenbank 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 Best Practices 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