Compartilhar via

Usa a CI/CD do Azure Spring Apps com o GitHub Actions

  • Artigo

Observação

Os planos Básico, Standard e Enterprise serão preteridos a partir de meados de março de 2025, com um período de desativação de 3 anos. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para mais informações, confira o anúncio de desativação dos Aplicativos Spring do Azure.

O plano consumo e dedicado Standard será preterido a partir de 30 de setembro de 2024, com um desligamento completo após seis meses. Recomendamos a transição para os Aplicativos de Contêiner do Azure. Para mais informações, confira Migrar o plano dedicado e consumo Standard dos Aplicativos Spring do Azure para os Aplicativos de Contêiner do Azure.

Este artigo se aplica a:✅ Básico/Standard ✅ Enterprise

Este artigo mostra como criar um fluxo de trabalho de CI/CD para o Azure Spring Apps com o GitHub Actions.

O GitHub Actions permite um fluxo de trabalho automatizado de ciclo de vida de desenvolvimento de software. Com o GitHub Actions para o Azure Spring Apps, é possível criar fluxos de trabalho no repositório para criar, testar, empacotar, liberar e implantar no Azure.

Pré-requisitos

Este exemplo exige a CLI do Azure.

Configurar repositório do GitHub e autenticar

É necessária uma credencial de entidade de serviço do Azure para autorizar a ação de logon do Azure. Para obter uma credencial do Azure, execute os seguintes comandos em seu computador local:

az login
az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID> \
    --json-auth

Para acessar um grupo de recursos específico, você pode reduzir o escopo:

az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
    --json-auth

O comando deve gerar um objeto JSON semelhante a este:

{
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
}

Este exemplo usa o exemplo do steeltoe no GitHub. Crie um fork no repositório, abra a página do repositório GitHub para o fork e escolha a guia Configurações. Abra o menu Segredos e escolha Novo segredo:

Captura de tela da página Segredos e variáveis do GitHub Actions com o botão Novo segredo do repositório realçado.

Defina o nome do segredo como AZURE_CREDENTIALS e seu valor como a cadeia de caracteres JSON que você encontrou no título Configurar seu repositório do GitHub e autenticar.

Captura de tela da página Segredos/Novo segredo do GitHub Actions.

Você também pode obter as credenciais de logon do Azure de Key Vault em GitHub Actions, conforme explicado em Autenticar o Azure Spring com Key Vault no GitHub Actions.

Provisionar uma instância de serviço

Para provisionar sua instância de serviço do Azure Spring Apps, execute os comandos a seguir usando a CLI do Azure.

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

Criar o fluxo de trabalho

O fluxo de trabalho é definido usando as opções a seguir.

Preparar-se para a implantação com a CLI do Azure

O comando az spring app create não é idempotente no momento. Depois de executar uma vez, você receberá um erro se executar o mesmo comando novamente. Recomendamos esse fluxo de trabalho em instâncias e aplicativos existentes do Azure Spring Apps.

Use os seguintes comandos da CLI do Azure:

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

Implantar com CLI do Azure diretamente

Crie o arquivo .github/workflows/main.yml no repositório com o conteúdo a seguir. Substitua <o nome do grupo de recursos> e <o nome do serviço> pelos valores corretos.

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 }}

Configurar repositório do GitHub e autenticar

É necessária uma credencial de entidade de serviço do Azure para autorizar a ação de logon do Azure. Para obter uma credencial do Azure, execute os seguintes comandos em seu computador local:

az login
az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID> \
    --json-auth

Para acessar um grupo de recursos específico, você pode reduzir o escopo:

az ad sp create-for-rbac \
    --role contributor \
    --scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP> \
    --json-auth

O comando deve gerar um objeto JSON semelhante a este:

{
    "clientId": "<GUID>",
    "clientSecret": "<GUID>",
    "subscriptionId": "<GUID>",
    "tenantId": "<GUID>",
    ...
}

Este exemplo usa o exemplo PiggyMetrics no GitHub. Crie fork do exemplo, desmarque Copiar somente o branch do Azure, abra a página do repositório GitHub e selecione a guia Configurações. Abra o menu Segredos e selecione Adicionar um novo secreto:

Captura de tela da página Segredos e variáveis do GitHub Actions com o botão Novo segredo do repositório realçado.

Defina o nome do segredo como AZURE_CREDENTIALS e seu valor como a cadeia de caracteres JSON que você encontrou no título Configurar seu repositório do GitHub e autenticar.

Captura de tela da página Segredos/Novo segredo do GitHub Actions.

Você também pode obter as credenciais de logon do Azure de Key Vault em GitHub Actions, conforme explicado em Autenticar o Azure Spring com Key Vault no GitHub Actions.

Provisionar uma instância de serviço

Para provisionar sua instância de serviço do Azure Spring Apps, execute os comandos a seguir usando a CLI do Azure.

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

Fluxos de trabalho de exemplo de ponta a ponta

Os exemplos a seguir demonstram cenários de uso comuns.

Implantando

As seções a seguir mostram várias opções para implantar seu aplicativo.

Para produção

Os Aplicativos Spring do Azure dão suporte à implantação em implantações com artefatos compilados (por exemplo, JAR ou .NET Core ZIP) ou arquivo de código-fonte.

O exemplo a seguir implanta a implantação de produção padrão no Azure Spring Apps usando o arquivo JAR criado pelo Maven. Esse exemplo é o único cenário de implantação possível ao usar o SKU Básico:

Observação

O padrão de pesquisa de pacote apenas deve retornar exatamente um pacote. Se a tarefa de build produzir vários pacotes JAR, como sources.jar e javadoc.jar, você precisará refinar o padrão de pesquisa para que ele corresponda apenas ao artefato binário do aplicativo.

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

O exemplo a seguir implanta a implantação de produção padrão no Azure Spring Apps usando o código-fonte.

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 }}

O exemplo a seguir é implantado na implantação de produção padrão nos Aplicativos Spring do Azure usando o código-fonte no plano Enterprise. Você pode especificar qual construtor usar para implantar ações usando a opção 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>

O exemplo a seguir implanta a implantação de produção padrão nos Aplicativos Spring do Azure com uma imagem de contêiner existente.

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>

Durante a implantação, você poderá obter mais funcionalidade usando mais argumentos. Para obter mais informações, confira a seção Argumentos do GitHub Action para implantação nos Aplicativos Spring do Azure.

Blue-green

Os exemplos a seguir implantam em uma implantação de preparo existente. Essa implantação não recebe tráfego de produção até que seja definida como uma implantação de produção. Você pode definir use-staging-deployment como true para localizar a implantação de preparo automaticamente ou simplesmente alocar um nome de implantação específico. Nos concentramos apenas na ação spring-apps-deploy e deixamos de fora os trabalhos preparatórios no restante do artigo.

# 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

Para obter mais informações sobre implantações blue-green, incluindo uma abordagem alternativa, consulte estratégias de implantação blue-green.

Definir a implantação de produção

O exemplo a seguir define a implantação de preparo atual como produção, trocando efetivamente qual implantação recebe o tráfego de produção.

# 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

Excluir uma implantação de preparo

A ação Delete Staging Deployment permite que você exclua a implantação não recebendo tráfego de produção. Essa exclusão libera recursos usados por essa implantação e abre espaço para uma nova implantação de preparo:

# 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>

Criar ou atualizar build (somente o plano Enterprise)

O exemplo a seguir cria ou atualiza um recurso de build no plano Enterprise:

# 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>

Excluir build (somente o plano Enterprise)

O exemplo a seguir exclui um recurso de build no plano Enterprise:

# 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>

Implantar com o plug-in Maven

Outra opção é usar o plug-in Maven para implantar o JAR e atualizar as configurações do aplicativo. O comando mvn azure-spring-apps:deploy é idempotente e cria aplicativos automaticamente, se necessário. Você não precisa criar aplicativos correspondentes com antecedência.

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

Executar o fluxo de trabalho

O GitHub Actions deve ser habilitado automaticamente depois que você enviar .github/workflow/main.yml por push para o GitHub. A ação é disparada quando você envia uma nova confirmação por push. Se você criar esse arquivo no navegador, sua ação já deverá ter sido executada.

Para verificar se a ação foi habilitada, selecione a guia Ações na página de repositório do GitHub:

Captura de tela da guia GitHub Actions mostrando a seção Todos os fluxos de trabalho.

Se a ação for executada com erro, por exemplo, se você não tiver definido a credencial do Azure, poderá executar novamente as verificações depois de corrigir o erro. Na página de repositório do GitHub, selecione Ações, escolha a tarefa de fluxo de trabalho específica e selecione o botão Executar verificações novamente para executar novamente as verificações:

Captura de tela da guia GitHub Actions com o botão Executar as verificações novamente realçado.

Próximas etapas