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

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 há uma confirmação no repositório. Você pode adicionar outras automatizações em seu fluxo de trabalho de Ações do GitHub, 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 seu aplicativo

Se você já tiver um aplicativo Web Python para usar, certifique-se de que ele esteja comprometido com um repositório GitHub.

Se precisar de um aplicativo para trabalhar, você pode bifurcar 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.

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 interface de linha de comando (CLI) do Azure por meio do Azure Cloud Shell interativo. O Cloud Shell inclui o Git e a CLI do Azure. Nas etapas a seguir, você usará az webapp para criar o Serviço de Aplicativo e fazer a primeira implantação do seu aplicativo.

Passo 1. Inicie sessão no Portal do Azure em https://portal.azure.com.

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

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

Passo 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 é:

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.

Passo 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 Flask:

cd python-sample-vscode-flask-tutorial

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

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

Especifique um nome de Serviço de Aplicativo que seja exclusivo no Azure. O nome deve ter de 3 a 60 caracteres e pode conter apenas letras, números e hífenes. O nome deve começar com uma letra e terminar com uma letra ou 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 é 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.

Passo 7. Se seu aplicativo usa um comando de inicialização personalizado, use a configuração az webapp use esse comando. Se a sua aplicação não tiver um comando de arranque personalizado, ignore este passo.

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_.

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

Se vir uma página genérica, aguarde alguns segundos até que o Serviço de Aplicação inicie e atualize a página. Se continuar a ver a página genérica, verifique se implementou a partir da pasta correta. Por exemplo, se você estiver usando o aplicativo de exemplo Flask, a pasta é 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 seu repositório, como com uma solicitação pull (PR).

Passo 1. Adicione a ação do GitHub 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 esteja em conflito com o nome usado pelo Serviço de Aplicativo, 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.

Passo 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 explicados

Um fluxo de trabalho é definido por um arquivo YAML (.yml) no caminho /.github/workflows/ em seu repositório. Este 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 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:

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 nas 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 do GitHub é autenticada com uma credencial de perfil de publicação. Há outras maneiras de autenticar, como com uma entidade de serviço ou 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.

Passo 1. Vá para a bifurcação do repositório de exemplo (ou do repositório que você usou) e selecione a ramificação definida como parte do gatilho.

Passo 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!".

Passo 3. Confirme a alteração diretamente na filial 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.

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

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

Solução de 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 "build" e "deploy". Para um trabalho com falha, observe 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, seu arquivo .txt requisitos não foi processado durante a implantação. Esse comportamento acontece se você criou o aplicativo Web diretamente no portal em vez de usar o comando, az webapp up como 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 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 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 a codificação de valores de variáveis no arquivo YML do fluxo de trabalho, você pode substituí-los na interface da Web do GitHub e, em seguida, consultar o 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. Não é possível 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 wsgi.py no código do aplicativo, que normalmente contém o objeto do aplicativo. Quando você usou o comando para definir o comando de inicialização, 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 o comando depois de python manage.py migrate 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 seu arquivo de fluxo de trabalho depois de desconectar, se deseja salvar ou excluir o arquivo.

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

Clean up resources (Limpar recursos)

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

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 foi 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.