Verwenden von Azure Spring Apps-CI/CD mit GitHub Actions
Hinweis
Die Pläne Basic, Standard und Enterprise gelten ab Mitte März 2025 als veraltet und werden über einen Zeitraum von drei Jahren eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie in der Ankündigung zur Einstellung von Azure Spring Apps.
Der Plan Standardverbrauch und dediziert gilt ab dem 30. September 2024 als veraltet und wird nach sechs Monaten vollständig eingestellt. Es wird empfohlen, auf Azure Container Apps umzustellen. Weitere Informationen finden Sie unter Migrieren des Plans „Standardverbrauch und dediziert“ von Azure Spring Apps zu Azure Container Apps.
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 den Befehl ein Mal ausgeführt haben, erhalten Sie eine Fehlermeldung, 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. Forken Sie das Beispiel, deaktivieren Sie Nur Azure-Branch kopieren, öffnen Sie die Seite des GitHub-Repositorys, und wählen Sie die Registerkarte Einstellungen aus. Öffnen Sie das Menü Geheimnisse, und wählen Sie Neues Geheimnis 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 das Ausrollen der Bereitstellungen mit erstellten 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 einzig mögliche Bereitstellungsszenario bei Verwendung der Basic-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 }}
Das folgende Beispiel wird mithilfe des Quellcodes im Enterprise-Plan in der Standardproduktionsbereitstellung in Azure Spring Apps bereitgestellt. Mit der Option builder können Sie angeben, welcher Generator für Bereitstellungsaktionen 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 die Funktionalität verbessern, indem Sie weitere Argumente verwenden. Weitere Informationen finden Sie unter GitHub-Aktionen für die Bereitstellung in Azure Spring Apps im Abschnitt Argumente.
Blau-grün
Die folgenden Beispiele werden in einer vorhandenen Zurückspeicherungs-Bereitstellung ausgerollt. Diese Bereitstellung erhält so lange keinen Produktionsdatenverkehr, bis sie als Produktionsbereitstellung festgelegt wird. 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 Aktion spring-apps-deploy und lassen die vorbereitenden Aufträge im Rest des Artikels 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 Produktion festgelegt, wodurch effektiv ausgetauscht wird, welche Bereitstellung Produktionsdatenverkehr erhält.
# 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 Aktion Delete Staging Deployment können Sie die Bereitstellung löschen, die keinen Produktionsdatenverkehr empfängt. Durch das Löschen werden von dieser Bereitstellung verwendete Ressourcen freigegeben und Platz für eine neue Stagingbereitstellung geschaffen:
# 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 von Buildressourcen (nur im 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>
Löschen von Buildressourcen (nur im 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 Apps bei Bedarf automatisch. 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 pushen. 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:
