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:
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.
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:
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.
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:
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:
