Übung: Erstellen kurzlebiger Umgebungen für Pull Requests
Einige Teammitglieder haben Ihnen mitgeteilt, dass sie das automatische Bicep-Linter-Feedback zu ihren Codeänderungen zu schätzen wissen, bevor sie diese an andere Teammitglieder zur Überprüfung weiterleiten. Jetzt haben Sie beschlossen, Ihren Mitwirkenden und Prüfern die Möglichkeit zu geben, ihren Code in einer kurzlebigen Umgebung bereitzustellen und zu prüfen.
In dieser Übung werden Sie Ihren Pull Request-Workflow aktualisieren, um eine kurzlebige Umgebung bereitzustellen, sobald ein Pull Request geöffnet wird, und sie erneut bereitzustellen, wenn Code in den Pull Request-Branch gepusht wird. Sie erstellen auch einen weiteren Workflow zum automatischen Löschen der Umgebung, wenn der Pull Request geschlossen wird. Sie testen Ihre Änderungen, indem Sie einen Pull Request für Ihre Website erstellen, um ein Docker-Containerimage zu verwenden.
In dem Prozess gehen Sie wie folgt vor:
- Aktualisieren Sie den Pull Request-Workflow, um eine kurzlebige Umgebung bereitzustellen.
- Erstellen Sie einen Workflow zum Löschen von Pull Requests, um die kurzlebige Umgebung zu löschen.
- Erstellen Sie einen Pull Request und beobachten Sie, wie die kurzlebige Umgebung erstellt wird.
- Genehmigen Sie den Pull Request, und beobachten Sie, wie die kurzlebige Umgebung gelöscht wird.
Aktualisieren des Pull Request-Workflows zum Bereitstellen einer kurzlebigen Umgebung
Zunächst müssen Sie Ihren pr-validation-Workflow aktualisieren, um eine kurzlebige Umgebung zu erstellen.
Schauen Sie sich im Visual Studio Code-Terminal den Mainbranch des Repositorys an.
git checkout main
Pullen Sie die neueste Version des Codes von GitHub, die die Änderungen enthält, die Sie in einer vorherigen Übung gemergt haben.
git pull
Öffnen Sie die Datei .github/workflows/pr-validation.yml in Visual Studio Code.
Fügen Sie am oberen Rand der Datei unter der Einstellung
name
eineconcurrency
-Einstellung hinzu:name: pr-validation concurrency: ${{ github.event.number }}
Diese Einstellung verhindert, dass mehrere Workflows für denselben Pull Request gleichzeitig ausgeführt werden, was zu unvorhersehbaren Ergebnissen bei der Bereitstellung von Ressourcen in Azure führen kann.
Definieren Sie am oberen Rand der Datei unter dem Abschnitt
on
, in dem der Trigger definiert wird, den Abschnittpermissions
:name: pr-validation concurrency: ${{ github.event.number }} on: pull_request permissions: id-token: write contents: read
Fügen Sie unterhalb des Abschnitts
permissions
zwei neue Umgebungsvariablen hinzu:name: pr-validation concurrency: ${{ github.event.number }} on: pull_request permissions: id-token: write contents: read env: resourceGroupName: pr_${{ github.event.number }} resourceGroupLocation: westus3
Die Umgebungsvariable
resourceGroupName
gibt den Namen der Ressourcengruppe an, die für jede kurzlebige Umgebung verwendet werden soll. Jede Ressourcengruppe erhält den Namenpr_123
, wobei123
die eindeutige Nummer des Pull Requests ist.Die Umgebungsvariable
resourceGroupLocation
gibt an, dass Ihre kurzlebigen Umgebungen alle in der Azure-Region „USA, Westen 3“ bereitgestellt werden sollen.Definieren Sie einen neuen Auftrag mit dem Namen
deploy
, unterhalb des Auftragslint
:jobs: lint: uses: ./.github/workflows/lint.yml deploy: runs-on: ubuntu-latest 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 }}
Der Auftrag checkt zunächst den gesamten Code auf den GitHub-Runner aus und meldet sich dann bei Ihrer Azure-Umgebung an.
Tipp
YAML-Dateien berücksichtigen Einzüge. Unabhängig davon, ob Sie diesen Code eingeben oder einfügen, stellen Sie sicher, dass der Einzug korrekt ist. Später in dieser Übung sehen Sie die vollständige YAML-Workflowdefinition, sodass Sie überprüfen können, ob Ihre Datei übereinstimmt.
Fügen Sie einen Schritt hinzu, um die Ressourcengruppe mit dem in der Umgebungsvariablen definierten Namen zu erstellen:
- uses: Azure/cli@v1 name: Create resource group with: inlineScript: | az group create \ --name ${{ env.resourceGroupName }} \ --location ${{ env.resourceGroupLocation }}
Fügen Sie nach dem Schritt zur Erstellung der Ressourcengruppe einen Schritt zur Bereitstellung der Bicep-Datei für die Ressourcengruppe hinzu:
- uses: azure/arm-deploy@v1 id: deploy name: Deploy Bicep file with: failOnStdErr: false deploymentName: ${{ github.run_number }} resourceGroupName: ${{ env.resourceGroupName }} template: ./deploy/main.bicep parameters: > environmentType=Test
Fügen Sie nach dem Schritt der Bereitstellung einen Schritt hinzu, um die Adresse der Website der kurzlebigen Umgebung im Workflowprotokoll anzuzeigen:
- name: Show website hostname run: | echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
Speichern Sie die Änderungen.
Überprüfen Sie, ob die Datei pr-validation.yml wie folgt aussieht:
name: pr-validation concurrency: ${{ github.event.number }} on: pull_request permissions: id-token: write contents: read env: resourceGroupName: pr_${{ github.event.number }} resourceGroupLocation: westus3 jobs: lint: uses: ./.github/workflows/lint.yml deploy: runs-on: ubuntu-latest 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/cli@v1 name: Create resource group with: inlineScript: | az group create \ --name ${{ env.resourceGroupName }} \ --location ${{ env.resourceGroupLocation }} - uses: azure/arm-deploy@v1 id: deploy name: Deploy Bicep file with: failOnStdErr: false deploymentName: ${{ github.run_number }} resourceGroupName: ${{ env.resourceGroupName }} template: ./deploy/main.bicep parameters: > environmentType=Test - name: Show website hostname run: | echo "Access the website at this address: https://${{ steps.deploy.outputs.appServiceAppHostName }}"
Falls nicht, aktualisieren Sie sie entsprechend diesem Beispiel und speichern sie.
Committen Sie Ihre Änderungen im Visual Studio Code-Terminal. Sie werden sie noch nicht in das Remoterepository pushen.
git add . git commit -m "Update pull request validation workflow to deploy an ephemeral environment"
Hinzufügen eines Workflows zum Löschen von Pull Requests
Sie haben einen Workflow erstellt, der die Änderungen in jedem Pull Request automatisch in einer kurzlebigen Ressourcengruppe bereitstellt. Jetzt konfigurieren Sie einen zweiten Workflow, um die kurzlebigen Umgebungen zu löschen, wenn sie nicht mehr benötigt werden.
Erstellen Sie eine neue Datei namens pr-closed.yml im Ordner .github/workflows.
Benennen Sie den Workflow am Anfang der Datei, konfigurieren Sie denselben Parallelitätsschlüssel, den Sie im Workflow zur Überprüfung von Pull Requests verwendet haben, konfigurieren Sie den Workflow so, dass er ausgeführt wird, sobald ein Pull Request geschlossen wird, und gestatten Sie dem Workflow das Abrufen eines Zugriffstokens:
name: pr-closed concurrency: ${{ github.event.number }} on: pull_request: types: [closed] permissions: id-token: write contents: read
Definieren Sie unterhalb des Codes, den Sie gerade eingegeben haben, eine Umgebungsvariable für den Namen der Ressourcengruppe, die der kurzlebigen Umgebung des Pull Requests zugeordnet ist:
env: resourceGroupName: pr_${{ github.event.number }}
Der Name der Ressourcengruppe ist derselbe wie der, den Sie für den Workflow zur Überprüfung des Pull Requests verwendet haben.
Definieren Sie unterhalb des hinzugefügten Codes einen neuen Auftrag mit dem Namen
remove
, und konfigurieren Sie ihn für die Anmeldung bei Azure:jobs: remove: runs-on: ubuntu-latest steps: - 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 }}
Definieren Sie innerhalb des Auftrags
remove
einen Schritt zum Löschen der Ressourcengruppe mithilfe der Azure CLI, und bestätigen Sie die Löschung mithilfe des Arguments--yes
:- uses: Azure/cli@v1 name: Delete resource group with: inlineScript: | az group delete \ --name ${{ env.resourceGroupName }} \ --yes
Speichern Sie die Änderungen.
Überprüfen Sie, ob die Datei pr-closed.yml wie folgt aussieht:
name: pr-closed concurrency: ${{ github.event.number }} on: pull_request: types: [closed] permissions: id-token: write contents: read env: resourceGroupName: pr_${{ github.event.number }} jobs: remove: runs-on: ubuntu-latest steps: - 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/cli@v1 name: Delete resource group with: inlineScript: | az group delete \ --name ${{ env.resourceGroupName }} \ --yes
Falls nicht, aktualisieren Sie sie entsprechend diesem Beispiel und speichern sie.
Committen Sie Ihre Änderungen im Visual Studio Code-Terminal, und pushen Sie sie in das Remoterepository:
git add . git commit -m 'Add pull request closed workflow' git push
Update der Bicep-Datei
Aktualisieren Sie nun Ihre Bicep-Datei, um ein Docker-Containerimage für die Anwendung Ihrer Website zu verwenden.
Führen Sie im Visual Studio Code-Terminal den folgenden Befehl aus, um einen neuen Branch für Ihre Änderungen zu erstellen:
git checkout -b feature/container-app
Öffnen Sie die Datei main.bicep im Ordner deploy.
Aktualisieren Sie den Wert der Variablen
appServiceAppLinuxFrameworkVersion
:var appServiceAppLinuxFrameworkVersion = 'DOCKER|dockersamples/static-site:latest'
Speichern Sie die Änderungen.
Committen und pushen Sie Ihre Änderungen in Ihr Git-Repository, indem Sie die folgenden Befehle im Visual Studio Code-Terminal ausführen:
git add . git commit -m "Use container image for website" git push origin feature/container-app
Erstellen eines Pull Request
Sie haben Workflows definiert, um kurzlebige Umgebungen in Pull Requests automatisch zu erstellen und zu verwalten. Nun erstellen Sie einen weiteren Pull Request für Ihre Bicep-Änderungen.
Wählen Sie in Ihrem Browser Code aus, und wählen Sie dann 3 Branches aus.
Wählen Sie unter Ihre Branches neben feature/container-app die Option Neuer Pull Request aus.
Klicken Sie auf Pull Request erstellen.
Beobachten Sie, wie die kurzlebige Umgebung erstellt wird.
Warten Sie auf der Detailseite des Pull Requests, bis die Statusünerprüfungselemente angezeigt werden.
Wählen Sie in der Liste neben dem Bereitstellungsauftrag die Option Details aus.
Warten Sie, bis die Bereitstellung abgeschlossen ist.
Wählen Sie Websitehostnamen anzeigen aus.
Wählen Sie die URL im Protokoll aus.
Die Website wird geladen und die Meldung Hello Docker! angezeigt, die besagt, dass die Website im in der Pull Request-Änderung angegebenen Containerimage ausgeführt wird.
Öffnen Sie optional das Azure-Portal, und navigieren Sie zur Ressourcengruppe der kurzlebigen Umgebung.
Überprüfen Sie die bereitgestellten Ressourcen: Speicherkonto, App Service-Instanz und App Service-Plan.
Zusammenführen des Pull Requests
Nachdem Sie den Pull Request getestet haben, können Sie ihn mit dem Branch Main zusammenführen.
Wählen Sie Pull Requests und dann den Pull Request Containerimage für Website verwenden aus.
Die Statusprüfungen wurden bestanden.
Wählen Sie Pull Request zusammenführen aus.
Wählen Sie Merge bestätigen aus.
Überprüfen des Löschens der Ressourcengruppe
Wählen Sie im Browser Aktionen aus, und wählen Sie dann im linken Bereich den pr-closed-Workflow aus.
Sie können erkennen, dass der Workflow automatisch aufgerufen wurde, da ein Pull Request geschlossen wurde.
Wählen Sie den Workflow zur Überprüfung des Protokolls aus.
Es kann ein paar Minuten dauern, bis der Workflow das Löschen der Ressourcengruppe in Azure beendet hat.
Wichtig
Sie müssen nicht warten, bis die Workflowausführung abgeschlossen ist. Denken Sie jedoch daran, später das Azure-Portal zu öffnen, um zu überprüfen, ob die Ressourcengruppe der kurzlebigen Umgebung erfolgreich gelöscht wurde und um zu vermeiden, dass Ihnen Kosten für die Azure-Ressourcen entstehen.
Bereinigen von Ressourcen
Sobald Sie mit dem Modul fertig sind, können Sie die von Ihnen erstellten Ressourcen löschen:
GitHub-Geheimnisse
- Wechseln Sie im GitHub-Repository zu Einstellungen>Geheimnisse und Variablen>Aktionen.
- Wählen Sie die Schaltfläche "Löschen " für jeden geheimen Repositoryschlüssel aus, und folgen Sie den Eingabeaufforderungen.
GitHub-Repository
- Wechseln Sie zu Einstellungen>Allgemein.
- Scrollen Sie zum unteren Rand des Bildschirms, wählen Sie "Dieses Repositorylöschen" aus, und folgen Sie den Anweisungen.
Verbundanmeldeinformationen und Dienstprinzipal der Azure-App-Registrierung.
- Suchen Sie auf der Startseite des Portals nach Microsoft Entra-ID, und wählen Sie sie aus der Liste der Dienste aus.
- Wechseln Sie zu Verwalten>App-Registrierungen.
- Wählen Sie unter Anwendungen mit Besitzerdie Option toy-website-auto-review aus.
- Wählen Sie Löschen aus, und befolgen Sie die Anweisungen.
- Wählen Sie Gelöschte Anwendungen aus, um die App-Registrierung endgültig zu löschen.
Wichtig
Doppelte App-Registrierungen und Dienstprinzipalnamen sind möglich. Es wird empfohlen, die ID der Anwendung zu überprüfen, um sicherzustellen, dass Sie die richtige Ressource löschen.