Utiliser CI/CD Azure Spring Apps avec GitHub Actions

Remarque

Les plans Essentiel, Standardet Entreprise seront déconseillés à compter de la mi-mars 2025, avec une période de mise hors service de 3 ans. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez l’annonce concernant la mise hors service d’Azure Spring Apps.

La consommation Standard et le plan dédié seront déconseillés à compter du 30 septembre 2024, avec un arrêt complet six mois après. Nous vous recommandons de passer à Azure Container Apps. Pour plus d’informations, consultez Migrer la consommation standard et le plan dédié Azure Spring Apps vers Azure Container Apps.

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. Dupliquez le référentiel, ouvrez la page de référentiel GitHub pour la fourche, puis sélectionnez l’onglet Paramètres. Ouvrez le menu Secrets, puis sélectionnez Nouveau secret :

Capture d’écran de la page des secrets et des variables GitHub Actions avec le bouton New repository secret (Nouveau secret de dépôt) mis en évidence.

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.

Capture d’écran de la page GitHub Actions secret / New secret (Secrets d’actions / Nouveau secret).

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. Dupliquez (fork) l’exemple, décochez Copy the Azure branch only (Copier la branche Azure uniquement), ouvrez la page du dépôt GitHub, puis sélectionnez l’onglet Settings (Paramètres). Ouvrez le menu Secrets, puis sélectionnez Add a new secret (Ajouter un nouveau secret) :

Capture d’écran de la page des secrets et des variables GitHub Actions avec le bouton New repository secret (Nouveau secret de dépôt) mis en évidence.

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.

Capture d’écran de la page GitHub Actions secret / New secret (Secrets d’actions / Nouveau secret).

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 avec des artefacts créés (par exemple, JAR ou ZIP .NET Core) 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 avec la référence SKU Essentiel :

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 utilise le déploiement de production par défaut dans Azure Spring Apps en utilisant le code source du plan Entreprise. Vous pouvez spécifier le générateur à utiliser pour les actions de déploiement à 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 bénéficier de fonctionnalités supplémentaires en utilisant plus d’arguments. Pour plus d’informations, consultez la section Arguments de l’article GitHub Action for deploying to Azure Spring Apps (GitHub Action pour un 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 en tant que 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 omettons 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 de préproduction actuel en tant que déploiement de production, en permutant 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 le trafic de production. Cette suppression a pour effet de libérer les ressources utilisées par ce déploiement et fait de la place pour accueillir un nouveau déploiement de préproduction :

# 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 supprimer 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 se déclenche lorsque vous envoyez (push) un nouveau commit. 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 :

Capture d’écran de l’onglet GitHub Actions montrant la section All workflows (Tous les workflows).

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 :

Capture d’écran de l’onglet GitHub Actions avec le bouton Re-run checks (Réexécuter les vérifications) mis en évidence.

Étapes suivantes