Verwenden von Azure Spring Apps-CI/CD mit GitHub Actions
Hinweis
Azure Spring Apps ist der neue Name für den Azure Spring Cloud-Dienst. Obwohl der Dienst umbenannt wurde, wird der alte Name noch an einigen Stellen verwendet, solange wir Ressourcen wie Screenshots, Videos und Diagramme aktualisieren.
Dieser Artikel gilt für: ✔️ Basic/Standard ✔️ Enterprise
In diesem Artikel erfahren Sie, wie Sie einen CI/CD-Workflow für Azure Spring Apps mit GitHub Actions erstellen.
GitHub Actions unterstützt einen automatisierten Workflow für den Softwareentwicklungslebenszyklus. Mit GitHub Actions für Azure Spring Apps können Sie in Ihrem Repository Workflows zum Erstellen, Testen, Verpacken, Veröffentlichen und Bereitstellen in Azure erstellen.
Voraussetzungen
Für dieses Beispiel wird die Azure-Befehlszeilenschnittstelle benötigt.
Einrichten des GitHub-Repositorys und Durchführen der Authentifizierung
Zum Autorisieren der Azure-Anmeldeaktion sind Anmeldeinformationen für einen Azure-Dienstprinzipal erforderlich. Führen Sie auf Ihrem lokalen Computer die folgenden Befehle aus, um Azure-Anmeldeinformationen zu erhalten:
az login
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID> \
--json-auth
Wenn Sie auf eine bestimmte Ressourcengruppe zugreifen möchten, können Sie den Bereich einschränken:
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
--json-auth
Der Befehl sollte ein JSON-Objekt ausgeben:
{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
...
}
In diesem Beispiel wird das Steeltoe-Beispiel auf GitHub verwendet. Forken Sie das Repository, öffnen Sie die GitHub-Repositoryseite für den Fork, und wählen Sie die Registerkarte Settings (Einstellungen) aus. Öffnen Sie das Menü Secrets (Geheimnisse), und wählen Sie New secret (Neues Geheimnis) aus:
Legen Sie den Namen des Geheimnisses auf AZURE_CREDENTIALS und den Wert auf die JSON-Zeichenfolge fest, die Sie unter Einrichten des GitHub-Repositorys und Durchführen der Authentifizierung gefunden haben.
Die Azure-Anmeldeinformationen können auch aus Key Vault in GitHub Actions abgerufen werden, wie unter Authentifizieren von Azure Spring Cloud mit Schlüsseltresor in GitHub Actions beschrieben.
Bereitstellen der Dienstinstanz
Führen Sie zum Bereitstellen Ihrer Azure Spring Apps-Dienstinstanz die folgenden Befehle über die Azure-Befehlszeilenschnittstelle aus.
az extension add --name spring
az group create \
--name <resource-group-name> \
--location eastus
az spring create \
--resource-group <resource-group-name> \
--name <service-instance-name>
az spring config-server git set \
--name <service-instance-name> \
--uri https://github.com/Azure-Samples/azure-spring-apps-samples \
--label main \
--search-paths steeltoe-sample/config
Erstellen des Workflows
Der Workflow wird mithilfe folgender Optionen definiert.
Vorbereiten der Bereitstellung mit der Azure-Befehlszeilenschnittstelle
Der Befehl az spring app create ist aktuell nicht idempotent. Nachdem Sie sie einmal ausgeführt haben, wird eine Fehlermeldung angezeigt, wenn Sie denselben Befehl erneut ausführen. Dieser Workflow wird für vorhandene Azure Spring Apps-Apps und -Instanzen empfohlen.
Führen Sie zur Vorbereitung die folgenden Azure CLI-Befehle aus:
az config set defaults.group=<service-group-name>
az config set defaults.spring=<service-instance-name>
az spring app create --name planet-weather-provider
az spring app create --name solar-system-weather
Direktes Bereitstellen über die Azure-Befehlszeilenschnittstelle
Erstellen Sie die Datei .github/workflows/main.yml im Repository mit folgendem Inhalt. Ersetzen Sie <Ihren Ressourcengruppennamen> und <Ihren Dienstnamen> durch die richtigen Werte.
name: Steeltoe-CD
# Controls when the action runs. Triggers the workflow on push or pull request
# events but only for the main branch
on:
push:
branches: [ main]
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job runs on
runs-on: ubuntu-latest
env:
working-directory: ./steeltoe-sample
resource-group-name: <your resource group name>
service-name: <your service name>
# Supported .NET Core version matrix.
strategy:
matrix:
dotnet: [ '3.1.x' ]
# Steps represent a sequence of tasks that is executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
# Set up .NET Core 3.1 SDK
- uses: actions/setup-dotnet@v1
with:
dotnet-version: ${{ matrix.dotnet }}
# Set credential for az login
- uses: azure/login@v1.1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: install Azure CLI extension
run: |
az extension add --name spring --yes
- name: Build and package planet-weather-provider app
working-directory: ${{env.working-directory}}/src/planet-weather-provider
run: |
dotnet publish
az spring app deploy -n planet-weather-provider --runtime-version NetCore_31 --main-entry Microsoft.Azure.SpringCloud.Sample.PlanetWeatherProvider.dll --artifact-path ./publish-deploy-planet.zip -s ${{ env.service-name }} -g ${{ env.resource-group-name }}
- name: Build solar-system-weather app
working-directory: ${{env.working-directory}}/src/solar-system-weather
run: |
dotnet publish
az spring app deploy -n solar-system-weather --runtime-version NetCore_31 --main-entry Microsoft.Azure.SpringCloud.Sample.SolarSystemWeather.dll --artifact-path ./publish-deploy-solar.zip -s ${{ env.service-name }} -g ${{ env.resource-group-name }}
Einrichten des GitHub-Repositorys und Durchführen der Authentifizierung
Zum Autorisieren der Azure-Anmeldeaktion sind Anmeldeinformationen für einen Azure-Dienstprinzipal erforderlich. Führen Sie auf Ihrem lokalen Computer die folgenden Befehle aus, um Azure-Anmeldeinformationen zu erhalten:
az login
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID> \
--json-auth
Wenn Sie auf eine bestimmte Ressourcengruppe zugreifen möchten, können Sie den Bereich einschränken:
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
--json-auth
Der Befehl sollte ein JSON-Objekt ausgeben:
{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
...
}
In diesem Beispiel wird das PiggyMetrics-Beispiel auf GitHub verwendet. Deaktivieren Sie das Beispiel, deaktivieren Sie "Nur Azure Branch kopieren", öffnen Sie die GitHub-Repositoryseite, und wählen Sie die Registerkarte "Einstellungen" aus. Öffnen Sie das Menü "Geheime Schlüssel", und wählen Sie "Neuen geheimen Schlüssel hinzufügen" aus:
Legen Sie den Namen des Geheimnisses auf AZURE_CREDENTIALS und den Wert auf die JSON-Zeichenfolge fest, die Sie unter Einrichten des GitHub-Repositorys und Durchführen der Authentifizierung gefunden haben.
Die Azure-Anmeldeinformationen können auch aus Key Vault in GitHub Actions abgerufen werden, wie unter Authentifizieren von Azure Spring Cloud mit Schlüsseltresor in GitHub Actions beschrieben.
Bereitstellen der Dienstinstanz
Führen Sie zum Bereitstellen Ihrer Azure Spring Apps-Dienstinstanz die folgenden Befehle über die Azure-Befehlszeilenschnittstelle aus.
az extension add --name spring
az group create --location eastus --name <resource group name>
az spring create -n <service instance name> -g <resource group name>
az spring config-server git set -n <service instance name> --uri https://github.com/xxx/piggymetrics --label config
Durchgängige Beispiels-Arbeitsabläufe
Die folgenden Beispiele veranschaulichen gängige Verwendungsszenarien.
Wird bereitgestellt
Die folgenden Abschnitte zeigen Ihnen verschiedene Optionen zur Bereitstellung Ihrer App.
In einer Produktionsumgebung
Azure Spring Apps unterstützt die Bereitstellung in Bereitstellungen mit integrierten Artefakten (z. B. JAR oder .NET Core ZIP) oder Quellcodearchiv.
Das folgende Beispiel wird mithilfe der von Maven erstellten JAR-Datei in der Standardproduktionsbereitstellung in Azure Spring Apps bereitgestellt. Dieses Beispiel ist das einzige mögliche Bereitstellungsszenario bei Verwendung der Standard-SKU:
Hinweis
Das Paketsuchmuster sollte nur genau ein Paket zurückgeben. Wenn die Buildaufgabe mehrere JAR-Pakete wie sources.jar und javadoc.jar erzeugt, müssen Sie das Suchmuster verfeinern, damit es nur mit dem binären Artefakte der Anwendung übereinstimmt.
name: AzureSpringApps
on: push
env:
ASC_PACKAGE_PATH: ${{ github.workspace }}
AZURE_SUBSCRIPTION: <azure subscription name>
jobs:
deploy_to_production:
runs-on: ubuntu-latest
name: deploy to production with artifact
steps:
- name: Checkout GitHub Action
uses: actions/checkout@v2
- name: Set up Java 11
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '11'
- name: maven build, clean
run: |
mvn clean package
- name: Login via Azure CLI
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: deploy to production with artifact
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: Deploy
service-name: <service instance name>
app-name: <app name>
use-staging-deployment: false
package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar
Das folgende Beispiel wird mithilfe des Quellcodes in der Standardproduktionsbereitstellung in Azure Spring Apps bereitgestellt.
name: AzureSpringApps
on: push
env:
ASC_PACKAGE_PATH: ${{ github.workspace }}
AZURE_SUBSCRIPTION: <azure subscription name>
jobs:
deploy_to_production:
runs-on: ubuntu-latest
name: deploy to production with source code
steps:
- name: Checkout GitHub Action
uses: actions/checkout@v2
- name: Login via Azure CLI
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: deploy to production step with source code
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: deploy
service-name: <service instance name>
app-name: <app name>
use-staging-deployment: false
package: ${{ env.ASC_PACKAGE_PATH }}
Im folgenden Beispiel wird die Standardmäßige Produktionsbereitstellung in Azure Spring Apps mithilfe von Quellcode im Enterprise-Plan bereitgestellt. Mit der builder Option können Sie angeben, welcher Generator für die Bereitstellung von Aktionen verwendet werden soll.
name: AzureSpringApps
on: push
env:
ASC_PACKAGE_PATH: ${{ github.workspace }}
AZURE_SUBSCRIPTION: <azure subscription name>
jobs:
deploy_to_production:
runs-on: ubuntu-latest
name: deploy to production with source code
steps:
- name: Checkout GitHub Action
uses: actions/checkout@v2
- name: Login via Azure CLI
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: deploy to production step with source code in the Enterprise plan
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: deploy
service-name: <service instance name>
app-name: <app name>
use-staging-deployment: false
package: ${{ env.ASC_PACKAGE_PATH }}
builder: <builder>
Das folgende Beispiel wird einem vorhandenen Containerimage in der Standardproduktionsbereitstellung in Azure Spring Apps bereitgestellt.
name: AzureSpringApps
on: push
env:
ASC_PACKAGE_PATH: ${{ github.workspace }}
AZURE_SUBSCRIPTION: <azure subscription name>
jobs:
deploy_to_production:
runs-on: ubuntu-latest
name: deploy to production with source code
steps:
- name: Checkout GitHub Action
uses: actions/checkout@v2
- name: Login via Azure CLI
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
- name: Deploy Custom Image
uses: Azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: deploy
service-name: <service instance name>
app-name: <app name>
deployment-name: <deployment name>
container-registry: <your container image registry>
registry-username: ${{ env.REGISTRY_USERNAME }}
registry-password: ${{ secrets.REGISTRY_PASSWORD }}
container-image: <your image tag>
Während der Bereitstellung können Sie mehr Funktionalität erreichen, indem Sie weitere Argumente verwenden. Weitere Informationen finden Sie im Abschnitt "Argumente " von GitHub Action für die Bereitstellung in Azure Spring Apps.
Blau-grün
Die folgenden Beispiele werden in einer vorhandenen Zurückspeicherungs-Bereitstellung ausgerollt. Diese Bereitstellung empfängt erst dann Produktionsdatenverkehr, wenn sie als Produktionsbereitstellung festgelegt ist. Sie können Verwende-Zurückspeicherungs-Bereitstellung true setzen, um die Zurückspeicherungs-Bereitstellung automatisch zu finden, oder einfach einen bestimmten Verteilungsnamen zuweisen. Wir konzentrieren uns nur auf die spring-apps-deploy Aktion und lassen die vorbereitenden Arbeitsplätze im restlichen Artikel aus.
# environment preparation configurations omitted
steps:
- name: blue green deploy step use-staging-deployment
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: deploy
service-name: <service instance name>
app-name: <app name>
use-staging-deployment: true
package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar
# environment preparation configurations omitted
steps:
- name: blue green deploy step with deployment-name
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: deploy
service-name: <service instance name>
app-name: <app name>
deployment-name: staging
package: ${{ env.ASC_PACKAGE_PATH }}/**/*.jar
Weitere Informationen zu Blau-Grün-Bereitstellungen, einschließlich eines alternativen Ansatzes, finden Sie unter Blau-Grün-Bereitstellungsstrategien.
Produktionsbereitstellung festlegen
Im folgenden Beispiel wird die aktuelle Stagingbereitstellung als Produktionsbereitstellung festgelegt und effektiv ausgetauscht, welche Bereitstellung Produktionsdatenverkehr empfängt.
# environment preparation configurations omitted
steps:
- name: set production deployment step
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: set-production
service-name: <service instance name>
app-name: <app name>
use-staging-deployment: true
Zurückspeicherungs-Bereitstellung löschen
Mit der Delete Staging Deployment Aktion können Sie die Bereitstellung löschen, die keinen Produktionsdatenverkehr empfängt. Diese Löschung gibt Ressourcen frei, die von dieser Bereitstellung verwendet werden, und macht Platz für eine neue Stagingbereitstellung:
# environment preparation configurations omitted
steps:
- name: Delete staging deployment step
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: delete-staging-deployment
service-name: <service instance name>
app-name: <app name>
Erstellen oder Aktualisieren des Builds (nur Enterprise-Plan)
Im folgenden Beispiel wird eine Buildressource im Enterprise-Plan erstellt oder aktualisiert:
# environment preparation configurations omitted
steps:
- name: Create or update build
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: build
service-name: <service instance name>
build-name: <build name>
package: ${{ env.ASC_PACKAGE_PATH }}
builder: <builder>
Build löschen (nur Enterprise-Plan)
Im folgenden Beispiel wird eine Buildressource im Enterprise-Plan gelöscht:
# environment preparation configurations omitted
steps:
- name: Delete build
uses: azure/spring-apps-deploy@v1
with:
azure-subscription: ${{ env.AZURE_SUBSCRIPTION }}
action: delete-build
service-name: <service instance name>
build-name: <build name>
Bereitstellen mit Maven-Plug-In
Eine weitere Option ist die Verwendung des Maven-Plug-Ins, um die JAR-Datei bereitzustellen und die App-Einstellungen zu aktualisieren. Der Befehl mvn azure-spring-apps:deploy ist idempotent und erstellt bei Bedarf automatisch Apps. Entsprechende Apps müssen nicht im Voraus erstellt werden.
name: AzureSpringApps
on: push
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@main
- name: Set up Java 11
uses: actions/setup-java@v3
with:
distribution: 'temurin'
java-version: '11'
- name: maven build, clean
run: |
mvn clean package -DskipTests
# Maven plugin can cosume this authentication method automatically
- name: Azure Login
uses: azure/login@v1
with:
creds: ${{ secrets.AZURE_CREDENTIALS }}
# Maven deploy, make sure you have correct configurations in your pom.xml
- name: deploy to Azure Spring Apps using Maven
run: |
mvn azure-spring-apps:deploy
Ausführen des Workflows
GitHub Actions sollte nach dem Pushen von .github/workflow/main.yml an GitHub automatisch aktiviert werden. Die Aktion wird ausgelöst, wenn Sie einen neuen Commit übertragen. Wenn Sie diese Datei im Browser erstellen, sollte Ihre Aktion bereits ausgeführt worden sein.
Klicken Sie auf der GitHub-Repositoryseite auf die Registerkarte Aktionen, um zu überprüfen, ob die Aktion aktiviert wurde:
Im Falle eines Aktionsfehlers (beispielsweise, wenn die Azure-Anmeldeinformationen nicht festgelegt wurden) können Sie die Überprüfungen erneut ausführen, nachdem Sie den Fehler behoben haben. Klicken Sie auf der GitHub-Repositoryseite auf Aktionen, wählen Sie die spezifische Workflowaufgabe aus, und klicken Sie auf die Schaltfläche Rerun checks (Überprüfungen erneut ausführen), um die Überprüfungen erneut auszuführen:
