BLOG | NGINX

Tutorial do NGINX: Como usar ações do GitHub para automatizar implantações de microsserviços Canary

NGINX-Parte-de-F5-horiz-preto-tipo-RGB
Miniatura de Christopher Harrison
Cristóvão Harrison
Publicado em 21 de março de 2023

Este post é um dos quatro tutoriais que ajudam você a colocar em prática os conceitos do Microservices de março de 2023: Comece a fornecer microsserviços :

 

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

  • Passo 1: Implantação canário para testar isoladamente – Implante seu código em um nó, servidor ou contêiner isolado fora do seu ambiente e teste para garantir que o código funcione conforme o esperado.
  • Passo 2: Implantação azul-verde para testar em produção – Supondo que o código funcione na implantação canário, transfira o código para servidores recém-criados (ou nós ou contêineres) em seu ambiente de produção, juntamente com os servidores para a versão atual. Em seguida, redirecione uma parte do tráfego de produção para a nova versão para testar se ela continua funcionando bem sob carga mais alta. Na maioria das vezes, você começa direcionando uma pequena porcentagem (10%, digamos) para a nova versão e aumenta gradativamente até que a nova versão receba todo o tráfego. O tamanho dos incrementos depende de quão confiante você está de que a nova versão pode lidar com o tráfego; você pode até mesmo mudar completamente para a nova versão em uma única etapa.

Se você não estiver familiarizado com os diferentes casos de uso para distribuir 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 azul-verde, lançamentos canários, testes A/B, limitação de taxa, interrupção de circuito e muito mais. Embora o blog seja específico para o 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 azul-verde canário 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:

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

Pré-requisitos e configuração

Pré-requisitos

Se você quiser fazer este tutorial em seu próprio ambiente, você precisa:

  • Uma conta do Azure . Recomendamos que você use uma conta que não esteja vinculada à sua organização, porque você pode ter problemas com permissões ao usar uma conta organizacional.
  • A CLI do Azure .
  • O GitHub CLI , se você quiser usá-lo em vez de (ou em adição a) a GUI do GitHub baseada em navegador.

Configurar

Crie e configure os recursos básicos necessários. Bifurque e clone o repositório para o tutorial, faça login na CLI do Azure e instale a extensão para Aplicativos de Contêiner do Azure.

  1. No seu diretório inicial, crie o diretório microservices-march . (Você também pode usar um nome de diretório diferente e adaptar as instruções adequadamente.)

    Observação:  Ao longo do tutorial, o prompt na linha de comando do Linux é omitido para facilitar a cópia e colagem dos comandos no seu terminal.

    mkdir ~/microservices-marchcd ~/microservices-march
    
  2. Bifurque e clone o repositório da plataforma Microservices March para sua conta pessoal do GitHub, usando a CLI ou a GUI do GitHub.

    • Se estiver usando a GUI do GitHub:

      1. Clique em Fork no canto superior direito da janela e selecione sua conta pessoal do GitHub no menu Proprietário .

        captura de tela da GUI do GitHub mostrando o fork do repositório para este tutorial

      2. Clone o repositório localmente, substituindo o nome da sua conta por <sua_conta_GitHub>:

        clone do git https://github.com/<sua_conta_GitHub>/plataforma.gitcd plataforma
        
    • Se estiver usando o GitHub CLI, execute:

      gh repo fork microservices-março/plataforma -–clone
      
  3. Faça login no Azure CLI. Siga os prompts para fazer login usando um navegador:

    az login [ { "nomedanuvem": "AzureCloud", "homeTenantId": "cfd11e0f-1435-450s-bdr1-ffab73b4er8e", "id": "60efapl2-38ad-41w8-g49a-0ecc6723l97c", "isDefault": verdadeiro, "managedByTenants": [], "nome": "Assinatura do Azure 1", "estado": "Habilitado", "tenantId": "cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde", "usuário": { "nome": "usuário@exemplo.com", "tipo": "usuário" } } ]
    
  4. Instale a extensão containerapp :

    az extension add --name containerapp -upgrade A extensão instalada 'containerapp' está em pré-visualização.
    

Desafio 1: Crie e implante um aplicativo de contêiner NGINX

Neste desafio inicial, você cria um aplicativo de contêiner NGINX Azure como a versão inicial do aplicativo usado como linha de base para a implantação azul-verde canário. O Azure Container Apps é um serviço do Microsoft Azure que você usa para executar facilmente o código do 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 meu-aplicativo-de-container-rg --location westus { "id": "/subscriptions/0efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/meu-aplicativo-de-container-rg", "location: "westus", "managedBy": null, "name": "meu-aplicativo-de-container-rg", "properties": { "provisioningState": "Sucesso" }, "tags": null, "type": "Microsoft.Resources/grupos de recursos" }
    
  2. Implante o contêiner no Azure Container Apps (esta etapa pode demorar um pouco):

    az containerapp up \ --resource-group meu-container-app-rg \ --name meu-container-app \ --source ./ingress \ --ingress external \ --target-port 80 \ --location westus ... - imagem: registro: cac085021b77acr .azurecr.io repositório: meu-container-app tag: "20230315212413756768" resumo: sha256:90a9fc67c409e244195ec0ea190ce3b84195ae725392e8451... dependência de tempo de execução: registro: registry.hub.docker.com repositório: biblioteca/nginx tag: "1.23" digest: sha256:aa0afebbb3cfa473099a62c4b32e9b3fb73ed23f2a75a65ce... git: {} ID de execução: cf1 foi bem-sucedido após 27s Criando Containerapp my-container-app no grupo de recursos my-container-app-rg Adicionando senha de registro como um segredo com o nome "ca2ffbce7810acrazurecrio-cac085021b77acr" Aplicativo de contêiner criado. Acesse seu aplicativo em https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ ...
    
  3. Na saída da Etapa 2, encontre o nome e a URL do aplicativo de contêiner que você criou no Registro de Contêiner do Azure (ACR). Eles são destacados em laranja na saída de exemplo. Você substituirá os valores da sua saída (que serão diferentes da saída de exemplo na Etapa 2) pelas variáveis indicadas nos comandos ao longo do tutorial:

    • Nome do aplicativo de contêiner – Na chave image.registry , a sequência de caracteres antes de .azurecr.io . Na saída de exemplo da Etapa 2, é cac085021b77acr .

      Substitua esta sequência de caracteres por <Nome_ACR> em comandos subsequentes.

    • URL do aplicativo contêiner – A URL na linha que começa com Aplicativo contêiner criado . Na saída de exemplo da Etapa 2, é https://my-container-app.delightfulmoss-eb6d59d5.westus.azurecontainerapps.io/ .

      Substitua esta URL por <URL_ACR> em comandos subsequentes.

  4. Habilite revisões para o aplicativo de contêiner conforme necessário para uma implantação azul-verde:

    az containerapp revisão set-mode \ --name meu-container-app \ --resource-group meu-container-app-rg \ --mode multiple "Múltiplo"
    
  5. (Opcional) Teste se a implantação está funcionando consultando o endpoint /health no contêiner:

    enrolar <URL_ACR>/saúdeOK
    

Desafio 2: Configurar permissões para automatizar implantações de aplicativos de contêiner do Azure

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

Comece obtendo a ID do Registro de Contêiner do Azure (ACR) e, em seguida, a ID principal da sua identidade gerenciada do Azure. Em seguida, atribua a função interna do Azure para ACR à identidade gerenciada e configure o aplicativo de contêiner para usar a identidade gerenciada. Por fim, você obtém as credenciais JSON para a identidade gerenciada, que serão usadas pelo GitHub Actions para autenticação no Azure.

Embora esse conjunto de etapas possa parecer tedioso, você só precisa executá-las uma vez ao criar um novo aplicativo e poderá criar um script completo do processo. O tutorial pede que você execute 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. Procure o ID principal da sua identidade gerenciada. Ele aparece na coluna PrincipalID da saída (que é dividida em duas linhas para legibilidade). Você substituirá esse valor por <ID_principal_de_identidade_gerenciada> na Etapa 3:

    az containerapp identidade atribuir \ --name meu-aplicativo-de-container \ --resource-group meu-aplicativo-de-container-rg \ --system-assigned \ --output table PrincipalId ... ------------------------------------ ...  
        39f8434b-12d6-4735-81d8-ba0apo14579f ... ... TenantId ... ------------------------------------ ... cfda3e0f-14g5-4e05-bfb1-ffab73b4fsde
    
  2. Procure o ID do recurso do aplicativo de contêiner no ACR, substituindo <Nome_ACR> com o nome que você registrou na Etapa 3 de Desafio 1. Você substituirá esse valor por <ID_do_recurso_ACR> no próximo passo:

    az acr mostrar --nome <Nome_ACR> --id da consulta --saída tsv/subscriptions/60efafl2-38ad-41w8-g49a-0ecc6723l97c/resourceGroups/my-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr
    
  3. Atribua a função interna do Azure para ACR à identidade gerenciada do aplicativo de contêiner, substituindo <ID_principal_de_identidade_gerenciada> com a identidade gerenciada obtida na Etapa 1, e <ID_do_recurso_ACR> com o ID do recurso obtido na Etapa 2:

    az atribuição de função criar \ --assignee <ID_principal_de_identidade_gerenciada> \
    --role AcrPull \
    --escopo <ID_do_recurso_ACR>
    {
    "condição": nulo,
    "conditionVersion": nulo,
    "criadoPor": nulo,
    "criadoEm": "2023-03-15T20:28:40.831224+00:00", "delegatedManagedIdentityResourceId": nulo, "descrição": nulo, "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", "nome": "f0773943-8769-44c6-a820-ed16007ff249", "principalId": "39f8ee4b-6fd6-47b5-89d8-ba0a4314579f", "tipoprincipal": "ServicePrincipal", "resourceGroup": "meu-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/meu-container-app-rg/providers/Microsoft.ContainerRegistry/registries/cac085021b77acr", "type": "Microsoft.Authorization/roleAssignments", "atualizado por": "d4e122d6-5e64-4bg1-9cld-2aceeb0oi24d", "atualizado em": "2023-03-15T20:28:41.127243+00:00" }
    
  4. Configure o aplicativo de contêiner para usar a identidade gerenciada ao extrair imagens do ACR, substituindo <Nome_ACR> com o nome do aplicativo de contêiner que você registrou na Etapa 3 em Desafio 1 (e também usado na Etapa 2 acima):

    conjunto de registro az containerapp \ --name meu-container-app \
    --resource-group meu-container-app-rg \
    --server <Nome_ACR>.azurecr.io \
    --sistema de identidade
    [
    {
    "identidade": "sistema",
    "passwordSecretRef": "",
    "servidor": "cac085021b77acr.azurecr.io",
    "nome de usuário": ""
    }
    ]
    
  5. Procure sua ID de assinatura do Azure .

    conta az mostrar --id da consulta --saída tsv 0efafl2-38ad-41w8-g49a-0ecc6723l97c
    
  6. Crie um token JSON que contenha as credenciais a serem usadas pela Ação do GitHub, substituindo <ID_da_assinatura> com sua ID de assinatura do Azure. Salve a saída para colar como o valor do segredo chamado CREDENCIAIS_AZURE em Adicione segredos ao seu repositório GitHub. Você pode ignorar com segurança o aviso sobre a descontinuação do --sdk-auth ; é um problema conhecido :

    az ad sp criar-para-rbac \ --nome meu-container-app-rbac \
    --role contribuidor \
    --scopes /subscriptions/<ID_da_assinatura>/resourceGroups/meu-container-app-rg \
    --sdk-auth \
    --output json
    A opção '--sdk-auth' foi descontinuada e será removida em uma versão futura.
    ...
    {
    "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 ação GitHub de implantação Canary Blue-Green

Neste desafio, você adiciona segredos ao seu repositório do GitHub (usado para gerenciar dados confidenciais em seus fluxos de trabalho de ação do GitHub), cria um arquivo de fluxo de trabalho de ação e executa o fluxo de trabalho de ação .

Para uma introdução detalhada ao gerenciamento de segredos, consulte o segundo tutorial de microsserviços de 23 de março, Como gerenciar segredos com segurança em contêineres, em nosso blog.

Adicione segredos ao seu repositório GitHub

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

  • Se estiver usando a GUI do GitHub:

    1. Navegue até seu repositório bifurcado do GitHub.
    2. Selecione Configurações > Segredos e variáveis > Ações .
    3. Clique em Novo segredo do repositório .
    4. Digite os seguintes valores nos campos indicados:

      • NomeAZURE_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. Digite os valores das colunas Nome Secreto e Valor Secreto nos campos Nome e Segredo da GUI, respectivamente. Para o terceiro segredo, substitua <Nome_ACR> com o nome atribuído ao aplicativo de contêiner que você registrou na Etapa 3 de Desafio 1.

      Nome Secreto Valor Secreto
      NOME_DO_APLICATIVO_DO_CONTÊINER meu-container-app
      GRUPO_DE_RECURSOS meu-container-app-rg
      NOME_ACR <Nome_ACR>
    7. Prossiga para Criar um arquivo de fluxo de trabalho de ação do GitHub .
  • Se estiver usando o GitHub CLI:

    1. Na raiz do seu repositório, crie um arquivo temporário.

      toque em ~/creds.json
      
    2. Usando seu editor de texto preferido, abra creds.json e copie as credenciais JSON que você criou na Etapa 6 do Desafio 2 .
    3. Crie o segredo:

      gh conjunto secreto AZURE_CREDENTIALS --repo <sua_conta_GitHub>/plataforma < ~/creds.json
      
    4. Excluir creds.json :

      rm ~/creds.json
      
    5. Repita este comando para criar mais três segredos:

      conjunto secreto gh <nome_secreto> --repositório <sua_conta_GitHub>/plataforma
      

      Para cada repetição, substitua <nome_secreto> com um dos valores em Nome Secreto coluna na tabela. No prompt, cole o valor associado da coluna Valor Secreto . Para o terceiro segredo, substitua <Nome_ACR> com o nome atribuído ao aplicativo de contêiner que você registrou na Etapa 3 de Desafio 1.

      Nome Secreto Valor Secreto
      NOME_DO_APLICATIVO_DO_CONTÊINER meu-container-app
      GRUPO_DE_RECURSOS meu-container-app-rg
      NOME_ACR <Nome_ACR>

Crie um arquivo de fluxo de trabalho de ação do GitHub

Com a identidade gerenciada e os segredos em vigor, você pode criar um arquivo de fluxo de trabalho para uma ação do GitHub que automatiza a implantação azul-verde do Canary.

Observação:  Os arquivos de fluxo de trabalho são definidos no formato YAML, onde o espaço em branco é significativo. Certifique-se de preservar o recuo mostrado nas etapas abaixo.

  1. Crie um arquivo para o fluxo de trabalho de ação.

    • Se estiver usando a GUI do GitHub:

      1. Navegue até seu repositório GitHub.
      2. Selecione Ações > Novo fluxo de trabalho > Ignorar isso e configurar um fluxo de trabalho você mesmo .
    • Se estiver usando o GitHub CLI, crie o diretório .github/workflows e crie um novo arquivo chamado main.yml :

      mkdir .github/fluxos de trabalhotouch .github/fluxos de trabalho/main.yml
      
  2. Usando seu editor de texto preferido, adicione o texto do fluxo de trabalho ao main.yml . O método mais fácil é copiar o texto que aparece no Arquivo de Fluxo de Trabalho Completo . Como alternativa, você pode criar o arquivo manualmente adicionando o conjunto de snippets anotados nesta etapa.

    Observação:  Os arquivos de fluxo de trabalho são definidos no formato YAML, onde o espaço em branco é significativo. Se você copiar os snippets, certifique-se de preservar o recuo (e para ter mais certeza, compare seu arquivo com o Arquivo de fluxo de trabalho completo ).

    • Defina o nome do fluxo de trabalho:

      nome: Implantar no Azure
      
    • Configure o fluxo de trabalho para ser executado quando uma solicitação push ou pull for feita para a ramificação principal:

      em:
      push:
      branches:
      - principal
      pull_request:
      branches:
      - principal
      
    • Na seção jobs , defina o trabalho build-deploy , que verifica o código, efetua login no Azure e implanta o aplicativo no Azure Container App:

      jobs:
      build-deploy:
      runs-on: ubuntu-22.04
      steps:
      - name: Confira a base de código
      usa: actions/checkout@v3
      
      - nome: Efetue login no Azure
      usa: azure/login@v1
      com:
      creds: ${{ secrets.AZURE_CREDENTIALS }}
      
      - nome: Crie e implante o Container App
      execute: |
      # Adicione a extensão containerapp manualmente
      az extension add --name containerapp --upgrade
      # Use o Azure CLI para implantar a atualização
      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 de implantação de teste , que obtém a URL de preparação da revisão recém-implantada e usa uma ação do GitHub para executar ping no ponto de extremidade da API /health para garantir que a nova revisão esteja respondendo. Se a verificação de integridade for bem-sucedida, o Gerenciador de Tráfego do Azure no aplicativo de contêiner será atualizado para apontar todo o tráfego para o contêiner recém-implantado.

      Observação:  Certifique-se de recuar a chave test-deployment no mesmo nível que a chave build-deploy que você definiu no marcador anterior:

        test-deployment:
      necessidades: build-deploy
      runs-on: ubuntu-22.04
      etapas:
      - nome: Efetue login no Azure
      usa: azure/login@v1
      com:
      creds: ${{ secrets.AZURE_CREDENTIALS }}
      
      - nome: Obter novo nome de contêiner
      executar: |
      # Adicionar a extensão containerapp manualmente
      az extension add --name containerapp --upgrade
      
      # Obter o último nome de revisão implantado
      REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
      # Obter o fqdn da última revisão implantada
      REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
      # Armazenar valores em variáveis de ambiente
      echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
      echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV
      
      - name: Implantação de teste
      id: test-deployment
      usa: jtalk/url-health-check-action@v3 # Ação do Marketplace para tocar no endpoint
      com:
      url: "https://${{ env.REVISION_FQDN }}/health" # Endpoint de preparação
      
      - nome: Implantação bem-sucedida
      executar: |
      echo "Implantação bem-sucedida! Habilitando nova revisão"
      az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"
      

Arquivo de fluxo de trabalho completo

Este é o texto completo do arquivo de fluxo de trabalho de ação.

nome: Implantar no Azure
em:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
build-deploy:
runs-on: ubuntu-22.04
steps:
- name: Confira a base de código
usa: actions/checkout@v3

- nome: Efetue login no Azure
usa: azure/login@v1
com:
creds: ${{ secrets.AZURE_CREDENTIALS }}

- nome: Crie e implante o Container
run: |
# Adicione a extensão containerapp manualmente
az extension add --name containerapp -upgrade

# Use o CLI do Azure para implantar a atualização
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: Efetue login no Azure
usa: azure/login@v1
com:
creds: ${{ secrets.AZURE_CREDENTIALS }}

- nome: Obter novo nome de contêiner
executar: |
# Instalar a extensão containerapp para o Azure CLI
az extension add --name containerapp --upgrade
# Obter o último nome de revisão implantado
REVISION_NAME=`az containerapp revision list -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --query "[].name" -o tsv | tail -1`
# Obter o fqdn da última revisão implantada
REVISION_FQDN=`az containerapp revision show -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision "$REVISION_NAME" --query properties.fqdn -o tsv`
# Armazenar valores em variáveis de ambiente
echo "REVISION_NAME=$REVISION_NAME" >> $GITHUB_ENV
echo "REVISION_FQDN=$REVISION_FQDN" >> $GITHUB_ENV

- name: Implantação de teste
id: test-deployment
usa: jtalk/url-health-check-action@v3 # Ação do Marketplace para tocar no endpoint
com:
url: "https://${{ env.REVISION_FQDN }}/health" # Endpoint de preparação

- nome: Implantação bem-sucedida
executar: |
echo "Implantação bem-sucedida! Habilitando nova revisão"
az containerapp ingress traffic set -n ${{ secrets.CONTAINER_APP_NAME }} -g ${{ secrets.RESOURCE_GROUP }} --revision-weight "${{ env.REVISION_NAME }}=100"

Executar o fluxo de trabalho de ação

  • Se estiver usando a GUI do GitHub:

    1. Clique em Iniciar confirmação , adicione uma mensagem de confirmação, se desejar, e na caixa de diálogo selecione Confirmar novo arquivo . O novo arquivo de fluxo de trabalho é mesclado na ramificação principal e começa a ser executado.
    2. Clique em Ações para monitorar o progresso do fluxo de trabalho.
  • Se estiver usando o GitHub CLI:

    1. Adicione main.yml à área de preparação do Git:

      git adicionar .github/workflows/main.yml
      
    2. Confirme o arquivo:

      git commit -m "feat: criar fluxo de trabalho do GitHub Actions"
      
    3. Envie suas alterações para o GitHub:

      empurrar git
      
    4. Monitore o progresso do fluxo de trabalho:

      gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
      

Desafio 4: Teste o fluxo de trabalho de ações do GitHub

Neste desafio, você testa o fluxo de trabalho. Primeiro, simule uma atualização bem-sucedida do seu balanceador de carga do Ingress e confirme se o aplicativo foi atualizado. Em seguida, você simula uma atualização malsucedida (o que leva a um erro interno do servidor) e confirma que o aplicativo publicado permanece inalterado.

Faça uma atualização bem-sucedida

Crie uma atualização bem-sucedida e observe o fluxo de trabalho ser bem-sucedido.

  • Se estiver usando a GUI do GitHub:

    1. Selecione Código > 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:

      localização /saúde {
      access_log off;
      return 200 "Atualização bem-sucedida!\n";
      }
      
    4. Na caixa de diálogo, selecione Criar uma nova ramificação para esta confirmação e iniciar uma solicitação de pull e, em seguida, Propor alterações .
    5. Clique em Criar solicitação de pull para acessar o modelo de solicitação de pull.
    6. Clique em Criar solicitação de pull novamente para criar a solicitação de pull.
    7. Clique em Ações para monitorar o progresso do fluxo de trabalho.
    8. Quando o fluxo de trabalho for concluído, navegue até seu aplicativo de contêiner em <URL_ACR>/saúde ponto final, onde o <URL_ACR> é o URL que você anotou na Etapa 3 de Desafio 1. Observe a mensagem Atualização bem-sucedida !
    9. 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 <URL_ACR> com o valor que você registrou na Etapa 3 de Desafio 1:

      enrolar <URL_ACR>/saúdeAtualização bem-sucedida!
      
    10. Prossiga para fazer uma atualização sem sucesso .
  • Se estiver usando o GitHub CLI:

    1. Crie uma nova ramificação chamada patch-1 :

      git checkout -b patch-1
      
    2. No seu editor de texto preferido, abra ingress/default.conf.template e no bloco location /health próximo ao final do arquivo, altere a diretiva return conforme indicado:

      localização /saúde {
      access_log off;
      return 200 "Atualização bem-sucedida!\n";
      }
      
    3. Adicione default.conf.template à área de preparação do Git:

      git add ingress/default.conf.template
      
    4. Confirme o arquivo:

      git commit -m "feat: atualizar entrada NGINX"
      
    5. Envie suas alterações para o GitHub:

      git push --set-upstream origem patch-1
      
    6. Crie uma solicitação de pull (PR):

      gh pr criar --head patch-1 --fill --repo <sua_conta_GitHub>/plataforma
      
    7. Monitore o progresso do fluxo de trabalho:

      gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
      
    8. Quando o fluxo de trabalho for concluído, envie uma solicitação de verificação de integridade ao aplicativo, substituindo <URL_ACR> com o valor que você registrou na Etapa 3 de Desafio 1:

      enrolar <URL_ACR>/saúde
      Atualização bem-sucedida!
      

Faça uma atualização sem sucesso

Agora crie uma atualização malsucedida e observe o fluxo de trabalho falhar. Isso envolve basicamente repetir as etapas em Fazer uma atualização bem-sucedida , mas com um valor diferente para a diretiva de retorno .

  • Se estiver usando a GUI do GitHub:

    1. Selecione Código > ingress > default.conf.template .
    2. No canto superior esquerdo, selecione main e depois o nome do branch 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 de retorno conforme indicado:

      localização /saúde {
      access_log off;
      return 500 "Atualização sem sucesso!\n";
      }
      
    5. Selecione Confirmar diretamente na ramificação -patch-1 e depois Confirmar alterações .
    6. Selecione Ações para monitorar o progresso do fluxo de trabalho. Observe que o fluxo de trabalho é executado novamente quando os arquivos no PR são atualizados.
    7. Quando o fluxo de trabalho for concluído, navegue até seu aplicativo de contêiner em <URL_ACR>/saúde ponto final, onde o <URL_ACR> é o URL que você registrou na Etapa 3 de Desafio 1.

       

      Observe que a mensagem é Atualização bem-sucedida ! (a mesma da atualização anterior bem-sucedida). Embora isso possa parecer paradoxal, na verdade confirma que esta atualização falhou – a tentativa de atualização resultou em status500 (que significa erro interno do servidor ) e não foi aplicado.

    8. 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 <URL_ACR> com o valor que você registrou na Etapa 3 de Desafio 1:

      enrolar <URL_ACR>/saúdeAtualização bem-sucedida!
      
  • Se estiver usando o GitHub CLI:

    1. Confira a ramificação patch-1 que você criou na seção anterior :

      git checkout patch-1
      
    2. No seu editor de texto preferido, abra ingress/default.conf.template e altere novamente a diretiva de retorno conforme indicado:

      localização /saúde {
      access_log off;
      return 500 "Atualização sem sucesso!\n";
      }
      
    3. Adicione default.conf.template à área de preparação do Git:

      git add ingress/default.conf.template
      
    4. Confirme o arquivo:

      git commit -m "feat: atualizar o NGINX ingress novamente"
      
    5. Envie suas alterações para o GitHub:

      empurrar git
      
    6. Monitore o progresso do fluxo de trabalho:

      gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
      
    7. Quando o fluxo de trabalho for concluído, envie uma solicitação de verificação de integridade ao aplicativo, substituindo <URL_ACR> com o valor que você registrou na Etapa 3 de Desafio 1:

      enrolar <URL_ACR>/saúdeAtualização bem-sucedida!
      

      Pode parecer paradoxal que a mensagem seja Atualização bem-sucedida ! (a mesma da atualização anterior bem-sucedida). Embora isso possa parecer paradoxal, na verdade confirma que esta atualização falhou – a tentativa de atualização resultou em status500 (que significa erro interno do servidor ) e não foi aplicado.

Limpeza de recursos

Provavelmente você deseja remover os recursos do Azure implantados no tutorial para evitar possíveis cobranças futuras:

az grupo delete -n meu-container-app-rg -y

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

  • Se estiver usando a GUI do GitHub:

    1. Clique em Configurações .
    2. Role para baixo até o final da página.
    3. Clique em Excluir este repositório .
    4. Tipo <sua_conta_GitHub>/plataforma e selecione Entendo as consequências, exclua este repositório.
  • Se estiver usando o GitHub CLI:

    gh repositório excluir <sua_conta_GitHub>/plataforma -sim
    

PRÓXIMOS PASSOS

Parabéns! Você aprendeu como usar o GitHub Actions para executar uma implantação azul-verde canário de um aplicativo de microsserviços. Confira estes artigos nos documentos do GitHub para continuar explorando e aumentando seu conhecimento sobre DevOps:

Se você estiver pronto para experimentar a segunda etapa de uma implantação canário (teste em produção), confira o tutorial da Microservices de março de 2022, Melhore o tempo de atividade 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 precisar de uma malha de serviço, ou que você não esteja usando o Kubernetes, os princípios ainda se aplicam a implantações mais simples usando apenas um controlador Ingress ou balanceador de carga.

Para continuar sua educação em microsserviços, confira Microservices março de 2023. Na Unidade 3, Acelere implantações de microsserviços com automação , você aprenderá mais sobre como automatizar implantações.


"Esta postagem do blog pode fazer referência a produtos que não estão mais disponíveis e/ou não têm mais suporte. Para obter as informações mais atualizadas sobre os produtos e soluções F5 NGINX disponíveis, explore nossa família de produtos NGINX . O NGINX agora faz parte do F5. Todos os links anteriores do NGINX.com redirecionarão para conteúdo semelhante do NGINX no F5.com."