Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo descreve como usar a plataforma de CI/CD (integração contínua e entrega contínua) no GitHub Actions para implantar um aplicativo Web Python no Serviço de Aplicativo do Azure no Linux. O fluxo de trabalho do GitHub Actions cria automaticamente o código e o implanta na instância do 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 de várias fases.
Criar repositório para o código do aplicativo
Para concluir os procedimentos neste artigo, você precisa de um aplicativo Web Python comprometido com um repositório GitHub.
Aplicativo existente: para usar um aplicativo Web Python existente, verifique se o aplicativo está comprometido com um repositório GitHub.
Novo aplicativo: se você precisar de um novo aplicativo Web Python, poderá bifurcar e clonar o https://github.com/Microsoft/python-sample-vscode-flask-tutorial repositório GitHub. O código de exemplo dá suporte ao tutorial do Flask no Visual Studio Code e fornece um aplicativo Python funcional.
Observação
Se o aplicativo usar o Django e um banco de dados SQLite , ele não funcionará para esses procedimentos. O SQLite não tem suporte na maioria dos ambientes hospedados na nuvem devido às limitações de armazenamento local baseadas em arquivo. Considere alternar para um banco de dados compatível com a nuvem, como o PostgreSQL ou o Azure Cosmos DB. Para obter mais informações, consulte examinar as considerações do Django mais adiante neste artigo.
Crie a instância dos Serviços de Aplicativos 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 Azure Cloud Shell interativo. O Cloud Shell inclui o Git e a CLI do Azure. No procedimento a seguir, você usa o comando az webapp up para criar a instância do Serviço de Aplicativo e fazer a implantação inicial do aplicativo.
Entre no Portal do Azure em https://portal.azure.com.
Abra a CLI do Azure selecionando a opção Cloud Shell na barra de ferramentas do portal:
No Cloud Shell, selecione a opção Bash no menu suspenso:
No Cloud Shell, clone seu repositório usando o comando git clone .
Dica
Para colar comandos ou texto no Cloud Shell, use o atalho de teclado Ctrl+Shift+V ou clique com o botão direito do mouse e selecione Colar no menu de contexto.
Para o aplicativo de exemplo Flask, você pode usar o comando a seguir. Substitua a
<github-user>parte pelo nome da conta do GitHub em que você bifurcava o repositório:git clone https://github.com/<github-user>/python-sample-vscode-flask-tutorial.gitSe o aplicativo estiver em um repositório diferente, configure o GitHub Actions para o repositório específico. Substitua a seção
<github-user>pelo nome da conta do GitHub onde você bifurcou o repositório e forneça o nome real do repositório no marcador<repo-name>.git clone https://github.com/<github-user>/<repo-name>.git
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 depois de concluir este artigo, juntamente com outros recursos criados.
No Cloud Shell, altere o diretório para a pasta do repositório para seu aplicativo Python, de modo que o comando az webapp up reconheça o aplicativo como Python. Para o aplicativo de exemplo do Flask, use o seguinte comando:
cd python-sample-vscode-flask-tutorialNo Cloud Shell, use o comando az webapp up para criar uma instância do Serviço de Aplicativo e fazer a implantação inicial para seu aplicativo:
az webapp up --name <app-service-name> --runtime "PYTHON:3.9"Para o placeholder
<app-service-name>, especifique um nome exclusivo para os Serviços de Aplicativos no Azure. O nome deve ter de 3 a 60 caracteres e pode conter apenas letras, números e hifens. O nome precisa começar com uma letra e terminar com uma letra ou um número.Para obter uma lista de runtimes disponíveis em seu sistema, use o
az webapp list-runtimescomando.Ao inserir o valor do runtime no comando, use o formato
PYTHON:X.Y, ondeX.Yé a versão principal e secundária do Python.Você também pode especificar o local da região da instância do Serviço de Aplicativo usando o
--locationparâmetro. Para obter uma lista de locais disponíveis, use oaz account list-locations --output tablecomando.
Se o aplicativo tiver um script de inicialização personalizado, use o comando az webapp config para iniciar o script.
Se o aplicativo não tiver um script de inicialização personalizado, prossiga para a próxima etapa.
Para o aplicativo de exemplo do Flask, você precisa acessar o script de inicialização no arquivo startup.txt executando o seguinte comando:
az webapp config set \ --resource-group <resource-group-name> \ --name <app-service-name> \ --startup-file startup.txtForneça o nome do grupo de recursos no espaço reservado
<resource-group-name>e o nome da instância do Serviço de Aplicativo no espaço reservado<app-service-name>. Para localizar o nome do grupo de recursos, verifique a saída do comando anterioraz webapp up. O nome do grupo de recursos inclui o nome da conta do Azure seguido pelo sufixo _rg , como em <azure-account-name>_rg_.
Para exibir o aplicativo em execução, abra um navegador e vá para o ponto de extremidade de implantação da instância do Serviço de Aplicativo. Na URL a seguir, substitua o placeholder
<app-service-name>pelo nome da instância do App Service.http://<app-service-name>.azurewebsites.netSe você vir uma página genérica, aguarde alguns segundos para que a instância do Serviço de Aplicativo seja iniciada e atualize a página.
- Se você continuar a ver uma página genérica, confirme que fez a implantação a partir da pasta correta.
- Para o aplicativo de exemplo do Flask, confirme se você implantou a partir da pasta python-sample-vscode-flask-tutorial. Verifique também se você definiu o comando de inicialização corretamente.
Configure a implantação contínua dos Serviços de Aplicativos
No próximo procedimento, você configura a entrega contínua (CD), o que significa que uma nova implantação de código ocorre sempre que um fluxo de trabalho é disparado. O gatilho no exemplo do artigo é qualquer alteração no branch principal do repositório, como uma solicitação de pull (PR).
No Cloud Shell, confirme se você está no diretório raiz do sistema (
~) e não em uma subpasta de aplicativo, como python-sample-vscode-flask-tutorial.Adicione o GitHub Actions com o comando az webapp deployment github-actions add . Substitua todos os espaços reservados por seus valores específicos:
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-githubO
--login-with-githubparâmetro usa um método interativo para recuperar um token de acesso pessoal. Siga os prompts e conclua a autenticação.Se o sistema encontrar um arquivo de fluxo de trabalho existente com o mesmo nome de instância do Serviço de Aplicativo, siga os prompts para escolher se deseja substituir o fluxo de trabalho. Você pode usar o
--forceparâmetro com o comando para substituir automaticamente quaisquer fluxos de trabalho conflitantes.
O
addcomando conclui as seguintes tarefas:- Cria um novo arquivo de fluxo de trabalho no caminho .github/workflows/<workflow-name>.yml em seu repositório. O nome do arquivo contém o nome da instância do Serviço de Aplicativo.
- Busca um perfil de publicação com segredos para sua instância dos Serviços de Aplicativos e o adiciona como um segredo de ação do GitHub. O nome do segredo começa com AZUREAPPSERVICE_PUBLISHPROFILE_. Esse segredo é referenciado no arquivo de fluxo de trabalho.
Obtenha os detalhes de uma configuração de implantação de controle do código-fonte com o comando az webapp deployment source show . Substitua os parâmetros de espaço reservado por seus valores específicos:
az webapp deployment source show \ --name <app-service-name> \ --resource-group <resource-group-name>Na saída do comando, confirme os valores para as propriedades
repoUrlebranch. Esses valores devem corresponder aos valores especificados com oaddcomando.
Examinar o fluxo de trabalho e as ações do GitHub
Uma definição de fluxo de trabalho é especificada em 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 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 e cada trabalho é um conjunto de etapas. Cada etapa é um script de shell ou uma ação. Cada trabalho tem uma seção Ação no arquivo de fluxo de trabalho.
Em termos do fluxo de trabalho configurado com seu código Python para implantação no Serviço de Aplicativo do Azure, o fluxo de trabalho tem as seguintes ações:
| Ação | Descrição |
|---|---|
| finalização de compra | Confira o repositório em um executor, um agente de ações do GitHub. |
| setup-python | Instale o Python no ambiente de execução. |
| appservice-build | Criar o aplicativo Web. |
| webapps-deploy | 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 é disparado em eventos de push para o branch especificado. O evento e o branch 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 é ativado em eventos de push para o branch main:
on:
push:
branches:
- main
Aplicativos autorizados do 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 YAML de ação do GitHub no caminho .github/workflows/<workflow-name>.yml no repositório.
Para ver seus aplicativos autorizados e revogar permissões em suas contas do GitHub, acesse Configurações>integrações/aplicativos:
Segredo do perfil de publicação do fluxo de trabalho
No .github/workflows/<workflow-name>.yml arquivo de fluxo de trabalho adicionado ao seu repositório, há um espaço reservado para as credenciais de perfil de publicação necessárias para o trabalho de implantação do fluxo de trabalho. As informações de perfil de publicação são armazenadas criptografadas no repositório.
Para exibir o segredo, vá para Configurações>Segurança>Segredo e variáveis>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 o OpenID Connect. Para obter mais informações, consulte Implantar no Serviço de Aplicativo usando o GitHub Actions.
Executar e testar fluxo de trabalho
A última etapa é testar o fluxo de trabalho fazendo uma alteração no repositório.
Em um navegador, acesse o seu fork do repositório de exemplo (ou o repositório que você utilizou) e selecione o branch que você definiu como parte do gatilho:
Faça uma pequena alteração em seu aplicativo Web Python.
Para o tutorial do Flask, aqui está uma alteração simples:
- Vá para o arquivo /hello-app/templates/home.html do branch de gatilho.
- Selecione Editar (lápis).
- No Editor, localize a instrução de impressão
<p>e adicione o texto "Reimplantado!"
Confirme a alteração diretamente no ramo em que você está trabalhando.
- No Editor, selecione Confirmar alterações na parte superior direita. A janela Confirmar alterações é aberta.
- Na janela Confirmar alterações , modifique a mensagem de confirmação conforme desejado e selecione Confirmar alterações.
O processo de confirmação dispara o fluxo de trabalho do GitHub Actions.
Você também pode disparar o fluxo de trabalho manualmente:
Vá para a aba Ações do repositório configurado para implantação contínua.
Selecione o fluxo de trabalho na lista de fluxos de trabalho e selecione Executar fluxo de trabalho.
Solucionar problemas em fluxos de trabalho com falhas
Você pode verificar o status de um fluxo de trabalho na guia Ações para o repositório do aplicativo. Ao examinar o arquivo de fluxo de trabalho criado neste artigo, você verá dois trabalhos: compilar e implantar. Como lembrete, o fluxo de trabalho é baseado no modelo Azure/actions-workflow-samples .
Para um trabalho com falha, examine a saída das tarefas de trabalho para obter uma indicação da falha.
Aqui estão alguns problemas comuns para investigar:
Se o aplicativo falhar devido a uma dependência ausente, o arquivo requirements.txt não foi processado durante a implantação. Esse comportamento ocorrerá se você criou o aplicativo Web diretamente no portal, em vez de usar o
az webapp upcomando, conforme mostrado neste artigo.Se você provisionou o serviço de aplicativo por meio do portal, a configuração da ação
SCM_DO_BUILD_DURING_DEPLOYMENTde compilação pode não estar definida. Essa configuração deve ser definida comotrue. Oaz webapp upcomando define a ação de build automaticamente.Se você vir uma mensagem de erro sobre "Tempo limite do handshake do TLS", execute o fluxo de trabalho manualmente selecionando Disparar implantação automática na guia Ações do repositório do aplicativo. Você pode determinar 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 artigo, o arquivo de fluxo de trabalho inicial .github/workflows/<workflow-name>.yml será criado automaticamente para você. Se você modificou o arquivo, remova as modificações para ver se elas estão causando a falha.
Execute um script pós-implantação
Um script pós-implantação pode concluir várias tarefas, como definir variáveis de ambiente esperadas pelo código do aplicativo. Adicione o script como parte do código do aplicativo e execute o script usando o comando de inicialização.
Para evitar a codificação fixa dos valores das variáveis em seu arquivo YAML de fluxo de trabalho, considere configurar as variáveis no GitHub e referir-se aos nomes das variáveis 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 Como usar segredos no GitHub Actions.
Revisar considerações sobre o Django
Conforme observado anteriormente neste artigo, você pode usar o GitHub Actions para implantar aplicativos Django no Serviço de Aplicativo do Azure no Linux, se você usar 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 , o que impede leituras e gravações. Esse comportamento não afeta um banco de dados externo.
O artigo configurar o aplicativo Python no Serviço de Aplicativo – Processo de inicialização de contêiner descreve como 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 webapp config set comando para definir o comando de inicialização, usou o --startup-file parâmetro para especificar o arquivo que contém o 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 startup-command parâmetro para especificar o comando de inicialização. Por exemplo, o 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 python manage.py migrate comando depois de implantar o código do aplicativo. Você pode executar o comando migrar em um script pós-implantação.
Desconectar GitHub Actions
Desconectar o GitHub Actions da instância do Serviço de Aplicativo permite que você reconfigure a implantação do aplicativo. Você pode escolher o que acontece com o arquivo de fluxo de trabalho depois de desconectar e se deseja salvar ou excluir o arquivo.
Desconecte o GitHub Actions usando o seguinte comando da CLI do Azure: az webapp deployment github-actions remove. Substitua todos os espaços reservados por seus valores específicos:
az webapp deployment github-actions remove \
--repo "<github-username>/<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 sobre os recursos do Azure criados neste artigo, exclua o grupo de recursos que contém a instância do Serviço de Aplicativo e o Plano do Serviço de Aplicativo.
Em qualquer lugar em que a CLI do Azure estiver instalada, incluindo o Azure Cloud Shell, você pode usar o comando az group delete para excluir um grupo de recursos:
az group delete --name <resource-group-name>
Excluir a conta de armazenamento
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.
Atualizar a conta e o repositório do GitHub
Se você excluir o grupo de recursos do Azure, considere fazer as seguintes modificações na conta do GitHub e repositório conectados para implantação contínua:
- No repositório de aplicativos, remova o arquivo .github/workflows/<workflow-name>.yml arquivo.
- Nas configurações do repositório de aplicativos, 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.

