Grundlegendes zu End-to-End-Bereitstellungen

Abgeschlossen

GitHub Actions-Workflows sind flexible Tools, die Sie auf vielfältige Weise konfigurieren können, damit sie Ihre Anforderungen erfüllen. In dieser Lerneinheit erfahren Sie, wie Sie Workflows verwenden, um eine gesamte Lösung bereitzustellen, einschließlich der Konfiguration der Azure-Infrastruktur, und um andere Bereitstellungsvorgänge durchzuführen.

Wie viele Workflows?

In einigen Organisationen unterscheidet sich das Team, das die Azure-Umgebung verwaltet, von dem Team, das den Code entwickelt, der in der Umgebung ausgeführt wird. In diesen Situationen ist es oft verlockend, mehrere Workflows zu erstellen, die sich jeweils im Besitz des Teams befinden, das für den jeweiligen Bereich verantwortlich ist. Beispielsweise können Sie einen Workflow zum Bereitstellen des Bicep-Codes erstellen, der die Azure-Ressourcen Ihrer Website bereitstellt, und einen anderen Workflow, der die Websiteanwendung bereitstellt.

Obwohl dieser Ansatz Ihnen ein gewisses Maß an Flexibilität bei der Verwaltung der Workflows bietet, kann es schwierig sein, alle Elemente synchron zu halten. Angenommen, Ihr Websiteteam benötigt eine neue Einstellung für seine Azure App Service-App, um ein neu entwickeltes Feature zu aktivieren. Der Workflow für die Anwendungsbereitstellung kann erst ausgeführt werden, wenn der Workflow für die Infrastrukturbereitstellung erfolgreich abgeschlossen wurde. Außerdem kann es kompliziert werden, die von Ihrem Infrastrukturworkflow erstellten Daten (z. B. die Namen von Azure-Ressourcen) zwischen den Workflows zu senden.

Stattdessen ist es häufig besser, einen einzelnen Workflow zu erstellen, die alle erforderlichen Komponenten für Ihre Lösung bereitstellt, auch wenn die Komponenten von verschiedenen Personen oder Teams verwaltet werden. Sie können Tools wie Git und GitHub verwenden, um Ihre Arbeit zu koordinieren. Wenn ein neues Feature hinzugefügt wird, können Sie einen Branch verwenden, um die erforderlichen Änderungen an Ihrer Bicep-Datei vorzunehmen. Wenn die Änderung integriert und freigegeben werden kann, führt ein einzelner Workflow alle erforderlichen Schritte aus, um die Lösung zu erstellen und bereitzustellen. Dies verringert die Wahrscheinlichkeit von Synchronisierungsfehlern.

Tipp

Wenn Sie Code für Ihre Lösung erstellen, müssen Sie ihn wahrscheinlich häufig bereitstellen, damit Sie die Funktionsweise testen können. Möglicherweise stellen Sie fest, dass die Bereitstellung Ihrer Infrastruktur zusammen mit Ihrem Anwendungscode dazu führt, dass Ihr Workflow langsam ausgeführt wird und Ihren Fortschritt hemmt.

Wenn Sie sich in dieser Lage befinden, können Sie erwägen, die Infrastrukturbereitstellung für Ihre Entwicklungsumgebung zu deaktivieren. Hierzu können Sie Pfadfilter, wiederverwendbare Workflows und Bedingungen verwenden. Sie sollten jedoch die vollständige Bereitstellungssequenz für Ihre anderen Umgebungen intakt lassen.

Steuerungsebene und Datenebene

Viele Azure-Ressourcen bieten zwei verschiedene Ebenen für den Zugriff. Auf der Steuerungsebene wird die Ressource bereitgestellt und konfiguriert. Auf der Datenebene können Sie auf die Funktionen der Ressource zugreifen.

Wenn Sie Bicep-Dateien erstellen und bereitstellen, interagieren Sie mit der Steuerungsebene. In Azure ist Azure Resource Manager die Steuerungsebene. Sie verwenden Resource Manager, um die Konfiguration der einzelnen Ressourcen zu definieren.

Ihr Workflow muss jedoch häufig mehr Aktionen ausführen, als nur mit der Steuerungsebene zu interagieren. Beispielsweise müssen Sie eventuell:

• Hochladen eines Blobs in ein Speicherkonto.
• Ändern eines Datenbankschemas.
• Aufrufen einer API für einen Drittanbieterdienst.
• Auslösen einer Aktualisierung des Machine Learning-Modells.
• Bereitstellen einer Website für eine Azure App Service-App.
• Bereitstellen von Software auf einer VM.
• Registrieren eines DNS-Eintrags bei einem Drittanbieter.

Wenn Sie einen ganzheitlichen Workflow in Betracht ziehen, müssen Sie normalerweise Ihre Azure-Ressourcen bereitstellen und dann eine Reihe von Vorgängen für die Datenebenen dieser Ressourcen ausführen. Gelegentlich werden diese Vorgänge als letzte Meile der Bereitstellung bezeichnet, da Sie den Großteil der Bereitstellung mithilfe der Steuerungsebene durchführen und nur wenige Konfigurationsschritte verbleiben.

Hinweis

Einige Ressourcen weisen keine klare Trennung zwischen ihrer Steuerungsebene und der Datenebene auf. Dazu gehören Azure Data Factory und Azure API Management. Beide Dienste unterstützen vollständig automatisierte Bereitstellungen mithilfe von Bicep, erfordern jedoch besondere Überlegungen. Links zu weiteren Informationen finden Sie auf der Seite „Zusammenfassung“ am Ende des Moduls.

Ausführen von Datenebenenvorgängen

Wenn Sie einen Bereitstellungsworkflow erstellen, der mit der Datenebene Ihrer Ressourcen interagiert, können Sie einen der drei folgenden gängigen Ansätze verwenden:

• Resource Manager-Bereitstellungsskripts
• Workflowskripts
• Workflowaktionen

Resource Manager-Bereitstellungsskripts werden in Ihrer Bicep-Datei definiert. Sie führen Bash- oder PowerShell-Skripts aus und können mit Azure CLI-Befehlen und Azure PowerShell-Cmdlets interagieren. Sie erstellen eine verwaltete Identität für das Bereitstellungsskript zur Authentifizierung bei Azure, und Azure stellt automatisch die anderen Ressourcen bereit, die zum Ausführen des Bereitstellungsskripts benötigt werden, und verwaltet sie.

Bereitstellungsskripts sind gut, wenn Sie ein einfaches Skript innerhalb Ihres Bereitstellungsprozesses ausführen müssen, aber sie bieten Ihnen keinen einfachen Zugriff auf andere Elemente aus Ihrem Workflow.

Sie können auch Ihre eigene Logik innerhalb eines Bereitstellungsworkflows ausführen. GitHub Actions bietet ein umfangreiches Ökosystem von Aktionen für gängige Schritte, die Sie ausführen müssen. Wenn Sie keine Aktion finden, die Ihren Anforderungen entspricht, können Sie über ein Skript Ihren eigenen Bash- oder PowerShell-Code ausführen. Workflowaktionen und Skripts werden vom Runner Ihres Workflows ausgeführt. Häufig müssen Sie die Aktion oder das Skript auf der Datenebene des von Ihnen verwendeten Diensts authentifizieren. Wie Sie dabei vorgehen, hängt vom Dienst ab.

Workflowaktionen und Skripts bieten Ihnen Flexibilität und Kontrolle. Sie ermöglichen Ihnen außerdem den Zugriff auf Workflowartefakte, die Sie in Kürze kennenlernen werden. In diesem Modul konzentrieren wir uns auf Workflowaktionen. Links zu weiteren Informationen über Resource Manager-Bereitstellungsskripts finden Sie auf der Seite „Zusammenfassung“ am Ende des Moduls.

Ausgaben

Ein Workflow erstellt und konfiguriert normalerweise Ihre Azure-Ressourcen, indem eine Bicep-Datei bereitgestellt wird. Die nachfolgenden Teile des Workflows interagieren dann mit der Datenebene dieser Ressourcen. Um mit den Ressourcen interagieren zu können, benötigen die Workflowaktionen und -schritte Informationen über die erstellte Azure-Ressource.

Angenommen, Sie verfügen über eine Bicep-Datei, die ein Speicherkonto bereitstellt. Sie möchten, dass Ihr Workflow das Speicherkonto bereitstellt und dann einige Blobs in einen Blobcontainer im Speicherkonto hochlädt. Der Workflowschritt zum Hochladen der Blobs muss den Namen des Speicherkontos kennen, mit dem eine Verbindung hergestellt werden soll, sowie den Namen des Blobcontainers, in den die Datei hochgeladen werden soll.

Es ist eine bewährte Methode, dass die Bicep-Datei über die Namen Ihrer Azure-Ressourcen entscheidet. Sie kann Parameter, Variablen oder Ausdrücke verwenden, um die Namen für das Speicherkonto und den Blobcontainer zu erstellen. Die Bicep-Datei kann dann eine Ausgabe verfügbar machen, die den Namen der einzelnen Ressourcen bereitstellt. Spätere Schritte im Workflow können den Wert der Ausgabe lesen. Auf diese Weise muss Ihre Workflowdefinition keine Namen oder andere Informationen hartcodieren, die sich zwischen Umgebungen ändern können oder auf Regeln basieren, die in Ihrer Bicep-Datei definiert sind.

Mit GitHub Actions können Sie die Werte von Ausgaben mithilfe von Workflowvariablen weitergeben. Die Aktion azure/arm-deploy erstellt automatisch Variablen für jede Ausgabe Ihrer Bicep-Bereitstellung. Sie können Workflowvariablen auch manuell in Skripts erstellen. Links zu weiteren Informationen finden Sie auf der Seite „Zusammenfassung“ am Ende dieses Moduls.

Wenn Sie auf Variablen zugreifen, die in einem anderen Auftrag erstellt wurden, müssen Sie die Variable veröffentlichen, damit sie für den Auftrag zugänglich ist, der sie liest. Angenommen, Sie erstellen einen Auftrag, der eine Bicep-Datei bereitgestellt, und Sie müssen die appServiceAppName-Ausgabe an Ihren Workflow übergeben. Mit dem Schlüsselwort outputs geben Sie an, dass die Workflowvariable appServiceAppName auf den Wert der im Schritt deploy erstellten Ausgabevariable appServiceAppName festgelegt werden soll:

job1:
  runs-on: ubuntu-latest
  outputs:
    appServiceAppName: ${{ steps.deploy.outputs.appServiceAppName }}
  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 Bicep file
    with:
      failOnStdErr: false
      deploymentName: ${{ github.run_number }}
      resourceGroupName: Playground1
      template: ./deploy/main.bicep

In einem späteren Auftrag erstellen Sie dann eine explizite Abhängigkeit von dem Auftrag, der die Variable erstellt hat, indem Sie das Schlüsselwort needs einfügen. Außerdem verweisen Sie auf die Variable, indem Sie den Namen der veröffentlichten Variable verwenden:

job2:
  needs: job1
  runs-on: ubuntu-latest
  steps:
  - run: |
      echo "${{needs.job1.outputs.appServiceAppName}}"

Mithilfe von Bicep-Ausgaben und Workflowvariablen können Sie einen Workflow erstellen, der Ihren Bicep-Code bereitstellt und dann im Rahmen Ihrer Bereitstellung mehrere Aktionen für die Ressourcen ausführt.