Share via

Konfigurieren einer Pipeline und Pushupdates

  • Artikel

In diesem Artikel erfahren Sie, wie Sie die Azure Developer CLI (azd) verwenden, um Vorlagenänderungen über eine CI/CD-Pipeline wie GitHub-Aktionen oder Azure DevOps zu übertragen. In diesem Beispiel verwenden Sie die React Web App mit Node.js API und MongoDB auf Azure-Vorlage , aber Sie können die in diesem Artikel beschriebenen Prinzipien auf eine der Azure Developer CLI-Vorlagen anwenden.

Hinweis

Der azd pipeline config Befehl befindet sich noch in der Betaversion. Weitere Informationen zur Unterstützung von Alpha- und Betafeatures finden Sie auf der Seite "Featureversionsverwaltung" und "Releasestrategie ".

Voraussetzungen

azd Vorlagen können eine standardmäßige GitHub-Aktionen- und/oder Azure DevOps-Pipelinekonfigurationsdatei enthalten, die zum azure-dev.ymlEinrichten von CI/CD erforderlich ist. Diese Konfigurationsdatei stellt Ihre Azure-Ressourcen bereit und stellt Ihren Code im Standard Branch bereit. Sie finden azure-dev.yml:

  • Für GitHub-Aktionen: im .github/workflow Verzeichnis.
  • Für Azure DevOps: im .azdo/pipelines Verzeichnis.

Sie können die Konfigurationsdatei entsprechend Ihren Anforderungen verwenden oder ändern.

Hinweis

Stellen Sie sicher, dass Ihre Vorlage vor dem Aufrufen azd pipeline configüber eine Pipelinedefinition (azure-dev.yaml) verfügt. azd diese Datei wird nicht automatisch erstellt. Siehe "Erstellen einer Pipelinedefinition für azd " weiter unten.

Um eine CI/CD-Pipeline zu konfigurieren, verwenden Sie den azd pipeline config Befehl, der die folgenden Aufgaben behandelt:

  • Erstellen und Konfigurieren eines Dienstprinzipals für die App im Azure-Abonnement. Ihr Benutzer muss entweder Owner über Rollen oder Contributor + User Access Administrator Rollen innerhalb des Azure-Abonnements verfügen, da azd das Erstellen und Zuweisen von Rollen zum Dienstprinzipal zulassen kann.
  • Führt Sie durch einen Workflow, um ein GitHub- oder Azure DevOps-Repository zu erstellen und zu konfigurieren und ihren Projektcode darauf zu übernehmen. Sie können auch ein vorhandenes Repository verwenden.
  • Erstellt eine sichere Verbindung zwischen Azure und Ihrem Repository.
  • Führt die GitHub-Aktion aus, wenn Sie die Workflowdatei einchecken.

Für eine genauere Kontrolle über diesen Prozess oder wenn Der Benutzer nicht über die erforderlichen Rollen verfügt, können Sie eine Pipeline manuell konfigurieren.

Wählen Sie Ihren bevorzugten Pipelineanbieter aus, um den Vorgang fortzusetzen:

Autorisieren von GitHub für die Bereitstellung in Azure

Um den Workflow zu konfigurieren, müssen Sie einen Dienstprinzipal für die Bereitstellung in Azure in Ihrem Auftrag aus einer GitHub-Aktion autorisieren. azd erstellt den Dienstprinzipal und eine Verbundanmeldeinformationen dafür.

  1. Führen Sie den folgenden Befehl aus, um den Azure-Dienstprinzipal zu erstellen und die Pipeline zu konfigurieren:

    azd pipeline config

    Mit diesem Befehl wird optional ein GitHub-Repository erstellt und Code an das neue Repository übertragen.

    Hinweis

    Verwendet standardmäßig azd pipeline config OpenID-Verbinden (OIDC), die als Verbundanmeldeinformationen bezeichnet werden. Wenn Sie OIDC nicht verwenden möchten, führen Sie azd pipeline config --auth-type client-credentials aus.

    OIDC/Verbundanmeldeinformationen werden für Terraform nicht unterstützt.

    Erfahren Sie mehr über die Unterstützung von OIDC in azd.

  2. Geben Sie die angeforderten GitHub-Informationen an.

  3. Geben Sie an y, wenn Sie aufgefordert werden, die lokalen Änderungen zu übernehmen und zu pushen, um eine neue Ausführung von GitHub-Aktionen zu starten.

  4. Zeigen Sie im Terminalfenster die Ergebnisse des azd pipeline config Befehls an. Der azd pipeline config Befehl gibt den GitHub-Repositorynamen für Ihr Projekt aus.

  5. Öffnen Sie mit Ihrem Browser das GitHub-Repository für Ihr Projekt.

  6. Wählen Sie "Aktionen" aus, um den ausgeführten Workflow anzuzeigen.

    Screenshot des ausgeführten GitHub-Workflows.

Vornehmen und Pushen einer Codeänderung

  1. Öffnen header.tsxSie im Verzeichnis des /src/web/src/layout Projekts .

  2. Suchen Sie die Zeile <Text variant="xLarge">ToDo</Text>.

  3. Ändern Sie das Literal ToDo in myTodo.

  4. Speichern Sie die Datei .

  5. Committen Sie die Änderung. Beim Commit der Änderung wird die GitHub Action-Pipeline gestartet, um das Update bereitzustellen.

    Screenshot der Schritte, die erforderlich sind, um Änderungen an der Testdatei vorzunehmen und zu übernehmen.

  6. Öffnen Sie mit Ihrem Browser das GitHub-Repository Ihres Projekts, um beides anzuzeigen:

    • Ihr Commit
    • Der Commit von GitHub-Aktionen, die eingerichtet werden.

    Screenshot Ihrer zugesicherten Änderung in GitHub.

  7. Wählen Sie "Aktionen" aus, um die im Workflow wiedergegebene Testaktualisierung anzuzeigen.

    Screenshot des GitHub-Workflows, der nach dem Testupdate ausgeführt wird.

  8. Besuchen Sie die Web-Frontend-URL, um das Update zu prüfen.

azd als GitHub-Aktion

Als GitHub-Aktion hinzufügenazd. Diese Aktion wird installiert azd. Um sie zu verwenden, können Sie Folgendes hinzufügen:.github\workflows\azure-dev.yml

on: [push]

jobs:
   build:
      runs-on: ubuntu-latest
      steps:
         - name: Install azd
         uses: Azure/setup-azd@v0.1.0

Bereinigen von Ressourcen

Wenn Sie die in diesem Artikel erstellten Azure-Ressourcen nicht mehr benötigen, führen Sie den folgenden Befehl aus:

azd down

Erweiterte Features

Sie können den azd pipeline config Befehl für bestimmte Vorlagenszenarien oder Anforderungen erweitern, wie in den folgenden Abschnitten beschrieben.

Weitere geheime Schlüssel oder Variablen

Legt standardmäßig azd Variablen und geheime Schlüssel für die Pipeline fest. Beispielsweise erstellt der azd pipeline config Befehl die subscription idUnd environment name die region als Pipelinevariablen, wenn sie ausgeführt wird. Die Pipelinedefinition verweist dann auf diese Variablen:

env:
   AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
   AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
   AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
   AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
   AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}

Wenn die Pipeline ausgeführt wird, azd werden die Werte aus der Umgebung abgerufen, die den Variablen und geheimen Schlüsseln zugeordnet sind. Je nach Vorlage gibt es möglicherweise Einstellungen, die Sie mithilfe von Umgebungsvariablen steuern können. Beispielsweise könnte eine Umgebungsvariable namens KEY_VAULT_NAME festgelegt werden, um den Namen einer Key Vault-Ressource innerhalb der Vorlageninfrastruktur zu definieren. In solchen Fällen kann die Liste der Variablen und geheimen Schlüssel mithilfe der azure.yamlVorlage definiert werden. Betrachten Sie beispielsweise die folgende azure.yaml Konfiguration:

pipeline:
  variables:
    - KEY_VAULT_NAME
    - STORAGE_NAME
  secrets:
    - CONNECTION_STRING

Bei dieser Konfiguration wird überprüft, azd ob eine der Variablen oder geheimen Schlüssel einen nicht leeren Wert in der Umgebung aufweist. azd anschließend wird entweder eine Variable oder ein geheimer Schlüssel für die Pipeline erstellt, wobei der Name des Schlüssels in der Konfiguration als Name der Variablen oder des geheimen Schlüssels und der Wert, der nicht aus der Umgebung für den Wert stammt, verwendet wird.

Die azure-dev.yaml Pipelinedefinition kann dann auf die Variablen oder geheimen Schlüssel verweisen:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      KEY_VAULT_NAME: ${{ variables.KEY_VAULT_NAME }}
      STORAGE_NAME: ${{ variables.STORAGE_NAME }}
      CONNECTION_STRING: ${{ secrets.CONNECTION_STRING }}

Hinweis

Sie müssen nach dem Aktualisieren der Liste der geheimen Schlüssel oder Variablen azure.yaml ausgeführt werdenazd pipeline config, damit azd die Pipelinewerte zurücksetzen kann.

Infrastrukturparameter

Betrachten Sie das folgende Bicep-Beispiel:

@secure()
param BlobStorageConnection string

Der Parameter BlobStorageConnection hat keinen Standardwert festgelegt, daher azd wird der Benutzer aufgefordert, einen Wert einzugeben. Während CI/CD gibt es jedoch keine interaktive Eingabeaufforderung. azd muss den Wert für den Parameter anfordern, wenn Sie ausgeführt azd pipeline configwerden, speichern Sie den Wert in der Pipeline, und rufen Sie den Wert dann erneut ab, wenn die Pipeline ausgeführt wird.

azd verwendet einen Pipelineschlüssel, der aufgerufen wird AZD_INITIAL_ENVIRONMENT_CONFIG , um den Wert aller erforderlichen Parameter in der Pipeline automatisch zu speichern und festzulegen. Sie müssen nur auf diesen geheimen Schlüssel in Ihrer Pipeline verweisen:

- name: Provision Infrastructure
   run: azd provision --no-prompt
   env:
      AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}

Wenn die Pipeline ausgeführt wird, azd werden die Werte für die Parameter aus dem geheimen Schlüssel verwendet, wodurch die Notwendigkeit einer interaktiven Eingabeaufforderung entfernt wird.

Hinweis

Sie müssen erneut ausgeführt azd pipeline config werden, wenn Sie einen neuen Parameter hinzufügen.

Erstellen einer Pipelinedefinition

Wenn Ihre azd Vorlage noch nicht über eine CI/CD-Pipelinedefinitionsdatei verfügt, können Sie eine datei selbst erstellen. Eine CI/CD-Pipelinedefinition weist in der Regel vier Standard Abschnitte auf:

  • Trigger (trigger)
  • konfigurieren
  • Betriebssystem oder Pool
  • Auszuführende Schritte

Die folgenden Beispiele veranschaulichen, wie Sie eine Definitionsdatei und zugehörige Konfigurationen für GitHub-Aktionen und Azure-Pipelines erstellen.

Für die Ausführung azd in GitHub-Aktionen sind die folgenden Konfigurationen erforderlich:

  • Gewähren id-token: write und contents: read Zugreifen auf Bereiche.
  • Installieren Sie die azd-Aktion, es sei denn, Sie verwenden ein Docker-Image, auf dem azd bereits installiert ist.

Sie können die folgende Vorlage als Ausgangspunkt für Ihre eigene Pipelinedefinition verwenden:

on:
  workflow_dispatch:
  push:
    # Run when commits are pushed to mainline branch (main or master)
    # Set this to the mainline branch you are using
    branches:
      - main
      - master

# Set this permission if you are using a Federated Credential.
permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    # azd build-in variables.
    # This variables are always set by `azd pipeline config`
    # You can set them as global env (apply to all steps) or you can add them to individual steps' environment
    env:
      AZURE_CLIENT_ID: ${{ vars.AZURE_CLIENT_ID }}
      AZURE_TENANT_ID: ${{ vars.AZURE_TENANT_ID }}
      AZURE_SUBSCRIPTION_ID: ${{ vars.AZURE_SUBSCRIPTION_ID }}
      AZURE_ENV_NAME: ${{ vars.AZURE_ENV_NAME }}
      AZURE_LOCATION: ${{ vars.AZURE_LOCATION }}
      ## Define the additional variables or secrets that are required globally (provision and deploy)
      # ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
      # ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}      
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      # using the install-azd action
      - name: Install azd
        uses: Azure/setup-azd@v1.0.0

      # # If you want to use azd-daily build, or install it from a PR, you can remove previous step and
      # # use the next one:
      # - name: Install azd - daily or from PR
      #  # Update this scrip based on the OS - pool of your pipeline. This example is for a linux pipeline installing daily build
      #  run: curl -fsSL https://aka.ms/install-azd.sh | bash -s -- --version daily
      #  shell: pwsh

      # azd set up Federated Credential by default. You can remove this step if you are using Client Credentials
      - name: Log in with Azure (Federated Credentials)
        if: ${{ env.AZURE_CLIENT_ID != '' }}
        run: |
          azd auth login `
            --client-id "$Env:AZURE_CLIENT_ID" `
            --federated-credential-provider "github" `
            --tenant-id "$Env:AZURE_TENANT_ID"
        shell: pwsh

      ## If you set up your pipeline with Client Credentials, remove previous step and uncomment this one
      # - name: Log in with Azure (Client Credentials)
      #   if: ${{ env.AZURE_CREDENTIALS != '' }}
      #   run: |
      #     $info = $Env:AZURE_CREDENTIALS | ConvertFrom-Json -AsHashtable;
      #     Write-Host "::add-mask::$($info.clientSecret)"

      #     azd auth login `
      #       --client-id "$($info.clientId)" `
      #       --client-secret "$($info.clientSecret)" `
      #       --tenant-id "$($info.tenantId)"
      #   shell: pwsh
      #   env:
      #     AZURE_CREDENTIALS: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Provision Infrastructure
        run: azd provision --no-prompt
        env:
         #  # uncomment this if you are using infrastructure parameters
         #  AZD_INITIAL_ENVIRONMENT_CONFIG: ${{ secrets.AZD_INITIAL_ENVIRONMENT_CONFIG }}
         ## Define the additional variables or secrets that are required only for provision 
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}

      - name: Deploy Application
        run: azd deploy --no-prompt
        env:
         ## Define the additional variables or secrets that are required only for deploy
         #  ADDITIONAL_VARIABLE_PLACEHOLDER: ${{ variables.ADDITIONAL_VARIABLE_PLACEHOLDER }}
         #  ADDITIONAL_SECRET_PLACEHOLDER: ${{ secrets.ADDITIONAL_SECRET_PLACEHOLDER }}