Utiliser CI/CD Azure Spring Apps avec GitHub Actions
Remarque
Azure Spring Apps est le nouveau nom du service Azure Spring Cloud. Bien que le service ait un nouveau nom, vous verrez l’ancien nom à divers endroits pendant un certain temps, car nous travaillons à mettre à jour les ressources telles que les captures d’écran, les vidéos et les diagrammes.
Cet article s’applique au : Niveau ✔️ De base/Standard ✔️ Entreprise
Cet article explique comment générer un workflow CI/CD pour Azure Spring Apps avec GitHub Actions.
GitHub Actions prend en charge un workflow automatisé de cycle de vie de développement logiciel. Grâce à GitHub Actions pour Azure Spring Apps, vous pouvez créer des workflows dans votre référentiel pour générer, tester, créer un package, publier et déployer sur Azure.
Prérequis
Cet exemple nécessite Azure CLI.
Configurer le référentiel GitHub et s’authentifier
Vous avez besoin des informations d’identification du principal de service Azure pour autoriser une action de connexion Azure. Pour récupérer des informations d’identification Azure, exécutez les commandes suivantes sur votre ordinateur local :
az login
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID> \
--json-auth
Pour accéder à un groupe de ressources spécifique, vous pouvez réduire l’étendue :
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
--json-auth
La commande doit générer un objet JSON :
{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
...
}
Cet exemple utilise l’échantillon steeltoe sur GitHub. Fork the repository, open the GitHub repository page for the fork, and select the Paramètres tab. Open the Secrets menu and select New secret :
Définissez le nom du secret sur AZURE_CREDENTIALS et sa valeur sur la chaîne JSON que vous avez trouvée sous le titre Configurer le référentiel GitHub et s’authentifier.
Vous pouvez également récupérer les informations d’identification de connexion Azure à partir de Key Vault dans GitHub Actions, comme expliqué dans Authentifier Azure Spring Cloud auprès de Key Vault dans GitHub Actions.
Approvisionner une instance de service
Pour approvisionner votre instance de service Azure Spring Apps, exécutez les commandes suivantes à l’aide d’Azure CLI.
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
Générer le workflow
Le workflow est défini à l’aide des options suivantes.
Préparer le déploiement avec Azure CLI
La commande az spring app create n’est pas idempotente actuellement. Après l’avoir exécutée une fois, vous obtenez une erreur si vous réexécutez la même commande. Nous vous recommandons d’utiliser ce workflow sur les applications et les instances Azure Spring Apps existantes.
Utilisez les commandes suivantes dans l’interface de ligne de commande Azure pour la préparation :
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
Déployer avec Azure CLI directement
Créez le fichier .github/workflows/main.yml dans le référentiel avec le contenu suivant. Remplacez le <nom de votre groupe de ressources> et le <nom de votre service> par les valeurs correctes.
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 }}
Configurer le référentiel GitHub et s’authentifier
Vous avez besoin des informations d’identification du principal de service Azure pour autoriser une action de connexion Azure. Pour récupérer des informations d’identification Azure, exécutez les commandes suivantes sur votre ordinateur local :
az login
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID> \
--json-auth
Pour accéder à un groupe de ressources spécifique, vous pouvez réduire l’étendue :
az ad sp create-for-rbac \
--role contributor \
--scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
--json-auth
La commande doit générer un objet JSON :
{
"clientId": "<GUID>",
"clientSecret": "<GUID>",
"subscriptionId": "<GUID>",
"tenantId": "<GUID>",
...
}
Cet exemple utilise l’échantillon PiggyMetrics sur GitHub. Fork the sample, un case activée Copy the Azure branch only, open the GitHub repository page, and select the Paramètres tab. Open Secrets menu and select Add a new secret :
Définissez le nom du secret sur AZURE_CREDENTIALS et sa valeur sur la chaîne JSON que vous avez trouvée sous le titre Configurer le référentiel GitHub et s’authentifier.
Vous pouvez également récupérer les informations d’identification de connexion Azure à partir de Key Vault dans GitHub Actions, comme expliqué dans Authentifier Azure Spring Cloud auprès de Key Vault dans GitHub Actions.
Approvisionner une instance de service
Pour approvisionner votre instance de service Azure Spring Apps, exécutez les commandes suivantes à l’aide d’Azure CLI.
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
Exemples de worflows de bout en bout
Les exemples suivants illustrent des scénarios d’utilisation courante.
Déploiement en cours
Les sections suivantes montrent différentes options de déploiement de votre application.
En production
Azure Spring Apps prend en charge le déploiement sur des déploiements avec des artefacts générés (par exemple, JAR ou .NET Core ZIP) ou une archive de code source.
L’exemple suivant utilise le déploiement de production par défaut dans Azure Spring Apps en utilisant un fichier JAR créé par Maven. Cet exemple est le seul scénario de déploiement possible lors de l’utilisation de la référence SKU de base :
Remarque
Le modèle de recherche de package ne doit retourner qu’un seul package. Si la tâche de build produit plusieurs packages JAR tels que sources.jar et javadoc.jar, vous devez affiner le modèle de recherche afin qu’il corresponde uniquement à l’artefact binaire de l’application.
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
L’exemple suivant utilise le déploiement de production par défaut dans Azure Spring Apps en utilisant le code source.
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 }}
L’exemple suivant se déploie sur le déploiement de production par défaut dans Azure Spring Apps à l’aide du code source dans le plan Entreprise. Vous pouvez spécifier le générateur à utiliser pour déployer des actions à l’aide de l’option builder .
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>
L’exemple suivant utilise le déploiement de production par défaut dans Azure Spring Apps avec une image conteneur existante.
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>
Pendant le déploiement, vous pouvez obtenir davantage de fonctionnalités à l’aide d’arguments supplémentaires. Pour plus d’informations, consultez la section Arguments de GitHub Action pour le déploiement sur Azure Spring Apps.
Bleu-vert
Les exemples suivants utilisent un déploiement de préproduction existant. Ce déploiement ne reçoit pas le trafic de production tant qu’il n’est pas défini comme déploiement de production. Vous pouvez définir use-staging-deployment sur true pour rechercher automatiquement le déploiement de préproduction ou simplement allouer un deployment-name spécifique. Nous nous concentrons uniquement sur l’action spring-apps-deploy et ne pas laisser les travaux préparatoires dans le reste de l’article.
# 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
Pour plus d’informations sur les déploiements bleu-vert, et la présentation d’une autre approche, consultez Stratégies de déploiement bleu-vert.
Définition du déploiement de production
L’exemple suivant définit le déploiement intermédiaire actuel en tant que production, en permutant efficacement le déploiement qui reçoit le trafic de production.
# 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
Supprimer un déploiement de préproduction
L’action Delete Staging Deployment vous permet de supprimer le déploiement qui ne reçoit pas de trafic de production. Cette suppression libère les ressources utilisées par ce déploiement et permet un nouveau déploiement intermédiaire :
# 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>
Créer ou mettre à jour la build (plan Entreprise uniquement)
L’exemple suivant crée ou met à jour une ressource de build dans le plan Entreprise :
# 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>
Supprimer la build (plan Entreprise uniquement)
L’exemple suivant supprime une ressource de build dans le plan Entreprise :
# 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>
Déployer avec le plug-in Maven
Une autre option consiste à utiliser le plug-in Maven pour déployer le fichier jar et mettre à jour les paramètres de l’application. La commande mvn azure-spring-apps:deploy est idempotente et crée automatiquement des applications si nécessaire. Vous n’avez pas besoin de créer des applications correspondantes à l’avance.
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
Exécuter le workflow
Les Actions GitHub doivent être activées automatiquement une fois que vous avez envoyé .github/workflow/main.yml à GitHub. L’action est déclenchée lorsque vous envoyez une nouvelle validation. Si vous créez ce fichier dans le navigateur, votre action doit déjà avoir été exécutée.
Pour vérifier que l’action a été activée, sélectionnez l’onglet Actions de la page du référentiel GitHub :
Si votre action s’exécute par erreur, par exemple si vous n’avez pas défini les informations d’identification Azure, vous pouvez réexécuter les vérifications après avoir corrigé l’erreur. Dans la page du référentiel GitHub, sélectionnez Actions, sélectionnez la tâche de flux de travail spécifique, puis sélectionnez le bouton Réexécuter les vérifications pour réexécuter les vérifications :
