Usar CI/CD com GitHub Actions para implantar um aplicativo Web Python para Serviço de Aplicativo do Azure no Linux

Artigo
12/02/2024

Use a plataforma de integração contínua e entrega contínua (CI/CD) do GitHub Actions para implantar um aplicativo Web Python no Serviço de Aplicativo do Azure no Linux. Seu fluxo de trabalho de Ações do GitHub cria automaticamente o código e o implanta no Serviço de Aplicativo sempre que houver uma confirmação no repositório. Você pode adicionar outra automação ao fluxo de trabalho do GitHub Actions, como scripts de teste, verificações de segurança e implantação em vários estágios.

Criar um repositório para o código do aplicativo

Se você já tiver um aplicativo Web Python para usar, verifique se ele está confirmado em um repositório GitHub.

Se você precisar de um aplicativo com o qual trabalhar, poderá criar um fork e clonar o repositório em https://github.com/Microsoft/python-sample-vscode-flask-tutorial. O código é do tutorial Flask no Visual Studio Code.

Observação

Se o aplicativo usar o Django e um banco de dados SQLite, ele não funcionará para este tutorial. Se o seu aplicativo Django usa um banco de dados separado como PostgreSQL, você pode usá-lo com este tutorial. Para obter mais informações sobre o Django, consulte considerações sobre o Django mais adiante neste artigo.

Criar o Serviço de Aplicativo do Azure de destino

A maneira mais rápida de criar uma instância do Serviço de Aplicativo é usar a CLI (interface de linha de comando) do Azure por meio do Shell de Nuvem do Azure interativo. O Cloud Shell inclui o Git e a CLI do Azure. Nas etapas a seguir, você usará az webapp até para criar o Serviço de Aplicativo e fazer a primeira implantação do seu aplicativo.

Etapa 1. Entre no portal do Azure emhttps://portal.azure.com.

Etapa 2. Abra a CLI do Azure selecionando o ícone do Cloud Shell na barra de ferramentas do portal.

Etapa 3. No Cloud Shell, selecione Bash na lista suspensa.

Etapa 4. No Cloud Shell, clone seu repositório usando o git clone. Por exemplo, se você estiver usando o aplicativo de exemplo Flask, o comando será:

git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.git

Substitua <github-user> pelo nome da conta do GitHub onde você bifurcou o repositório. Se você estiver usando um repositório de aplicativo diferente, esse repositório é onde você configurará as Ações do GitHub.

Observação

O Cloud Shell é apoiado por uma conta de Armazenamento do Azure em um grupo de recursos chamado cloud-shell-storage-your-region<>. Essa conta de armazenamento contém uma imagem do sistema de arquivos do Cloud Shell, que armazena o repositório clonado. Há um pequeno custo para esse armazenamento. Você pode excluir a conta de armazenamento no final deste artigo, juntamente com outros recursos criados.

Dica

Para colar no Cloud Shell, use Ctrl+Shift+V ou clique com o botão direito do mouse e selecione Colar no menu de contexto.

Etapa 5. No Cloud Shell, altere o diretório para a pasta do repositório que tem seu aplicativo Python para que o comando az webapp up reconheça o aplicativo como Python. Por exemplo, para o aplicativo de exemplo Frasco:

cd python-sample-vscode-flask-tutorial

Etapa 6. No Cloud Shell, use az webapp up para criar um Serviço de Aplicativo e implantar inicialmente seu aplicativo.

az webapp up --name <app-service-name> --runtime "PYTHON:3.9"

Especifique um nome de Serviço de Aplicativo exclusivo no Azure. O nome deve ter de 3 a 60 caracteres e pode conter apenas letras, números e hífens. O nome precisa começar com uma letra e terminar com uma letra ou um número.

Use az webapp list-runtimes para obter uma lista de tempos de execução disponíveis. Use o PYTHON|X.Y formato, onde X.Y está a versão do Python.

Você também pode especificar o local do Serviço de Aplicativo com o --location parâmetro. Use o az account list-locations --output table comando para obter uma lista de locais disponíveis.

Etapa 7. Se seu aplicativo usa um comando de inicialização personalizado, use a configuração az webapp use esse comando. Se o seu aplicativo não tiver um comando de inicialização personalizado, ignore esta etapa.

Por exemplo, o aplicativo python-sample-vscode-flask-tutorial contém um arquivo chamado startup.txt que contém um comando de inicialização que você pode usar da seguinte maneira:

az webapp config set \
  --resource-group <resource-group-name> \
  --name <app-service-name> \
  --startup-file startup.txt

Você pode encontrar o nome do grupo de recursos na saída do comando anterior az webapp up . O nome do grupo de recursos começará com <azure-account-name>_rg_.

Etapa 8. Para ver o aplicativo em execução, abra um navegador e vá para http://< app-service-name.azurewebsites.net>.

Se você vir uma página genérica, aguarde alguns segundos até que o Serviço de Aplicativo seja iniciado e atualize a página. Se você continuar a ver a página genérica, verifique se você implantou a partir da pasta correta. Por exemplo, se você estiver usando o aplicativo de exemplo Flask, a pasta será python-sample-vscode-flask-tutorial. Além disso, para o aplicativo de exemplo Flask, verifique se você definiu o comando de inicialização corretamente.

Configurar a implantação contínua no Serviço de Aplicativo

Nas etapas abaixo, você configurará a implantação contínua (CD), o que significa que uma nova implantação de código acontece quando um fluxo de trabalho é acionado. O gatilho neste tutorial é qualquer alteração na ramificação principal do repositório, como com uma solicitação pull (PR).

Etapa 1. Adicione o GitHub Action com o comando az webapp deployment github-actions add .

az webapp deployment github-actions add \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

O --login-with-github parâmetro usa um método interativo para recuperar um token de acesso pessoal. Siga as instruções para concluir a autenticação.

Se houver um arquivo de fluxo de trabalho existente que entre em conflito com o nome que o Serviço de Aplicativo usa, você será solicitado a escolher se deseja substituir. Use o --force parâmetro para substituir sem perguntar.

O que o comando add faz:

Cria um novo arquivo de fluxo de trabalho: .github/workflows/<workflow-name.yml> em seu repositório, o nome do arquivo conterá o nome do seu Serviço de Aplicativo.
Busca um perfil de publicação com segredos para seu Serviço de Aplicativo e o adiciona como um segredo de ação do GitHub. O nome do segredo começará com AZUREAPPSERVICE_PUBLISHPROFILE_. Esse segredo é referenciado no arquivo de fluxo de trabalho.

Etapa 2. Obtenha os detalhes de uma configuração de implantação de controle de origem com o comando az webapp deployment source show .

az webapp deployment source show \
  --name <app-service-name> \
  --resource-group <resource-group-name>

Na saída do comando, confirme os valores para as repoUrl propriedades e branch . Esses valores devem corresponder aos valores especificados na etapa anterior.

Fluxo de trabalho e ações do GitHub explicadas

Um fluxo de trabalho é definido por um arquivo YAML (.yml) no caminho /.github/workflows/ em seu repositório. Esse arquivo YAML contém as várias etapas e parâmetros que compõem o fluxo de trabalho, um processo automatizado associado a um repositório do GitHub. Você pode criar, testar, empacotar, liberar e implantar qualquer projeto no GitHub com um fluxo de trabalho.

Cada fluxo de trabalho é composto por um ou mais trabalhos. Cada trabalho, por sua vez, é um conjunto de etapas. E, finalmente, cada etapa é um shell script ou uma ação.

Em termos do fluxo de trabalho configurado com seu código Python para implantação no Serviço de Aplicativo, o fluxo de trabalho tem as seguintes ações:

Ação	Descrição
caixa	Confira o repositório em um corredor, um agente do GitHub Actions.
setup-python	Instale o Python no runner.
Compilação do AppService	Criar o aplicativo Web.
webapps-implantar	Implante o aplicativo Web usando uma credencial de perfil de publicação para autenticar no Azure. A credencial é armazenada em um segredo do GitHub.

O modelo de fluxo de trabalho usado para criar o fluxo de trabalho é Azure/actions-workflow-samples.

O fluxo de trabalho é acionado em eventos de push para a ramificação especificada. O evento e a ramificação são definidos no início do arquivo de fluxo de trabalho. Por exemplo, o trecho de código a seguir mostra que o fluxo de trabalho é acionado em eventos de push para a ramificação principal :

on:
  push:
    branches:
    - main

Aplicativos autorizados OAuth

Ao configurar a implantação contínua, você autoriza o Serviço de Aplicativo do Azure como um Aplicativo OAuth autorizado para sua conta do GitHub. O Serviço de Aplicativo usa o acesso autorizado para criar um arquivo YML de ação do GitHub em .github/workflows/<workflow-name.yml>. Você pode ver seus aplicativos autorizados e revogar permissões em Configurações de suas contas do GitHub, em Integrações/Aplicativos.

Segredo do perfil de publicação do fluxo de trabalho

No arquivo de fluxo de trabalho .github/workflows/<workflow-name.yml> que foi adicionado ao repositório, você verá um espaço reservado para credenciais de perfil de publicação necessárias para o trabalho de implantação do fluxo de trabalho. As informações do perfil de publicação são armazenadas criptografadas nas Configurações do repositório, em Segurança/Ações.

Neste artigo, a ação GitHub autentica com uma credencial de perfil de publicação. Há outras maneiras de autenticar, como com uma entidade de serviço ou o OpenID Connect. Para obter mais informações, consulte Implantar no Serviço de Aplicativo usando ações do GitHub.

Executar o fluxo de trabalho

Agora você testará o fluxo de trabalho fazendo uma alteração no repositório.

Etapa 1. Vá para o fork do repositório de amostra (ou o repositório usado) e selecione a ramificação definida como parte do gatilho.

Etapa 2. Faça uma pequena alteração.

Por exemplo, se você usou o tutorial VS Code Flask, você pode

Vá para o arquivo /hello-app/templates/home.html da ramificação do gatilho.
Selecione Editar e adicione o texto "Reimplantado!".

Etapa 3. Confirme a alteração diretamente na ramificação em que você está trabalhando.

No canto superior direito da página que você está editando, selecione o botão Confirmar alterações... . A janela Confirmar alterações é aberta. Na janela Confirmar alterações, modifique a mensagem de confirmação, se desejado, e selecione o botão Confirmar alterações.
A confirmação inicia o fluxo de trabalho de Ações do GitHub.

Você também pode iniciar o fluxo de trabalho manualmente.

Etapa 1. Vá para a guia Ações do repositório configurado para implantação contínua.

Etapa 2. Selecione o fluxo de trabalho na lista de fluxos de trabalho e, em seguida, selecione Executar fluxo de trabalho.

Solucionando problemas de um fluxo de trabalho com falha

Para verificar o status de um fluxo de trabalho, vá para a guia Ações do repositório. Ao detalhar o arquivo de fluxo de trabalho criado neste tutorial, você verá dois trabalhos "compilar" e "implantar". Para um trabalho com falha, examine a saída das tarefas de trabalho para obter uma indicação da falha. Alguns problemas comuns são:

Se o aplicativo falhar devido a uma dependência ausente, o arquivo .txt requisitos não foi processado durante a implantação. Esse comportamento ocorrerá se você tiver criado o aplicativo Web diretamente no portal, em vez de usar o comando az webapp up, conforme mostrado neste artigo.
Se você provisionou o serviço de aplicativo por meio do portal, a configuração de SCM_DO_BUILD_DURING_DEPLOYMENT de ação de compilação pode não ter sido definida. Essa configuração deve ser definida como true. O az webapp up comando define a ação de compilação automaticamente.
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á inicialmente criado automaticamente para você. Se você o modificou, remova as modificações para ver se elas estão causando a falha.

Executar um script pós-implantação

Um script pós-implantação pode, por exemplo, definir as variáveis de ambiente esperadas pelo código do aplicativo. Adicione o script como parte do código do aplicativo e execute-o usando o comando de inicialização.

Para evitar valores de variáveis codificados no arquivo YML do fluxo de trabalho, você pode usá-los na interface da Web do GitHub e, em seguida, fazer referência ao nome da variável no script. Você pode criar segredos criptografados para um repositório ou para um ambiente (repositório de conta). Para obter mais informações, consulte Segredos criptografados no GitHub Docs.

Considerações para Django

Conforme observado anteriormente neste artigo, você pode usar as Ações do GitHub para implantar aplicativos Django no Serviço de Aplicativo do Azure no Linux, se estiver usando um banco de dados separado. Você não pode usar um banco de dados SQLite porque o Serviço de Aplicativo bloqueia o arquivo db.sqlite3, impedindo leituras e gravações. Esse comportamento não afeta um banco de dados externo.

Conforme descrito no artigo Configurar aplicativo Python no Serviço de Aplicativo - Processo de inicialização de contêiner, o Serviço de Aplicativo procura automaticamente um arquivo de wsgi.py no código do aplicativo, que normalmente contém o objeto do aplicativo. Ao usar o comando para definir o comando startup, você usou o parâmetro para especificar o arquivo que contém o webapp config set --startup-file objeto do aplicativo. O webapp config set comando não está disponível na ação webapps-deploy. Em vez disso, você pode usar o parâmetro para especificar o startup-command comando de inicialização. Por exemplo, o trecho de código a seguir mostra como especificar o comando de inicialização no arquivo de fluxo de trabalho:

startup-command: startup.txt

Ao usar o Django, você normalmente deseja migrar os modelos de dados usando python manage.py migrate o comando depois de implantar o código do aplicativo. Você pode executar o comando migrate em um script pós-implantação.

Desconectar ações do GitHub

Desconectar as Ações do GitHub do Serviço de Aplicativo permite reconfigurar a implantação do aplicativo. Você pode escolher o que acontece com o arquivo de fluxo de trabalho depois de se desconectar, se deseja salvar ou excluir o arquivo.

CLI do Azure
Portal do Azure

Desconectar ações do GitHub com a CLI do Azure az webapp deployment github-actions remove command.

az webapp deployment github-actions remove \
  --repo "<github-user>/<github-repo>" \
  --resource-group <resource-group-name> \
  --branch <branch-name> \
  --name <app-service-name> \
  --login-with-github

Limpar os recursos

Para evitar incorrer em encargos nos recursos do Azure criados neste tutorial, exclua o grupo de recursos que contém o Serviço de Aplicativo e o Plano de Serviço de Aplicativo.

CLI do Azure
Portal do Azure

Em qualquer lugar onde a CLI do Azure esteja instalada, incluindo o Azure Cloud Shell, você pode usar o comando az group delete para excluir o grupo de recursos.

az group delete --name <resource-group-name>

Para excluir a conta de armazenamento que mantém o sistema de arquivos do Cloud Shell, que incorre em uma pequena cobrança mensal, exclua o grupo de recursos que começa com cloud-shell-storage-. Se você for o único usuário do grupo, é seguro excluir o grupo de recursos. Se houver outros usuários, você poderá excluir uma conta de armazenamento no grupo de recursos.

Se você excluiu o grupo de recursos do Azure, considere também fazer as seguintes modificações na conta do GitHub e no repositório que estava conectado para implantação contínua:

No repositório, remova o arquivo .github/workflows/<workflow-name.yml>.
Nas configurações do repositório, remova a chave secreta AZUREAPPSERVICE_PUBLISHPROFILE_ criada para o fluxo de trabalho.
Nas configurações da conta do GitHub, remova o Serviço de Aplicativo do Azure como um Aplicativo Oauth autorizado para sua conta do GitHub.

Compartilhar via