Usar o Azure Spring Apps CI/CD com ações do GitHub

Nota

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

O plano de consumo padrão e dedicado 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 obter mais informações, consulte Migrar consumo padrão e plano dedicado do Azure Spring Apps para Aplicativos de Contêiner do Azure.

Este artigo aplica-se a: ✔️ Basic/Standard ✔️ Enterprise

Este artigo mostra como criar um fluxo de trabalho de CI/CD para o Azure Spring Apps com Ações do GitHub.

As ações do GitHub suportam um fluxo de trabalho automatizado do ciclo de vida de desenvolvimento de software. Com o GitHub Actions for Azure Spring Apps, você pode criar fluxos de trabalho em seu repositório para criar, testar, empacotar, liberar e implantar no Azure.

Pré-requisitos

Este exemplo requer a CLI do Azure.

Configurar o repositório GitHub e autenticar

Você precisa de 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 sua máquina 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:

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

Este exemplo usa a amostra steeltoe no GitHub. Fork o repositório, abra a página do repositório GitHub para a bifurcação e selecione a guia Configurações . Abra o menu Segredos e selecione Novo segredo:

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

Defina o nome secreto e AZURE_CREDENTIALS seu valor para a cadeia de caracteres JSON que você encontrou sob o título Configurar seu repositório GitHub e autenticar.

Captura de tela dos segredos das Ações do GitHub / Nova página secreta.

Você também pode obter a credencial de logon do Azure do Cofre da Chave nas Ações do GitHub, conforme explicado em Autenticar o Azure Spring com o Cofre da Chave nas Ações do GitHub.

Instância do serviço de provisão

Para provisionar sua instância de serviço do Azure Spring Apps, execute os seguintes comandos 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 seguintes opções.

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

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

Use os seguintes comandos da CLI do Azure para preparação:

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 diretamente com a CLI do Azure

Crie o arquivo .github/workflows/main.yml no repositório com o seguinte conteúdo. 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 o repositório GitHub e autenticar

Você precisa de 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 sua máquina 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:

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

Este exemplo usa o exemplo PiggyMetrics no GitHub. Fork o exemplo, desmarque Copiar somente a ramificação 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 segredo:

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

Defina o nome secreto e AZURE_CREDENTIALS seu valor para a cadeia de caracteres JSON que você encontrou sob o título Configurar seu repositório GitHub e autenticar.

Captura de tela dos segredos das Ações do GitHub / Nova página secreta.

Você também pode obter a credencial de logon do Azure do Cofre da Chave nas Ações do GitHub, conforme explicado em Autenticar o Azure Spring com o Cofre da Chave nas Ações do GitHub.

Instância do serviço de provisão

Para provisionar sua instância de serviço do Azure Spring Apps, execute os seguintes comandos 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 completos

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

Implementação

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

Para a produção

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

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

Nota

O padrão de pesquisa de pacotes só deve retornar exatamente um pacote. Se a tarefa de compilação 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 na 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 implanta na implantação de produção padrão no Azure Spring Apps usando o código-fonte no plano Enterprise. Você pode especificar qual construtor usar para ações de implantação usando a builder opção.

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 na implantação de produção padrão no Azure Spring Apps 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ê pode obter mais funcionalidade usando mais argumentos. Para obter mais informações, consulte a seção Argumentos da Ação do GitHub para implantação no Azure Spring Apps.

Azul-esverdeado

Os exemplos a seguir são implantados 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 true para localizar a implantação de preparo automaticamente ou apenas alocar um nome de implantação específico. Nós só nos concentramos na spring-apps-deploy ação e deixamos de fora os trabalhos preparatórios no resto 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 verde-azul, incluindo uma abordagem alternativa, consulte Estratégias de implantação verde-azul.

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

Excluindo uma implantação de preparo

A Delete Staging Deployment ação permite excluir a implantação que não recebe 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 preparação:

# 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 compilação (somente plano Enterprise)

O exemplo a seguir cria ou atualiza um recurso de compilação 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 compilação (somente plano Enterprise)

O exemplo a seguir exclui um recurso de compilação 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>

Implante 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 automaticamente Apps, 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

As Ações do GitHub devem ser ativadas automaticamente depois que você enviar .github/workflow/main.yml para o GitHub. A ação é acionada quando você envia uma nova confirmação. Se você criar esse arquivo no navegador, sua ação já deve ter sido executada.

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

Captura de tela da guia Ações do GitHub mostrando a seção Todos os fluxos de trabalho.

Se sua ação for executada por engano, 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 do repositório GitHub, selecione Ações, selecione a tarefa de fluxo de trabalho específica e, em seguida, selecione o botão Executar verificações novamente para executar verificações novamente:

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

Próximos passos