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:
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.
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.
Se você quiser fazer este tutorial em seu próprio ambiente, você precisa:
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.
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
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:
Se estiver usando o GitHub CLI, execute:
gh repo fork microservices-março/plataforma -–clone
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" } } ]
Instale a extensão containerapp
:
az extension add --name containerapp -upgrade A extensão instalada 'containerapp' está em pré-visualização.
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.
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" }
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/ ...
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.
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"
(Opcional) Teste se a implantação está funcionando consultando o endpoint /health no contêiner:
enrolar <URL_ACR>/saúdeOK
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.
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
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
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" }
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": ""
}
]
Procure sua ID de assinatura do Azure .
conta az mostrar --id da consulta --saída tsv 0efafl2-38ad-41w8-g49a-0ecc6723l97c
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/" }
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.
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:
Digite os seguintes valores nos campos indicados:
AZURE_CREDENTIALS
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> |
Se estiver usando o GitHub CLI:
Na raiz do seu repositório, crie um arquivo temporário.
toque em ~/creds.json
Crie o segredo:
gh conjunto secreto AZURE_CREDENTIALS --repo <sua_conta_GitHub>/plataforma < ~/creds.json
Excluir creds.json :
rm ~/creds.json
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> |
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.
Crie um arquivo para o fluxo de trabalho de ação.
Se estiver usando a GUI do GitHub:
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
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"
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"
Se estiver usando a GUI do GitHub:
Se estiver usando o GitHub CLI:
Adicione main.yml à área de preparação do Git:
git adicionar .github/workflows/main.yml
Confirme o arquivo:
git commit -m "feat: criar fluxo de trabalho do GitHub Actions"
Envie suas alterações para o GitHub:
empurrar git
Monitore o progresso do fluxo de trabalho:
gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
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.
Crie uma atualização bem-sucedida e observe o fluxo de trabalho ser bem-sucedido.
Se estiver usando a GUI do GitHub:
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";
}
Atualização
bem-sucedida
!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:
Crie uma nova ramificação chamada patch-1 :
git checkout -b patch-1
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";
}
Adicione default.conf.template à área de preparação do Git:
git add ingress/default.conf.template
Confirme o arquivo:
git commit -m "feat: atualizar entrada NGINX"
Envie suas alterações para o GitHub:
git push --set-upstream origem patch-1
Crie uma solicitação de pull (PR):
gh pr criar --head patch-1 --fill --repo <sua_conta_GitHub>/plataforma
Monitore o progresso do fluxo de trabalho:
gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
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!
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:
Altere a diretiva de retorno
conforme indicado:
localização /saúde {
access_log off;
return 500 "Atualização sem sucesso!\n";
}
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.
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:
Confira a ramificação patch-1 que você criou na seção anterior :
git checkout patch-1
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";
}
Adicione default.conf.template à área de preparação do Git:
git add ingress/default.conf.template
Confirme o arquivo:
git commit -m "feat: atualizar o NGINX ingress novamente"
Envie suas alterações para o GitHub:
empurrar git
Monitore o progresso do fluxo de trabalho:
gh fluxo de trabalho visualizar main.yml --repo <sua_conta_GitHub>/plataforma
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.
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:
Se estiver usando o GitHub CLI:
gh repositório excluir <sua_conta_GitHub>/plataforma -sim
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."