Partilhar via


Configurar a implantação contínua para um aplicativo Web Python nos Aplicativos de Contêiner do Azure

Este artigo faz parte de um tutorial sobre como contentorizar e implementar uma aplicação Web Python nas Aplicações de Contentor do Azure. O Container Apps permite que você implante aplicativos em contêineres sem gerenciar uma infraestrutura complexa.

Nesta parte do tutorial, você aprenderá a configurar a implantação contínua ou a entrega (CD) para o aplicativo de contêiner. O CD faz parte da prática de DevOps de integração contínua / entrega contínua (CI/CD), que é a automação do seu fluxo de trabalho de desenvolvimento de aplicativos. Especificamente, você usa as Ações do GitHub para implantação contínua.

Este diagrama de serviço destaca os componentes abordados neste artigo: configuração de CI/CD.

Uma captura de tela dos serviços no Tutorial - Implantar um aplicativo Python em aplicativos de contêiner do Azure. As seções destacadas são partes relacionadas à integração contínua - entrega contínua (CI/CD).

Pré-requisitos

Para configurar a implantação contínua, você precisa:

  • Os recursos e sua configuração criados no artigo anterior desta série de tutoriais, que inclui um Registro de Contêiner do Azure e um aplicativo de contêiner em Aplicativos de Contêiner do Azure.

  • Uma conta do GitHub onde você bifurcou o código de exemplo (Django ou Flask) e pode se conectar a partir dos Aplicativos de Contêiner do Azure. (Se você baixou o código de exemplo em vez de bifurcar, certifique-se de enviar seu repositório local para sua conta do GitHub.)

  • Opcionalmente, o Git é instalado em seu ambiente de desenvolvimento para fazer alterações de código e enviar por push para seu repositório no GitHub. Como alternativa, você pode fazer as alterações diretamente no GitHub.

Configurar CD para um contêiner

Em um artigo anterior deste tutorial, você criou e configurou um aplicativo de contêiner em Aplicativos de Contêiner do Azure. Parte da configuração foi extrair uma imagem do Docker de um Registro de Contêiner do Azure. A imagem do contêiner é extraída do Registro ao criar uma revisão de contêiner, como quando você configurou o aplicativo de contêiner pela primeira vez.

Nesta seção, você configura a implantação contínua usando um fluxo de trabalho de Ações do GitHub. Com a implantação contínua, uma nova imagem do Docker e uma nova revisão de contêiner são criadas com base em um gatilho. O gatilho neste tutorial é qualquer alteração na ramificação principal do seu repositório, como com uma solicitação pull (PR). Quando acionado, o fluxo de trabalho cria uma nova imagem do Docker, envia-a por push para o Registro de Contêiner do Azure e atualiza o aplicativo de contêiner para uma nova revisão usando a nova imagem.

Os comandos da CLI do Azure podem ser executados no Azure Cloud Shell ou em uma estação de trabalho com a CLI do Azure instalada.

Se você estiver executando comandos em um shell Git Bash em um computador Windows, digite o seguinte comando antes de continuar:

export MSYS_NO_PATHCONV=1

Passo 1. Crie uma entidade de serviço com o comando az ad sp create-for-rbac.

az ad sp create-for-rbac \
--name <app-name> \
--role Contributor \
--scopes "/subscriptions/<subscription-ID>/resourceGroups/<resource-group-name>"

Em que:

  • <app-name> é um nome de exibição opcional para a entidade de serviço. Se você deixar de lado a --name opção, um GUID será gerado como o nome para exibição.
  • <subscription-ID> é o GUID que identifica exclusivamente sua assinatura no Azure. Se você não souber sua ID de assinatura, poderá executar o comando az account show e copiá-lo da id propriedade na saída.
  • <resource-group-name> é o nome de um grupo de recursos que contém o contêiner de Aplicativos de Contêiner do Azure. O controle de acesso baseado em função (RBAC) está no nível do grupo de recursos. Se você seguiu as etapas no artigo anterior deste tutorial, o nome do grupo de recursos é pythoncontainer-rg.

Salve a saída desse comando para a próxima etapa, em particular, a ID do cliente (appId propriedade), segredo do cliente (password propriedade) e ID do locatário (tenant propriedade).

Passo 2. Configure as ações do GitHub com o comando az containerapp github-action add .

az containerapp github-action add \
--resource-group <resource-group-name> \
--name python-container-app \
--repo-url <https://github.com/userid/repo> \
--branch main \
--registry-url <registry-name>.azurecr.io \
--service-principal-client-id <client-id> \
--service-principal-tenant-id <tenant-id> \
--service-principal-client-secret <client-secret> \
--login-with-github

Em que:

  • <resource-group-name> é o nome do grupo de recursos. Se você estiver seguindo este tutorial, é "pythoncontainer-rg".
  • <https://github.com/userid/repo> é a URL do seu repositório GitHub. Se você estiver seguindo as etapas deste tutorial, será ou https://github.com/userid/msdocs-python-django-azure-container-apps https://github.com/userid/msdocs-python-flask-azure-container-apps; onde userid está o seu ID de usuário do GitHub.
  • <registry-name> é o Registro de Contêiner existente que você criou para este tutorial, ou um que você pode usar.
  • <client-id> é o valor da appId propriedade do comando anterior az ad sp create-for-rbac . O ID é um GUID do formato 00000000-0000-0000-0000-00000000.
  • <tenant-id> é o valor da tenant propriedade do comando anterior az ad sp create-for-rbac . O ID também é um GUID semelhante ao ID do cliente.
  • <client-secret> é o valor da password propriedade do comando anterior az ad sp create-for-rbac .

Na configuração da implantação contínua, uma entidade de serviço é usada para permitir que as Ações do GitHub acessem e modifiquem os recursos do Azure. O acesso aos recursos é restrito pelas funções atribuídas à entidade de serviço. A entidade de serviço recebeu a função interna de Colaborador no grupo de recursos que contém o aplicativo contêiner.

Se você seguiu as etapas para o portal, a entidade de serviço foi criada automaticamente para você. Se você seguiu as etapas para a CLI do Azure, criou explicitamente a entidade de serviço primeiro antes de configurar a implantação contínua.

Reimplantar aplicativo Web com ações do GitHub

Nesta seção, você faz uma alteração na cópia bifurcada do repositório de exemplo e confirma se a alteração é implantada automaticamente no site.

Se ainda não o fez, faça uma bifurcação do repositório de amostras (Django ou Flask). Você pode fazer sua alteração de código diretamente no GitHub ou em seu ambiente de desenvolvimento a partir de uma linha de comando com o Git.

Passo 1. Vá para a bifurcação do repositório de amostras e comece na ramificação principal .

Captura de tela mostrando uma bifurcação do repositório de amostra e começando na ramificação principal.

Passo 2. Faça uma alteração.

  • Vá para o arquivo /templates/base.html . (Para Django, o caminho é: restaurant_review/templates/restaurant_review/base.html.)
  • Selecione Editar e altere a frase "Azure Restaurant Review" para "Azure Restaurant Review - Redeployed".

Captura de tela mostrando como fazer uma alteração em um arquivo de modelo na bifurcação do repositório de exemplo.

Passo 3. Confirme a alteração diretamente na ramificação principal .

  • Na parte inferior da página que você edita, selecione o botão Confirmar .
  • A confirmação inicia o fluxo de trabalho de Ações do GitHub.

Captura de tela mostrando como confirmar uma alteração em um arquivo de modelo na bifurcação do repositório de exemplo.

Nota

Mostramos fazer uma mudança diretamente no ramo principal . Em fluxos de trabalho de software típicos, você fará uma alteração em uma ramificação diferente da principal e, em seguida, criará uma solicitação pull (PR) para mesclar essas alterações na principal. As RPs também iniciam o fluxo de trabalho.

Acerca do GitHub Actions

Exibindo o histórico do fluxo de trabalho

Passo 1. No GitHub, vá para a bifurcação do repositório de exemplo e abra a guia Ações .

Captura de tela mostrando como visualizar as Ações do GitHub para um repositório e examinar fluxos de trabalho.

Segredos do fluxo de trabalho

No arquivo de fluxo de trabalho .github/workflows/<workflow-name>.yml que foi adicionado ao repositório, você verá espaços reservados para credenciais necessárias para os trabalhos de atualização de aplicativo de compilação e contêiner do fluxo de trabalho. As informações de credenciais são armazenadas criptografadas nas Configurações do repositório em Segredos de Segurança/e Ações de variáveis./

Captura de tela mostrando como ver onde os segredos das Ações do GitHub são armazenados no GitHub.

Se as informações de credenciais forem alteradas, você pode atualizá-las aqui. Por exemplo, se as senhas do Registro de Contêiner do Azure forem regeneradas, você precisará atualizar o valor REGISTRY_PASSWORD. Para obter mais informações, consulte Segredos criptografados na documentação do GitHub.

Aplicativos autorizados OAuth

Ao configurar a implantação contínua, você autoriza os Aplicativos de Contêiner do Azure como um Aplicativo OAuth autorizado para sua conta do GitHub. O Container Apps usa o acesso autorizado para criar um arquivo YML de ações do GitHub em .github/workflows/<workflow-name>.yml. Pode ver as suas aplicações autorizadas e revogar permissões em Aplicações de Integrações/da sua conta.

Captura de tela mostrando como ver os aplicativos autorizados para um usuário no GitHub.

Sugestões de resolução de problemas

Erros ao configurar uma entidade de serviço com o comando CLI az ad sp create-for-rba do Azure.

  • Você recebe um erro contendo "InvalidSchema: Nenhum adaptador de conexão foi encontrado".

  • Você recebe um erro contendo "Mais de um aplicativo tem o mesmo nome de exibição".

    • Este erro indica que o nome já foi utilizado para a entidade de serviço. Escolha outro nome ou deixe de lado o --name argumento e um GUID será gerado automaticamente como um nome para exibição.

Falha no fluxo de trabalho de Ações do GitHub.

  • Para verificar o status de um fluxo de trabalho, vá para a guia Ações do repositório.
  • Se houver um fluxo de trabalho com falha, analise detalhadamente seu arquivo de fluxo de trabalho. Deve haver dois trabalhos "build" e "deploy". Para um trabalho com falha, observe a saída das tarefas do trabalho para procurar problemas.
  • Se você vir uma mensagem de erro com "Tempo limite de handshake TLS", execute o fluxo de trabalho manualmente selecionando Acionar implantação automática na guia Ações do repositório para ver se o tempo limite é um problema temporário.
  • Se você configurar a implantação contínua para o aplicativo de contêiner, conforme mostrado neste tutorial, o arquivo de fluxo de trabalho (.github/workflows/<workflow-name>.yml) será criado automaticamente para você. Você não deve precisar modificar este arquivo para este tutorial. Se o fez, reverta as alterações e experimente o fluxo de trabalho.

O site não mostra as alterações que você mesclou na ramificação principal .

  • No GitHub: verifique se o fluxo de trabalho Ações do GitHub foi executado e se você verificou a alteração na ramificação que aciona o fluxo de trabalho.
  • No portal do Azure: verifique o Registro de Contêiner do Azure para ver se uma nova imagem do Docker foi criada com um carimbo de data/hora após sua alteração na ramificação.
  • No portal do Azure: verifique os logs do aplicativo de contêiner. Se houver um erro de programação, você o verá aqui.
    • Ir para a aplicação Container | Gestão de Revisões | <Contentor> ativo | Detalhes da revisão | Logs do console
    • Escolha a ordem das colunas para mostrar "Tempo gerado", "Stream_s" e "Log_s". Classifique os logs por mais recentes primeiro e procure por mensagens Python stderr e stdout na coluna "Stream_s". A saída de 'impressão' do Python será mensagens stdout .
  • Com a CLI do Azure, use o comando az containerapp logs show .

O que acontece quando desconecto a implantação contínua?

  • Interromper a implantação contínua significa desconectar seu aplicativo de contêiner do seu repositório. Para desligar:

  • Depois de desconectar, no seu repositório GitHub:

    • O arquivo .github/workflows/<workflow-name>.yml é removido do seu repositório.
    • As chaves secretas não são removidas.
    • Os Aplicativos de Contêiner do Azure permanecem como um Aplicativo OAuth autorizado para sua conta do GitHub.
  • Após a desconexão, no Azure:

    • O contêiner é deixado com o último contêiner implantado. Você pode reconectar o aplicativo de contêiner com o Registro de Contêiner do Azure, para que novas revisões de contêiner recebam a imagem mais recente.
    • As entidades de serviço criadas e usadas para implantação contínua não são excluídas.

Próximos passos

Se você terminou o tutorial e não quer incorrer em custos extras, remova os recursos usados. A remoção de um grupo de recursos remove todos os recursos do grupo e é a maneira mais rápida de remover recursos. Para obter um exemplo de como remover grupos de recursos, consulte Limpeza do tutorial Containerize.

Se você planeja desenvolver este tutorial, aqui estão algumas próximas etapas que você pode tomar.