Tutorial do NGINX: como usar o GitHub Actions para automatizar implantações canário de microsserviços

Christopher Harrison

Este post é um dos quatro tutoriais que ajudam você a colocar em prática os conceitos do Microservices March 2023: comece a disponibilizar microsserviços:

• Como implantar e configurar microsserviços
• Como gerenciar segredos com segurança em contêineres
• Como usar o GitHub Actions para automatizar lançamentos canário de microsserviços (este post)
• Como usar o rastreamento do OpenTelemetry para entender seus microsserviços

Automatizar as implantações é fundamental para o sucesso da maioria dos projetos. No entanto, não basta simplesmente implantar seu código. Você também precisa garantir que o tempo de inatividade seja limitado (ou eliminado) e ter a capacidade de reverter rapidamente em caso de falha. Combinar implantação canário e implantação azul-verde é uma abordagem comum para garantir que o novo código seja viável. Essa estratégia inclui duas etapas:

• Etapa 1: implantação canário para testes isolados – Implante seu código em um nó, servidor ou contêiner isolado, fora do seu ambiente, e faça testes para garantir que o código funcione conforme o esperado.
• Etapa 2: implantação blue-green para testar em produção – Supondo que o código funcione na implantação canário, transfira-o para servidores recém-criados (ou nós ou contêineres) no ambiente de produção, em paralelo aos servidores da versão atual. Em seguida, redirecione parte do tráfego de produção para a nova versão a fim de testar se ela continua funcionando bem sob uma carga maior. Normalmente, começa-se direcionando uma pequena porcentagem (10%, por exemplo) para a nova versão e aumentando-a gradualmente até que a nova versão receba todo o tráfego. O tamanho dos incrementos depende do seu grau de confiança na capacidade da nova versão de lidar com o tráfego; você pode até migrar completamente para a nova versão em uma única etapa.

Se você não conhece os diferentes casos de uso para distribuir o tráfego entre diferentes versões de um aplicativo ou site (divisão de tráfego), leia Como melhorar a resiliência no Kubernetes com o gerenciamento avançado de tráfego em nosso blog para obter uma compreensão conceitual de implantações blue-green, versões canário, testes A/B, limitação de taxa, circuit breaking e muito mais. Embora o artigo seja específico para Kubernetes, os conceitos são amplamente aplicáveis a aplicativos de microsserviços.

Visão geral do tutorial

Neste tutorial, mostramos como automatizar a primeira etapa de uma implantação canário blue-green usando o GitHub Actions. Nos quatro desafios do tutorial, você usa o Microsoft Azure Container Apps para implantar uma nova versão do seu aplicativo e, em seguida, usa o Azure Traffic Manager para transferir o tráfego do ambiente antigo para o novo:

• Criar e implantar um aplicativo de contêiner NGINX
• Configure permissões para automatizar implantações no Azure Container Apps
• Crie uma implantação canário azul-verde com uma GitHub Action
• Teste o fluxo de trabalho do GitHub Actions

Observação: Embora este tutorial use o Azure Container Apps, os conceitos e as técnicas podem ser aplicados a qualquer serviço de hospedagem baseado em nuvem.

Pré-requisitos e configuração

Pré-requisitos

Se você quiser seguir este tutorial em seu próprio ambiente, precisará de:

• Uma conta do Azure. Recomendamos usar uma conta que não esteja vinculada à sua organização, pois você pode ter problemas de permissão ao usar uma conta organizacional.
• A CLI do Azure.
• A CLI do GitHub, caso queira usá-la em vez da interface gráfica do GitHub no navegador (ou além dela).

Configuração

Crie e configure os recursos básicos necessários. Faça um fork e clone o repositório do tutorial, entre na CLI do Azure e instale a extensão para o Azure Container Apps.

1. No seu diretório pessoal, crie o diretório microservices-march. (Você também pode usar outro nome de diretório e adaptar as instruções conforme necessário.) Observação: Ao longo do tutorial, o prompt da linha de comando do Linux é omitido para facilitar a cópia e a colagem dos comandos no terminal.

mkdir ~/microservices-marchcd ~/microservices-march

1. Faça um fork e clone o repositório da plataforma Microservices March na sua conta pessoal do GitHub, usando a CLI ou a interface gráfica do GitHub.
   • Se estiver usando a interface gráfica do GitHub:
     1. Clique em Fork no canto superior direito da janela e selecione sua conta pessoal do GitHub no menu Owner.
        
     2. Clone o repositório localmente, substituindo pelo nome da sua conta <your_GitHub_account>:

git clone https://github.com/<your_GitHub_account>/platform.gitcd platform

• Se estiver usando a CLI do GitHub, execute:

gh repo fork microservices-march/platform -–clone

1. Faça login na CLI do Azure. Siga as instruções para entrar usando um navegador:

az login
[
  {
    "cloudName": "AzureCloud",
    "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e",
    "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c",
    "isDefault": true,
    "managedByTenants": [],
    "name": "Azure subscription 1",
    "state": "Enabled",
    "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
    "user": {
      "name": "user@example.com",
      "type": "user"
    }
  }
]

1. Instale a extensão containerapp:

az extension add --name containerapp -upgradeThe installed extension 'containerapp' is in preview.

Desafio 1: Criar e implantar um aplicativo de contêiner NGINX

Neste desafio inicial, você cria um Aplicativo de Contêiner do Azure com NGINX como a versão inicial do aplicativo, usada como base para a implantação canário blue-green. O Azure Container Apps é um serviço do Microsoft Azure que permite executar facilmente código de aplicativo empacotado em um contêiner, em um ambiente de contêiner pronto para produção.

1. Crie um grupo de recursos do Azure para o aplicativo de contêiner:

az group create --name my-container-app-rg --location westus{
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg",
  "location: "westus",
  "managedBy": null,
  "name": "my-container-app-rg",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}

1. Implante o contêiner no Azure Container Apps (esta etapa pode demorar um pouco):

az containerapp up --resource-group my-container-app-rg --name my-container-app --source ./ingress --ingress external --target-port 80 --location westus
... 
- image:
    registry: cac085021b77acr.azurecr.io
    repository: my-container-app
    tag: "20230315212413756768"
    digest: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451...
  runtime-dependency:
    registry: registry.hub.docker.com
    repository: library/nginx
    tag: "1.23"
    digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce...
  git: {} 
Run ID: cf1 was successful after 27s
Creating Containerapp my-container-app in resource group my-container-app-rg
Adding registry password as a secret with name "ca2ffbce7810acrazurecrio-cac085021b77acr" 
Container app created. Access your app at https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/
...

1. Na saída da Etapa 2, localize o nome e a URL do aplicativo de contêiner que você criou no Azure Container Registry (ACR). Eles estão destacados em laranja na saída de exemplo. Ao longo do tutorial, você substituirá as variáveis indicadas nos comandos pelos valores da sua saída (que serão diferentes dos valores da saída de exemplo da Etapa 2):
   • Nome do aplicativo de contêiner – Na chave image.registry, a cadeia de caracteres antes de .azurecr.io. No exemplo de saída da Etapa 2, ela é cac085021b77acr. Substitua <ACR_name> por essa cadeia de caracteres nos comandos subsequentes.
   • URL do aplicativo de contêiner – A URL na linha que começa com Container app created. No exemplo de saída da Etapa 2, ela é https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/. Substitua <ACR_URL> por essa URL nos comandos subsequentes.
2. Habilite as revisões para o aplicativo de contêiner, conforme necessário para uma implantação azul-verde:

az containerapp revision set-mode --name my-container-app --resource-group my-container-app-rg --mode multiple
"Multiple"

1. (Opcional) Teste se a implantação está funcionando consultando o endpoint /health no contêiner:

curl <ACR_URL>/healthOK

Desafio 2: configure permissões para automatizar implantações de Aplicativos de Contêiner do Azure

Neste desafio, você obtém o token JSON que permite automatizar as implantações de aplicativos de contêiner do Azure.

Você começa obtendo a ID do Registro de Contêiner do Azure (ACR) e, em seguida, a ID da entidade de segurança da sua identidade gerenciada. Depois, atribui à identidade gerenciada a função interna do Azure para o ACR e configura o aplicativo de contêiner para usar essa identidade. Por fim, obtém as credenciais JSON da identidade gerenciada, que serão usadas pelo GitHub Actions para autenticação no Azure.

Embora esse conjunto de etapas possa parecer trabalhoso, você só precisa executá-las uma vez ao criar um novo aplicativo e pode automatizar todo o processo com scripts. Neste tutorial, você executará as etapas manualmente para se familiarizar com elas.

Observação: Este processo de criação de credenciais para implantação é específico do Azure.

1. Consulte a ID da entidade de segurança da sua identidade gerenciada. Ela aparece na coluna PrincipalID da saída (que está dividida em duas linhas para facilitar a leitura). Você substituirá <managed_identity_principal_ID> por esse valor na etapa 3:

az containerapp identity assign --name my-container-app --resource-group my-container-app-rg --system-assigned --output table
PrincipalId                          ...                           
------------------------------------ ...  
    39f8434b-12d6-4735-81d8-ba0apo14579f ...
 
    ... TenantId
    ... ------------------------------------
        ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde

1. Consulte a ID do recurso do aplicativo de contêiner no ACR, substituindo <ACR_name> pelo nome que você anotou na Etapa 3 do Desafio 1. Você substituirá <ACR_resource_ID> por esse valor na próxima etapa:

az acr show --name <ACR_name> --query id --output tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr

1. Atribua a função interna do Azure para o ACR à identidade gerenciada do aplicativo de contêiner, substituindo <managed_identity_principal_ID> pela identidade gerenciada obtida na Etapa 1 e <ACR_resource_ID> pela ID do recurso obtida na Etapa 2:

az role assignment create --assignee <managed_identity_principal_ID> --role AcrPull --scope <ACR_resource_ID>
{
  "condition": null,
  "conditionVersion": null,
  "createdBy": null,
  "createdOn": "2023-03-15T20:28:40.831224+00:00",
  "delegatedManagedIdentityResourceId": null,
  "description": null,
  "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr/providers/Microsoft.Authorization/roleAssignments/f0773943-8769-44c6-a820-ed16007ff249",
  "name": "f0773943-8769-44c6-a820-ed16007ff249",
  "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f",
  "principalType": "ServicePrincipal",
  "resourceGroup": "my-container-app-rg",
  "roleDefinitionId": "/subscriptions/60e32142-384b-43r8-9329-0ecc67dca94c/providers/Microsoft.Authorization/roleDefinitions/7fd21dda-4fd3-4610-a1ca-43po272d538d",
  "scope": "/subscriptions/ 0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr",
  "type": "Microsoft.Authorization/roleAssignments",
  "updatedBy": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d",
  "updatedOn": "2023-03-15T20:28:41.127243+00:00"
}

1. Configure o aplicativo de contêiner para usar a identidade gerenciada ao efetuar pull de imagens do ACR, substituindo <ACR_name> pelo nome do aplicativo de contêiner que você anotou na Etapa 3 do Desafio 1 (e que também usou na Etapa 2 acima):

az containerapp registry set --name my-container-app --resource-group my-container-app-rg --server <ACR_name>.azurecr.io --identity system
[
  {
    "identity": "system",
    "passwordSecretRef": "",
    "server": "cac085021b77acr.azurecr.io",
    "username": ""
  }
]

1. Consulte a ID da sua assinatura do Azure.

az account show --query id --output tsv0efafl2-38ad-41w8-g49a-0ecc6723l97c

1. Crie um token JSON que contenha as credenciais a serem usadas pela GitHub Action, substituindo <subscription_ID> pela ID da sua assinatura do Azure. Salve a saída para colá-la como o valor do segredo chamado AZURE_CREDENTIALS em Adicionar segredos ao seu repositório do GitHub. Você pode ignorar com segurança o aviso de que --sdk-auth está obsoleto; trata-se de um problema conhecido:

az ad sp create-for-rbac --name my-container-app-rbac --role contributor --scopes /subscriptions/<subscription_ID>/resourceGroups/my-container-app-rg --sdk-auth --output json
Option '--sdk-auth' has been deprecated and will be removed in a future release.
...
{
  "clientId": "0732444d-23e6-47fb-8c2c-74bddfc7d2er",
  "clientSecret": "qg88Q~KJaND4JTWRPOLWgCY1ZmZwN5MK3N.wwcOe",
  "subscriptionId": "0efafl2-38ad-41w8-g49a-0ecc6723l97c",
  "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Desafio 3: crie uma GitHub Action para implantação canário blue-green

Neste desafio, você vai adicionar segredos ao seu repositório do GitHub (usados para gerenciar dados confidenciais nos fluxos de trabalho do GitHub Actions), criar um arquivo de fluxo de trabalho do GitHub Actions e executar o fluxo de trabalho do GitHub Actions.

Para uma introdução detalhada ao gerenciamento de segredos, confira o segundo tutorial do Microservices March 23, Como gerenciar segredos em contêineres com segurança em nosso blog.

Adicione segredos ao seu repositório do GitHub

Para implantar uma nova versão do aplicativo, você precisa criar uma série de segredos no repositório do GitHub do qual fez um fork em Configuração. Os segredos são as credenciais JSON da identidade gerenciada criada no Desafio 2, além de alguns parâmetros confidenciais específicos da implantação, necessários para implantar novas versões da imagem do NGINX no Azure. Na próxima seção, você usará esses segredos em uma GitHub Action para automatizar a implantação canário azul-verde.

• Se estiver usando a interface gráfica do GitHub:
  1. Acesse o repositório do GitHub que você bifurcou.
  2. Selecione Settings > Secrets and variables > Actions.
  3. Clique em Novo segredo do repositório.
  4. Digite os seguintes valores nos campos indicados:
     • Nome – AZURE_CREDENTIALS
     • Segredo – As credenciais JSON da Etapa 6 do Desafio 2
  5. Clique em Adicionar segredo.
  6. Repita as etapas 3 a 5 três vezes para criar os segredos listados na tabela. Insira os valores das colunas Nome do segredo e Valor do segredo nos campos Nome e Segredo da interface gráfica, respectivamente. Para o terceiro segredo, substitua <ACR_name> pelo nome atribuído ao aplicativo de contêiner que você anotou na etapa 3 do Desafio 1. Nome do segredo Valor do segredoCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>
  7. Prossiga para Criar um arquivo de fluxo de trabalho do GitHub Actions.
• Se estiver usando a CLI do GitHub:
  1. Na raiz do seu repositório, crie um arquivo temporário.

touch ~/creds.json

1. Usando seu editor de texto preferido, abra o arquivo creds.json e cole nele as credenciais JSON que você criou na Etapa 6 do Desafio 2.
2. Crie o segredo:

gh secret set AZURE_CREDENTIALS --repo <your_GitHub_account>/platform < ~/creds.json

1. Exclua creds.json:

rm ~/creds.json

1. Repita este comando para criar mais três segredos:

gh secret set <secret_name> --repo <your_GitHub_account>/platform

1. Para cada repetição, substitua <secret_name> por um dos valores da coluna Nome do segredo na tabela. Quando solicitado, cole o valor correspondente da coluna Valor do segredo. Para o terceiro segredo, substitua <ACR_name> pelo nome atribuído ao aplicativo de contêiner que você anotou na Etapa 3 do Desafio 1. Nome do segredo Valor do segredoCONTAINER_APP_NAME my-container-appRESOURCE_GROUP my-container-app-rgACR_NAME <ACR_name>

Criar um arquivo de fluxo de trabalho do GitHub Actions

Com a identidade gerenciada e os segredos configurados, você pode criar um arquivo de fluxo de trabalho para uma GitHub Action que automatize a implantação canário blue-green.

Observação: Os arquivos de fluxo de trabalho são definidos no formato YAML, no qual os espaços em branco são significativos. Preserve o recuo mostrado nas etapas abaixo.

1. Crie um arquivo para o fluxo de trabalho da Action.
   • Se estiver usando a interface gráfica do GitHub:
     1. Acesse seu repositório do GitHub.
     2. Selecione Actions > New workflow > Skip this and set up a workflow yourself.
   • Se estiver usando a CLI do GitHub, crie o diretório .github/workflows e crie um novo arquivo chamado main.yml:

mkdir .github/workflowstouch .github/workflows/main.yml

1. Usando seu editor de texto preferido, adicione o texto do fluxo de trabalho ao arquivo main.yml. O método mais fácil é copiar o texto exibido em Arquivo completo do fluxo de trabalho. Como alternativa, você pode criar o arquivo manualmente adicionando o conjunto de trechos indicados nesta etapa. Observação: os arquivos de fluxo de trabalho são definidos no formato YAML, no qual os espaços em branco são significativos. Se você copiar os trechos, preserve a indentação (e, para ter certeza, compare seu arquivo com o Arquivo completo do fluxo de trabalho.
   • Defina o nome do fluxo de trabalho:

name: Deploy to Azure

• Configure o fluxo de trabalho para ser executado quando um push ou uma solicitação de pull for feita para a branch principal:

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

• Na seção jobs, defina o job build-deploy, que faz o checkout do código, entra no Azure e implanta a aplicação no Azure Container App:

jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Build and deploy Container App
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }}
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io

• Defina o trabalho test-deployment, que obtém a URL de preparo da revisão recém-implantada e usa uma GitHub Action para enviar uma solicitação ao endpoint da API /health a fim de garantir que a nova revisão esteja respondendo. Se a verificação de integridade for bem-sucedida, o Azure Traffic Manager no aplicativo de contêiner será atualizado para direcionar todo o tráfego ao contêiner recém-implantado. Observação: certifique-se de recuar a chave test-deployment no mesmo nível da chave build-deploy definida no item anterior:

  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp --upgrade

          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Arquivo completo do fluxo de trabalho

Este é o texto completo do arquivo de fluxo de trabalho da Action.

name: Deploy to Azure
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
jobs:
  build-deploy:
    runs-on: ubuntu-22.04
    steps:
      - name: Check out the codebase
        uses: actions/checkout@v3

      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}
     
      - name: Build and deploy Container 
        run: |
          # Add the containerapp extension manually
          az extension add --name containerapp -upgrade
       
          # Use Azure CLI to deploy update
          az containerapp up -n ${{ secrets.CONTAINER_APP_NAME }} 
            -g ${{ secrets.RESOURCE_GROUP }} 
            --source ${{ github.workspace }}/ingress 
            --registry-server ${{ secrets.ACR_NAME }}.azurecr.io
  test-deployment:
    needs: build-deploy
    runs-on: ubuntu-22.04
    steps:
      - name: Log in to Azure
        uses: azure/login@v1
        with:
          creds: ${{ secrets.AZURE_CREDENTIALS }}

      - name: Get new container name
        run: |
          # Install the containerapp extension for the Azure CLI
          az extension add --name containerapp --upgrade
          # Get the last deployed revision name
          REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
          # Get the last deployed revision's fqdn
          REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
          # Store values in env vars
          echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
          echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

      - name: Test deployment
        id: test-deployment
        uses: jtalk/url-health-check-action@v3 # Marketplace action to touch the endpoint
        with:
          url: "https://${{ env.REVISION_FQDN }}/health" # Staging endpoint

      - name: Deploy succeeded
        run: |
          echo "Deployment succeeded! Enabling new revision"
          az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Execute o fluxo de trabalho da Action

• Se estiver usando a interface gráfica do GitHub:
  1. Clique em Iniciar commit, adicione uma mensagem de commit, se desejar, e, na caixa de diálogo, selecione Fazer commit do novo arquivo. O novo arquivo de fluxo de trabalho é mesclado à branch principal e começa a ser executado.
  2. Clique em Actions para monitorar o progresso do fluxo de trabalho.
• Se estiver usando a CLI do GitHub:
  1. Adicione o arquivo main.yml à área de staging do Git:

git add .github/workflows/main.yml

1. Faça o commit do arquivo:

git commit -m "feat: create GitHub Actions workflow"

1. Envie suas alterações para o GitHub:

git push

1. Monitore o progresso do fluxo de trabalho:

gh workflow view main.yml --repo <your_GitHub_account>/platform

Desafio 4: teste o fluxo de trabalho do GitHub Actions

Neste desafio, você testa o fluxo de trabalho. Primeiro, você simula uma atualização bem-sucedida do balanceador de carga do Ingress e confirma que a aplicação foi atualizada. Em seguida, simula uma atualização malsucedida (que resulta em um erro interno do servidor) e confirma que a aplicação publicada permanece inalterada.

Faça uma atualização bem-sucedida

Crie uma atualização bem-sucedida e veja o fluxo de trabalho ser concluído com sucesso.

• Se estiver usando a interface gráfica do GitHub:
  1. Selecione Code > ingress > default.conf.template.
  2. Abra default.conf.template para edição selecionando o ícone de lápis com a dica de ferramenta Editar este arquivo.
  3. No bloco location /health próximo ao final do arquivo, altere a diretiva return conforme indicado:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

1. Na caixa de diálogo, selecione Create a new branch for this commit and start a pull request e, em seguida, Propose changes.
2. Clique em Criar pull request para acessar o modelo de pull request.
3. Clique em Criar pull request novamente para criar o pull request.
4. Clique em Ações para acompanhar o andamento do fluxo de trabalho.
5. Quando o fluxo de trabalho for concluído, acesse o aplicativo de contêiner no ponto de extremidade <ACR_URL>/health, em que <ACR_URL> é a URL que você anotou na Etapa 3 do Desafio 1. Observe a mensagem Successful Update! exibida.
6. Você pode confirmar a mensagem iniciando uma sessão de terminal e enviando uma solicitação de verificação de integridade ao aplicativo, substituindo novamente <ACR_URL> pelo valor que você registrou na Etapa 3 do Desafio 1:

curl <ACR_URL>/healthSuccessful Update!

1. Prossiga para Fazer uma atualização sem sucesso.

• Se estiver usando a CLI do GitHub:
  1. Crie uma nova branch chamada patch-1:

git checkout -b patch-1

1. No editor de texto de sua preferência, abra ingress/default.conf.template e, no bloco location /health próximo ao final do arquivo, altere a diretiva return conforme indicado:

location /health {
    access_log off;
    return 200 "Successful Update!n";
}

1. Adicione default.conf.template à área de staging do Git:

git add ingress/default.conf.template

1. Faça o commit do arquivo:

git commit -m "feat: update NGINX ingress"

1. Envie suas alterações para o GitHub:

git push --set-upstream origin patch-1

1. Crie uma solicitação de pull (PR):

gh pr create --head patch-1 --fill --repo <your_GitHub_account>/platform

1. Monitore o progresso do fluxo de trabalho:

gh workflow view main.yml --repo <your_GitHub_account>/platform

1. Quando o fluxo de trabalho for concluído, envie uma solicitação de verificação de integridade ao aplicativo, substituindo <ACR_URL> pelo valor que você anotou na Etapa 3 do Desafio 1:

curl <ACR_URL>/health
Successful Update!

Faça uma atualização sem sucesso

Agora, crie uma atualização malsucedida e observe o fluxo de trabalho falhar. Basicamente, isso envolve repetir as etapas descritas em Fazer uma atualização bem-sucedida, mas usando um valor diferente para a diretiva return.

• Se estiver usando a interface gráfica do GitHub:
  1. Selecione Code > ingress > default.conf.template.
  2. No canto superior esquerdo, selecione main e, em seguida, o nome da ramificação que termina com patch-1, que você criou na seção anterior.
  3. Abra default.conf.template para edição selecionando o ícone de lápis com a dica de ferramenta Editar este arquivo.
  4. Altere a diretiva return conforme indicado:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

1. Selecione Fazer commit diretamente no branch -patch-1 e, em seguida, selecione Fazer commit das alterações.
2. Selecione Ações para monitorar o progresso do fluxo de trabalho. Observe que o fluxo de trabalho é executado novamente quando os arquivos na PR são atualizados.
3. Quando o fluxo de trabalho for concluído, acesse seu aplicativo de contêiner no ponto de extremidade <ACR_URL>/health, em que <ACR_URL> é a URL que você registrou na Etapa 3 do Desafio 1. Observe que a mensagem é Atualização bem-sucedida! (a mesma exibida após a atualização anterior, que foi bem-sucedida). Embora isso possa parecer paradoxal, na verdade confirma que esta atualização falhou – a tentativa de atualização resultou no status 500 (que significa Erro interno do servidor) e não foi aplicada.
4. Você pode confirmar a mensagem iniciando uma sessão de terminal e enviando uma solicitação de verificação de integridade ao aplicativo, substituindo novamente <ACR_URL> pelo valor que você anotou na Etapa 3 do Desafio 1:

curl <ACR_URL>/healthSuccessful Update!

• Se estiver usando a CLI do GitHub:
  1. Faça checkout da branch patch-1 que você criou na seção anterior:

git checkout patch-1

1. No seu editor de texto preferido, abra ingress/default.conf.template e altere novamente a diretiva return conforme indicado:

location /health {
    access_log off;
    return 500 "Unsuccessful Update!n";
}

1. Adicione default.conf.template à área de staging do Git:

git add ingress/default.conf.template

1. Faça o commit do arquivo:

git commit -m "feat: update NGINX ingress again"

1. Envie suas alterações para o GitHub:

git push

1. Monitore o progresso do fluxo de trabalho:

gh workflow view main.yml --repo <your_GitHub_account>/platform

1. Quando o fluxo de trabalho for concluído, envie uma solicitação de verificação de integridade ao aplicativo, substituindo <ACR_URL> pelo valor que você anotou na Etapa 3 do Desafio 1:

curl <ACR_URL>/healthSuccessful Update!

1. Pode parecer paradoxal que a mensagem seja Successful Update! (a mesma exibida após a atualização anterior, que foi bem-sucedida). Embora isso possa parecer paradoxal, na verdade confirma que esta atualização falhou – a tentativa de atualização resultou no status 500 (que significa Internal Server Error) e não foi aplicada.

Limpeza de recursos

É recomendável remover os recursos do Azure implantados durante o tutorial para evitar possíveis cobranças futuras:

az group delete -n my-container-app-rg -y

Você também pode excluir o fork que criou, se desejar.

• Se estiver usando a interface gráfica do GitHub:
  1. Clique em Configurações.
  2. Role a página até o final.
  3. Clique em Excluir este repositório.
  4. Digite <your_GitHub_account>/platform e selecione Entendo as consequências, excluir este repositório.
• Se estiver usando a CLI do GitHub:

gh repo delete <your_GitHub_account>/platform -yes

Próximos passos

Parabéns! Você aprendeu a usar o GitHub Actions para realizar uma implantação canário blue-green de um aplicativo de microsserviços. Confira estes artigos na documentação do GitHub para continuar explorando e ampliando seus conhecimentos sobre DevOps:

• Sobre fluxos de trabalho
• Sobre integração contínua usando o GitHub Actions
• Sobre a implantação contínua usando o GitHub Actions
• Sobre monitoramento e solução de problemas

Se você já está pronto para experimentar a segunda etapa de uma implantação canário (testes em produção), confira o tutorial do Microservices March 2022, Melhore a disponibilidade e a resiliência com uma implantação canário em nosso blog. Ele usa o NGINX Service Mesh para fazer a transição gradual para uma nova versão do aplicativo. Mesmo que suas implantações ainda não sejam complexas o suficiente para exigir uma malha de serviços, ou que você não use o Kubernetes, os princípios também se aplicam a implantações mais simples que usam apenas um controlador de Ingress ou um balanceador de carga.

Para continuar aprendendo sobre microsserviços, confira o Microservices March 2023. Na Unidade 3: acelere as implantações de microsserviços com automação, você aprenderá mais sobre como automatizar implantações.

Sobre o autor

Christopher Harrison

Mais publicações de Christopher Harrison