Bereitstellen von Bicep-Dateien mithilfe eines Workflows

  • 7 Minuten

Nachdem Sie nun einen einfachen Workflow erstellt haben, können Sie ihn für die Bereitstellung Ihrer Bicep-Dateien einrichten. In dieser Lerneinheit erfahren Sie, wie Sie Bicep-Code aus einem Workflow bereitstellen und wie Sie die Bereitstellungsschritte einrichten.

Hinweis

Die Befehle in dieser Lerneinheit dienen der Veranschaulichung der Konzepte. Führen Sie die Befehle jetzt noch nicht aus. Sie können das Erlernte in Kürze üben.

Auschecken Ihres Codes

Ihre Bicep-Dateien sind in Ihrem Git-Repository gespeichert. In GitHub Actions müssen Sie den Workflow explizit anweisen, die Dateien aus Ihrem Git-Repository auszuchecken. Andernfalls hat Ihr Workflow keinen Zugriff auf die Dateien. Dieser Schritt ist in der Regel der erste Schritt bei Ihrem Auftrag.

Für das Auschecken Ihres Codes können Sie die Aktion actions/checkout@v3 verwenden:

name: MyWorkflow

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo

Beachten Sie, dass der Workflow das Schlüsselwort uses enthält. Das Schlüsselwort zeigt an, dass Sie eine vordefinierte Aktion mit dem Namen actions/checkout verwenden möchten.

Wie bei Bicep-Ressourcen werden Aktionen immer versioniert. In diesem Fall verwendet der Workflow Version 3, daher wird @v3 an den Aktionsnamen angefügt.

Nachdem der Workflow diese Aktion umfasst, wird der Code Ihres Repositorys in das Dateisystem des Runners ausgecheckt. Sie geben den Pfad, in dem die Dateien gespeichert werden sollen, mithilfe des path-Parameters an.

Für Azure authentifizieren

Wenn Sie eine Bicep-Datei von Ihrem eigenen Computer aus bereitstellen, verwenden Sie die Azure CLI oder Azure PowerShell. Damit Sie Ihren Code bereitstellen können, müssen Sie sich bei Azure anmelden. In der Regel werden Sie von den Tools aufgefordert, Ihre Anmeldedaten in einen Browser einzugeben. Nachdem Ihre Anmeldeinformationen überprüft wurden, werden Ihre Berechtigungen zum Bereitstellen von Ressourcen bestätigt, und Sie können dann die Tools verwenden, um Ihre Bicep-Datei bereitzustellen.

Tipp

In diesem Modul erstellen Sie eine Workloadidentität für Ihren Workflow. Im Modul Authentifizieren Ihres Azure-Bereitstellungsworkflows mithilfe von Workloadidentitäten werden Workloadidentitäten, deren Funktionsweise, die Erstellung, das Zuweisen von Rollen und die Verwaltung ausführlicher erläutert.

Für die Bereitstellung mithilfe eines Workflows ist ebenfalls eine Authentifizierung erforderlich. Da Workflows ohne Eingriffe durch Personen ausgeführt werden, müssen sie mithilfe einer Workloadidentität bei Azure authentifiziert werden. GitHub und Microsoft Entra ID arbeiten zusammen, um Ihren Workflow sicher zu authentifizieren, ohne dass Anmeldeinformationen erforderlich sind.

Wenn Ihr Workflow mit Azure kommunizieren muss, meldet sich ein Workflowschritt mithilfe einer Workloadidentität bei Azure an. Anschließend verwenden die im Workflow definierten Schritte die Identität des Workflows.

Diagram that shows a workflow that includes an Azure deployment step, which accesses a secret and then deploys to Azure.

Sie müssen sicherstellen, dass Ihre Workloadidentität über die Berechtigungen verfügt, die zum Ausführen Ihrer Bereitstellungsschritte erforderlich sind. Beispielsweise müssen Sie der Workloadidentität möglicherweise die Rolle „Mitwirkender“ für die Ressourcengruppe zuweisen, in der Sie Ihre Ressourcen bereitstellen.

Warnung

Es mag einfacher erscheinen, Ihre Benutzeranmeldedaten in Ihrer YAML-Datei zu speichern und sich dann mit dem Befehl az login anzumelden. Diesen Ansatz sollten Sie jedoch niemals verwenden, um Ihren Workflow zu authentifizieren. Anmeldeinformationen in einer YAML-Datei werden in Klartext gespeichert. Jeder Benutzer, der Zugriff auf Ihr Repository hat, kann die Anmeldeinformationen anzeigen und verwenden. Selbst wenn Sie den Zugriff auf Ihr GitHub-Repository einschränken, befindet sich die YAML-Datei mit den Anmeldeinformationen immer auf dem Computer der Person, wenn diese Ihr Repository klont.

Anmelden bei Azure

Bevor Ihr Workflow Befehle für Ihre Azure-Umgebung ausführen kann, muss er sich zunächst anmelden. Es gibt eine Aktion namens azure/login, die den Anmeldevorgang durchführt. Außerdem müssen Sie Ihrem Workflow die Berechtigung erteilen, mit Authentifizierungstoken zu arbeiten.

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}

Für die Aktion azure/login müssen Sie zur Verwendung einer Workloadidentität drei Informationen bereitstellen: eine Microsoft Entra-Anwendungs-ID, Ihre Microsoft Entra-Mandanten-ID (Verzeichnis-ID) und die Azure-Abonnement-ID, mit der Sie arbeiten möchten.

Nachdem diese Aktion ausgeführt wurde, wird Ihr Runner authentifiziert und kann Anweisungen für Ihre Azure-Umgebung ausführen.

Bereitstellen Ihrer Bicep-Datei

Nachdem sich Ihr Workflow bei Azure angemeldet hat, kann er die Workloadidentität verwenden, um die Bicep-Bereitstellung auszuführen. In GitHub Actions verwenden Sie die azure/arm-deploy-Aktion, um eine Bicep-Bereitstellung zu initiieren.

Hinweis

Es gibt noch weitere Möglichkeiten, Bicep-Dateien über GitHub Actions bereitzustellen. Beispielsweise können Sie die azure/CLI-Aktion verwenden und dann Azure CLI-Befehle angeben, um Ihre Bereitstellungen auszuführen. Da der Task azure/arm-deploy jedoch speziell für die Bereitstellung konzipiert ist, werden Sie ihn in diesem Modul verwenden.

Hier sehen Sie ein Beispiel dafür, wie Sie einen Schritt für die Verwendung der azure/arm-deploy-Aktion konfigurieren können:

name: MyWorkflow

on: [workflow_dispatch]

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
      with:
        path: repo
    - uses: azure/login@v1
      with:
        client-id: ${{ secrets.AZURE_CLIENT_ID }}
        tenant-id: ${{ secrets.AZURE_TENANT_ID }}
        subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
    - uses: azure/arm-deploy@v1
      with:
        resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
        template: ./deploy/main.bicep
        parameters: environmentType=Test

Die azure/arm-deploy-Aktion akzeptiert mehrere Parameter, einschließlich:

  • resourceGroupName: Dies ist der Name der Ressourcengruppe, in der Sie die in der Bicep-Datei definierten Ressourcen bereitstellen möchten.
  • template: Dies ist der Pfad zur Bicep-Datei in Ihrem Repository. Der Pfad ist relativ zum Repositorystamm.
  • parameters: Gibt alle Parameterwerte an, die Sie zur Bereitstellungszeit angeben In diesem Beispiel geben Sie einen Wert für den environmentType-Parameter an.

Da der Workflow mit der vorherigen azure/login-Aktion bereits bei Azure angemeldet wurde, wird der Schritt azure/arm-deploy auf einem authentifizierten Runner ausgeführt.

Variablen

Häufig enthalten Ihre Workflows Werte, die Sie an mehreren Stellen in Ihrer Workflowdatei wiederverwenden möchten. Möglicherweise möchten Sie diese Werte auch oben in der Workflowdatei speichern, um sie einfacher referenzieren und ändern zu können. In Ihrem Workflow werden die von Ihnen definierten Variablen als Umgebungsvariablen verfügbar gemacht. Verwenden Sie Variablen, um wiederverwendbare Werte zu definieren.

Erstellen einer Variablen

Sie können Variablen auf verschiedenen Ebenen in Ihrer Workflowdatei erstellen. Wenn sie jedoch für die gesamte Workflowdatei verfügbar sein sollen, definieren Sie sie am Anfang der Datei direkt unterhalb Ihrer on-Anweisung. Verwenden Sie für das Definieren Ihrer Variablen den env-Parameter:

env:
    AZURE_RESOURCEGROUP_NAME: gh-actions
    AZURE_WEBAPP_NAME: webapp-gh-actions

In dem vorangegangenen Beispiel werden zwei Umgebungsvariablen angegeben.

Verwenden einer Variable in Ihrem Workflow

Nachdem Sie eine Variable erstellt haben, verwenden Sie eine spezielle Syntax, um in der YAML-Datei Ihres Workflows wie folgt darauf zu verweisen:

${{ env.AZURE_RESOURCEGROUP_NAME }}

Standardumgebungsvariablen

GitHub Actions verwendet auch Standardumgebungsvariablen. Standardumgebungsvariablen enthalten vordefinierte Informationen, die Sie möglicherweise in Ihrem Workflow verwenden möchten. Hier sind einige der Standardumgebungsvariablen aufgeführt, die Sie in Ihrem Workflow verwenden können:

  • github.sha: Bezeichner des Git-Commits, der die Ausführung des Workflows ausgelöst hat
  • github.run_number eindeutige Zahl für jede Ausführung eines bestimmten Workflows in einem Repository. Diese Zahl beginnt bei 1 für den ersten Lauf des Workflows und wird mit jedem neuen Lauf erhöht. Sie können diese Variable verwenden, um Ihre Azure-Bereitstellung zu benennen, damit Sie die Bereitstellung bis zu der spezifischen Workflowausführung zurückverfolgen können, die sie ausgelöst hat.

    Hinweis

    In GitHub Actions können Sie eine Workflowausführung erneut ausführen. Wenn Sie dies tun, ändert sich die Laufnummer nicht. Sie sollten also die Variable github.run_number nicht dazu verwenden, zu zählen, wie oft Ihr Workflow ausgeführt wurde.

Geheimnisse

Manchmal müssen Sie geheime Informationen für Ihren Workflow speichern, z. B. ein Datenbankkennwort oder einen API-Schlüssel. Sie verwenden GitHub-Geheimnisse, um Informationen sicher zu speichern, die Anmeldeinformationen oder vertrauliche Informationen enthalten. Ihr Workflow kann auf den Wert des Geheimnisses zugreifen.

Geheimnisse werden in den Einstellungen Ihres GitHub-Repositorys erstellt. Ein Geheimnis ist für alle Workflows im Repository verfügbar. In einem späteren Modul erfahren Sie mehr über Umgebungen, mit denen Sie die Verwendung von Geheimnissen auf Bereitstellungen in einer bestimmten Umgebung beschränken können.

Warnung

GitHub Actions verschleiert standardmäßig Variablenwerte mit Geheimnissen in Workflowprotokollen, trotzdem sollten Sie darüber hinaus bewährte Methoden befolgen. Ihre Workflowschritte haben Zugriff auf die Werte von Geheimnissen. Wenn Ihr Workflow einen Schritt enthält, der ein Geheimnis nicht sicher verarbeitet, besteht die Möglichkeit, dass der Geheimniswert in den Workflowprotokollen angezeigt wird. Sie sollten sämtliche Änderungen an einer Workflowdefinitionsdatei immer sorgfältig überprüfen, um sicherzustellen, dass die Geheimnisse richtig behandelt werden.

Sie können Geheimnisse über die GitHub-Weboberfläche erstellen. Mit der folgenden Syntax können Sie auf einen Geheimniswert in Ihrem Workflow verweisen:

${{ secrets.NAME_OF_THE_SECRET }}

Wenn Ihr Workflow gestartet wird, erhält der Runner, der die Bereitstellungsschritte ausführt, Zugriff auf den entschlüsselten Geheimniswert in GitHub. GitHub Actions ist so konzipiert, dass keine geheimen Werte in Ihren Workflowprotokollen offengelegt werden.

Tipp

Genau wie bei Bicep-Parametern müssen Sie nicht für alles Variablen erstellen. Es empfiehlt sich, Variablen für alles zu erstellen, was sich zwischen Umgebungen ändern kann, und GitHub-Geheimnisse für alle geheimen Informationen. Da der Workflow immer dieselbe Bicep-Datei verwendet, müssen Sie keine Variable für den Pfad erstellen.

In diesem Modul werden Sie GitHub-Geheimnisse verwenden, um die Informationen zu speichern, die die Task azure/login benötigt, um sich bei Azure anzumelden: Ihre Microsoft Entra-Abonnement- und Mandant-ID sowie die Anwendungsregistrierungs-ID der Workload-Identität.