Usa a CI/CD do Azure Spring Apps com o GitHub Actions
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 ao: ✔️ nível Básico/Standard ✔️ nível 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:
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.
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:
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.
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:
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: