Configurar um aplicativo Python do Linux para o Serviço de Aplicativo do Azure

Este artigo descreve como o Serviço de Aplicativo do Azure executa os aplicativos Python, como você pode migrar os aplicativos existentes para o Azure e como você pode personalizar o comportamento do Serviço de Aplicativo quando for necessário. Os aplicativos Python precisam ser implantados com todos os módulos pip necessários.

O mecanismo de implantação do Serviço de Aplicativo ativa automaticamente um ambiente virtual e executa pip install -r requirements.txt para você ao implantar um repositório Git, ou quando você implanta um pacote zip com a automação de compilação habilitada.

Este guia fornece conceitos e instruções essenciais para desenvolvedores do Python que usam um contêiner interno do Linux no Serviço de Aplicativo. Caso nunca tenha usado o Serviço de Aplicativo do Azure, primeiro siga o Início rápido do Python e o Tutorial do Python com o PostgreSQL.

Será possível usar o portal do Azure ou a CLI do Azure para executar a configuração:

• Portal do Azure, use a página de Configurações>de Configuração do aplicativo, conforme descrito em Configurar um aplicativo do Serviço de Aplicativo no portal do Azure.

• CLI do Azure: você tem duas opções.

  • Executar os comandos no Azure Cloud Shell.
  • Executar comandos localmente instalando a versão mais recente da CLI do Azure e entrar no Azure usando o comando az login.

Configurar a versão do Python

• Portal do Azure: use a guia Configurações gerais na página Configuração, conforme descrito em Definir as configurações gerais nos contêineres do Linux.

• CLI do Azure:

  • Mostre a versão atual do Python com o az webapp config show:

    az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion
    

    Substitua <resource-group-name> e <app-name> pelos nomes apropriados para seu aplicativo Web.

  • Defina a versão do Python com o az webapp config set

    az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PYTHON|3.11"
    

  • Mostre todas as versões do Python compatíveis com o Serviço de Aplicativo do Azure com o az webapp list-runtimes:

    az webapp list-runtimes --os linux | grep PYTHON
    

Você pode executar uma versão sem suporte do Python criando sua própria imagem de contêiner em vez disso. Para obter mais informações, confira Usar uma imagem do Docker personalizada.

Personalizar a automação de build

O sistema de compilação do Serviço de Aplicativo, chamado Oryx, executará as seguintes etapas quando você implantar seu aplicativo se suas configurações SCM_DO_BUILD_DURING_DEPLOYMENT estiverem definidas como 1:

1. Execute um script personalizado de pré-compilação caso essa etapa seja especificada pela configuração PRE_BUILD_COMMAND. (O script pode, por si só, executar outros scripts Python e Node.js, comandos do Pip e do npm e ferramentas baseadas em Node como o Yarn, por exemplo, yarn install e yarn build.)

2. Execute pip install -r requirements.txt. O arquivo requirements.txt deverá estar presente na pasta raiz do projeto. Caso contrário, o processo de compilação relatará o seguinte erro: "Não foi possível localizar o setup.py nem o requirements.txt. A instalação de PIP não está sendo executada."

3. Caso o manage.py seja encontrado na raiz do repositório (indicando um aplicativo Django), execute o manage.py collectstatic. No entanto, caso a configuração de DISABLE_COLLECTSTATIC seja true, essa etapa será ignorada.

4. Execute um script personalizado de pós-compilação caso essa etapa seja especificada pela configuração POST_BUILD_COMMAND. (Novamente, o script pode executar outros scripts Python e Node.js, comandos do Pip e do npm e ferramentas baseadas em Node.)

Por padrão, as configurações PRE_BUILD_COMMAND, POST_BUILD_COMMAND e DISABLE_COLLECTSTATIC estarão vazias.

• Para desabilitar a execução de collectstatic ao criar aplicativos Django, defina a configuração DISABLE_COLLECTSTATIC como true.

• Para executar os comandos de pré-compilação, defina a configuração PRE_BUILD_COMMAND para conter um comando, como o echo Pre-build command, ou um caminho para um arquivo de script relativo à raiz do projeto, como o scripts/prebuild.sh. Todos os comandos deverão usar caminhos relativos para a pasta raiz do projeto.

• Para executar os comandos de pós-compilação, defina a configuração POST_BUILD_COMMAND para conter um comando, como o echo Post-build command, ou um caminho para um arquivo de script relativo à raiz do projeto, como o scripts/postbuild.sh. Todos os comandos deverão usar caminhos relativos para a pasta raiz do projeto.

Para obter configurações adicionais que personalizam a automação de build, confira Configuração do Oryx.

Para acessar os logs de criação e implantação, confira Acessar logs de implantação.

Para obter mais informações sobre como o Serviço de Aplicativo executa e cria aplicativos Python no Linux, confira Como o Oryx detecta e cria aplicativos Python.

Migrar aplicativos existentes para o Azure

Os aplicativos Web existentes podem ser reimplantados para o Azure da seguinte maneira:

1. Repositório de origem: mantenha seu código-fonte em um repositório adequado, como o GitHub, que permite configurar a implantação contínua posteriormente neste processo.

   • O arquivo requirements.txt precisa estar na raiz do seu repositório para que o Serviço de Aplicativo instale automaticamente os pacotes necessários.

2. Banco de dados: se seu aplicativo depende de um banco de dados, crie os recursos necessários no Azure também.

3. Recursos do serviço de aplicativo: criar um grupo de recursos, um plano do Serviço de Aplicativo e um aplicativo Web do Serviço de Aplicativo para hospedar seu aplicativo. Você pode fazer isso facilmente executando o comando da CLI do Azure az webapp up. Ou, você pode criar e implantar recursos, conforme mostrado no Tutorial: implantar um aplicativo Web Python (Django ou Flask) com PostgreSQL. Substitua os nomes do grupo de recursos, do plano do Serviço de Aplicativo e do aplicativo Web para serem mais adequados para seu aplicativo.

4. Variáveis de ambiente: se seu aplicativo exigir variáveis de ambiente, crie configurações do aplicativo do Serviço de Aplicativo equivalentes. Essas configurações do Serviço de Aplicativo aparecem para seu código como variáveis de ambiente, conforme descrito em Acessar variáveis de ambiente.

   • As conexões de banco de dados, por exemplo, são geralmente gerenciadas por meio dessas configurações, conforme mostrado no Tutorial: Implantar um aplicativo Web Django com PostgreSQL – verificar as configurações de conexão.
   • Confira Configurações de produção para aplicativos Django para obter configurações específicas para aplicativos Django típicos.

5. Inicialização de aplicativo: examine a seção Processo de inicialização do contêiner mais adiante neste artigo para entender como o Serviço de Aplicativo tenta executar seu aplicativo. O Serviço de Aplicativo usa o servidor Web Gunicorn por padrão, que precisa ter a capacidade de localizar seu objeto de aplicativo ou a pasta wsgi.py. Se precisar, você poderá Personalizar o comando de inicialização.

6. Implantação contínua: configure a implantação contínua do GitHub Actions, Bitbucket ou Azure Repos conforme descrito no artigo Implantação contínua no Serviço de Aplicativo do Azure. Ou configure a implantação contínua do Git Local, conforme descrito no artigo Implantação do Git local no Serviço de Aplicativo do Azure.

7. Ações personalizadas: para executar ações no contêiner do Serviço de Aplicativo que hospeda seu aplicativo, como migrações do banco de dados Django, você pode conectar-se ao contêiner por meio de SSH. Para obter um exemplo de como executar migrações do banco de dados Django, confira Tutorial: Implantar um aplicativo Web Django com PostgreSQL – gerar esquema de banco de dados.

   • Ao usar a implantação contínua, você pode executar essas ações usando comandos pós-build conforme descrito anteriormente em Personalizar a automação de build.

Com essas etapas concluídas, você deve poder confirmar as alterações no repositório de origem e fazer com que essas atualizações sejam implantadas automaticamente no Serviço de Aplicativo.

Configurações de produção para aplicativos Django

Quanto a um ambiente de produção como o Serviço de Aplicativo do Azure, os aplicativos Django devem seguir a Lista de verificação de implantação do Django.

A tabela a seguir descreverá configurações de produção relevantes para o Azure. Essas configurações serão definidas no arquivo setting.py do aplicativo.

Fornecer arquivos estáticos para aplicativos Django

Se seu aplicativo Web Django incluir arquivos de front-end estáticos, primeiro siga as instruções sobre gerenciamento de arquivos estáticos na documentação do Django.

Para o Serviço de Aplicativo, faça as seguintes modificações:

1. Considere o uso de variáveis de ambiente (para desenvolvimento local) e Configurações de Aplicativo (na implantação na nuvem) para definir dinamicamente as variáveis STATIC_URL e STATIC_ROOT do Django. Por exemplo:

   STATIC_URL = os.environ.get("DJANGO_STATIC_URL", "/static/")
   STATIC_ROOT = os.environ.get("DJANGO_STATIC_ROOT", "./static/")    
   

   DJANGO_STATIC_URL e DJANGO_STATIC_ROOT podem ser alterados conforme necessário para seus ambientes locais e de nuvem. Por exemplo, se o processo de build dos arquivos estáticos os colocar em uma pasta chamada django-static, você poderá definir DJANGO_STATIC_URL como /django-static/ para evitar o uso do padrão.

2. Caso você tenha um script de pré-build que gera arquivos estáticos em outra pasta, inclua essa pasta na variável STATICFILES_DIRS do Django para que o processo collectstatic do Django os encontre. Por exemplo, se você executar yarn build na pasta de front-end e o Yarn gerar uma pasta build/static contendo arquivos estáticos, inclua essa pasta da seguinte maneira:

   FRONTEND_DIR = "path-to-frontend-folder" 
   STATICFILES_DIRS = [os.path.join(FRONTEND_DIR, 'build', 'static')]    
   

   Aqui, FRONTEND_DIR é usado para criar um caminho para onde uma ferramenta de compilação como o Yarn é executada. Use novamente uma variável de ambiente e uma Configuração de Aplicativo, conforme desejado.

3. Adicione whitenoise ao arquivo requirements.txt. O WhiteNoise (whitenoise.evans.io) é um pacote do Python que simplifica um aplicativo Django de produção para servir seus próprios arquivos estáticos. O WhiteNoise serve especificamente os arquivos encontrados na pasta especificada pela variável STATIC_ROOT do Django.

4. No seu arquivo settings.py, adicione a seguinte linha ao WhiteNoise:

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Além disso, modifique as listas MIDDLEWARE e INSTALLED_APPS para incluir o WhiteNoise:

   MIDDLEWARE = [                                                                   
       'django.middleware.security.SecurityMiddleware',
       # Add whitenoise middleware after the security middleware                             
       'whitenoise.middleware.WhiteNoiseMiddleware',
       # Other values follow
   ]
   
   INSTALLED_APPS = [
       "whitenoise.runserver_nostatic",
       # Other values follow
   ]
   

Fornecer arquivos estáticos para aplicativos Flask

Se o seu aplicativo Web Flask tiver arquivos estáticos front-end, primeiro, siga as instruções em Como gerenciar arquivos estáticos na documentação do Flask. Para obter um exemplo de como servir arquivos estáticos em um aplicativo Flask, consulte o aplicativo Flask de exemplo no GitHub.

Para fornecer arquivos estáticos diretamente de uma rota em seu aplicativo, você pode usar o método send_from_directory:

from flask import send_from_directory

@app.route('/reports/<path:path>')
def send_report(path):
    return send_from_directory('reports', path)

Características do contêiner

Quando implantados no Serviço de Aplicativo, os aplicativos Python são executados em um contêiner do Linux Docker definido no repositório GitHub do Serviço de Aplicativo do Python. Você pode encontrar as configurações de imagem nos diretórios específicos da versão.

Esse contêiner tem as seguintes características:

• Aplicativos são executados usando o Gunicorn WSGI HTTP Server com os argumentos adicionais --bind=0.0.0.0 --timeout 600.

  • Você pode fornecer configurações para o Gunicorn personalizando o comando de inicialização.

  • Para proteger seu aplicativo Web contra ataques DDOS acidentais ou deliberados, o Gunicorn é executado através de um proxy reverso do Nginx, conforme descrito em Implantando o Gunicorn.

• Por padrão, uma imagem de contêiner base inclui somente a estrutura Web do Flask, porém o contêiner é compatível com outras estruturas em conformidade com WSGI e compatíveis com o Python 3.6+, como o Django.

• Para instalar outros pacotes, como o Django, crie um arquivo requirements.txt na raiz do projeto que especificará as dependências diretas. O Serviço de Aplicativo instalará essas dependências de maneira automática quando você implantar o projeto.

  O arquivo requirements.txtdeverá estar na raiz do projeto para que as dependências sejam instaladas. Caso contrário, o processo de build relata o erro: "Não foi possível encontrar setup.py ou requirements.txt. A instalação do pip não está sendo executada". Se você encontrar esse erro, verifique o local do arquivo de requisitos.

• O Serviço de Aplicativo definirá de maneira automática uma variável de ambiente chamada WEBSITE_HOSTNAME com a URL do aplicativo Web, como msdocs-hello-world.azurewebsites.net. Ele também definirá WEBSITE_SITE_NAME com o nome do seu aplicativo, como msdocs-hello-world.

• O npm e o Node.js são instalados no contêiner de modo que você possa executar ferramentas de build baseadas em Node, como o Yarn.

Processo de inicialização do contêiner

Durante a inicialização, o Serviço de Aplicativo no contêiner do Linux executa as seguintes etapas:

1. Use um comando de inicialização personalizada, se for fornecido.
2. Verifique a existência de um aplicativo Django e inicie o Gunicorn para ele se for detectado.
3. Verifique a existência de um aplicativo Flaske inicie o Gunicorn para ele se for detectado.
4. Se nenhum outro aplicativo for encontrado, inicie um aplicativo padrão criado no contêiner.

As seções a seguir fornecem detalhes adicionais para cada opção.

Aplicativo do Django

Para aplicativos Django, o Serviço de Aplicativo procura um arquivo chamado wsgi.py dentro de seu código do aplicativo e, em seguida, executa Gunicorn usando o seguinte comando:

# <module> is the name of the folder that contains wsgi.py
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Caso queira obter um controle mais específico sobre o comando de inicialização, use um comando de inicialização personalizado, substitua o <module> pelo nome da pasta que contém o wsgi.py e adicione um argumento --chdir, caso esse módulo não esteja na raiz do projeto. Por exemplo, caso o wsgi.py esteja localizado em knboard/back-end/config na raiz do projeto, use os argumentos --chdir knboard/backend config.wsgi.

Para habilitar o log de produção, adicione os parâmetros --access-logfile e --error-logfile, conforme mostrado nos exemplos de comandos de inicialização personalizados.

Aplicativo do Flask

Para Flask, o Serviço de Aplicativo procura um arquivo chamado application.py ou app.py e inicia Gunicorn da seguinte maneira:

# If application.py
gunicorn --bind=0.0.0.0 --timeout 600 application:app

# If app.py
gunicorn --bind=0.0.0.0 --timeout 600 app:app

Se o módulo principal do seu aplicativo estiver contido em um arquivo diferente, use um nome diferente para o objeto do aplicativo. Se você quiser fornecer outros argumentos ao Gunicorn, use um comando de inicialização personalizado.

Comportamento padrão

Se o Serviço de Aplicativo não encontrar um aplicativo Flask, um aplicativo Django ou um comando personalizado, ele executará um aplicativo padrão somente leitura, localizado na pasta opt/defaultsite e mostrado na imagem a seguir.

Se você implantou o código e ainda vê o aplicativo padrão, confira Solução de problemas – O aplicativo não aparece.

Personalizar o comando de inicialização

Você pode controlar o comportamento de inicialização do contêiner fornecendo um comando de inicialização personalizado ou vários comandos em um arquivo de comandos de inicialização. Um arquivo de comandos de inicialização poderá usar qualquer nome que você escolher, como startup.sh, startup.cmd, startup.txt e assim por diante.

Todos os comandos deverão usar caminhos relativos para a pasta raiz do projeto.

Para especificar um comando de inicialização ou um arquivo de comandos:

• Portal do Azure: selecione a página de Configuração do aplicativo e clique em Configurações gerais. No campo Comando de Inicialização, coloque o texto completo do comando de inicialização ou o nome do arquivo de comandos de inicialização. Depois clique em Salvar para aplicar as alterações. Confira Definir configurações gerais para contêineres do Linux.

• CLI do Azure: use o comando az webapp config set com o parâmetro --startup-file para definir o arquivo ou comando de inicialização:

  az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"
  

  Substitua <custom-command> pelo texto completo do comando de inicialização ou nome do arquivo de comandos de inicialização.

O Serviço de Aplicativo ignorará todos os erros que ocorrerem no processamento de um arquivo ou comando personalizado de inicialização, depois ele continuará o processo de inicialização procurando por aplicativos Django e Flask. Caso não veja o comportamento esperado, verifique se o arquivo ou comando de inicialização está isento de erros e se um arquivo de comandos de inicialização foi implantado no Serviço de Aplicativo juntamente com o código do aplicativo. Você também pode verificar os logs de diagnóstico para obter mais informações. Verifique também a página Diagnosticar e resolver problemas do aplicativo no portal do Azure.

Exemplos de comandos de inicialização

• Argumentos do Gunicorn adicionados: o exemplo a seguir adiciona o argumento --workers=4 a uma linha de comando do Gunicorn para iniciar um aplicativo Django:

  # <module-path> is the relative path to the folder that contains the module
  # that contains wsgi.py; <module> is the name of the folder containing wsgi.py.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi
  

  Para obter mais informações, consulte Running Gunicorn. Se você estiver usando regras de dimensionamento automático para dimensionar ou reduzir verticalmente seu aplicativo Web, também deverá definir dinamicamente o número de trabalhos com o Gunicorn usando a variável de ambiente NUM_CORES no seu comando de inicialização, por exemplo: --workers $((($NUM_CORES*2)+1)). Para obter mais informações sobre como definir o número recomendado de trabalhadores do Gunicorn, consulte Perguntas frequentes sobre o Gunicorn.

• Habilitar o log de produção para o Django: adicione os argumentos --access-logfile '-' e --error-logfile '-' à linha de comando:

  # '-' for the log files means stdout for --access-logfile and stderr for --error-logfile.
  gunicorn --bind=0.0.0.0 --timeout 600 --workers=4 --chdir <module_path> <module>.wsgi --access-logfile '-' --error-logfile '-'
  

  Esses logs aparecerão no fluxo de log do Serviço de Aplicativo.

  Para obter mais informações, consulte Registro em log do Gunicorn.

• Módulo principal do Flask personalizado: por padrão, o Serviço de Aplicativo pressupõe que o módulo principal de um aplicativo Flask será application.py ou app.py. Caso o módulo principal use um nome diferente, você deverá personalizar o comando de inicialização. Por exemplo, se você tiver um aplicativo Flask cujo módulo principal seja hello.py e o objeto de aplicativo nesse arquivo tenha o nome myapp, o comando será assim:

  gunicorn --bind=0.0.0.0 --timeout 600 hello:myapp
  

  Se seu módulo principal estiver em uma subpasta, como website, especifique a pasta com o --chdir argumento:

  gunicorn --bind=0.0.0.0 --timeout 600 --chdir website hello:myapp
  

• Usar um servidor que não seja do Gunicorn: para usar um servidor Web diferente, como aiohttp, use o comando apropriado como o comando de inicialização ou no arquivo de comandos de inicialização:

  python3.7 -m aiohttp.web -H localhost -P 8080 package.module:init_func
  

Acessar configurações de aplicativos como variáveis de ambiente

As configurações do aplicativo são valores armazenados na nuvem especificamente para seu aplicativo, conforme descrito em Definir configurações de aplicativo. Essas configurações estão disponíveis para o código do aplicativo como variáveis de ambiente e podem ser acessadas usando o padrão os.environ.

Por exemplo, se você criou uma configuração de aplicativo chamada DATABASE_SERVER, o código a seguir recuperará o valor dessa configuração:

db_server = os.environ['DATABASE_SERVER']

Detectar sessão HTTPS

No Serviço de Aplicativo, a terminação TLS/SSL ocorre nos balanceadores de carga de rede, de modo que todas as solicitações HTTPS chegam ao seu aplicativo como solicitações HTTP não criptografadas. Se a lógica de aplicativo precisar verificar se as solicitações do usuário estão criptografadas ou não, inspecione o cabeçalho X-Forwarded-Proto.

if 'X-Forwarded-Proto' in request.headers and request.headers['X-Forwarded-Proto'] == 'https':
# Do something when HTTPS is used

Estrutura Web populares permitem que você acesse informações do X-Forwarded-* no seu padrão de aplicativo básico. Por exemplo, no Django, você pode usar o SECURE_PROXY_SSL_HEADER para dizer ao Django para usar o cabeçalho X-Forwarded-Proto.

Acessar logs de diagnóstico

Você pode acessar os logs do console gerados de dentro do contêiner.

Primeiro, ative o log do contêiner executando o seguinte comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Substitua <app-name> e <resource-group-name> pelos nomes apropriados para seu aplicativo Web.

Depois que o log do contêiner estiver ativado, execute o seguinte comando para ver o fluxo de log:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Se você não vir os logs do console imediatamente, verifique novamente após 30 segundos.

Para interromper o streaming de log a qualquer momento, digite Ctrl+C.

Você também pode inspecionar os arquivos de log em um navegador em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para acessar logs por meio do portal do Azure, selecione Monitoramento>Fluxo de log no menu do lado esquerdo do aplicativo.

Acessar logs de implantação

Quando você implanta seu código, o Serviço de Aplicativo executa o processo de build descrito anteriormente na seção Personalizar automação do build. Como o build é executado em um contêiner próprio, os logs de build são armazenados separadamente dos logs de diagnóstico do aplicativo.

Use as seguintes etapas para acessar os logs de implantação:

1. No portal do Azure para seu aplicativo Web, selecione Implantação>Centro de Implantação no menu à esquerda.
2. Na guia Logs, selecione a ID de Confirmação para a confirmação mais recente.
3. Na página Detalhes do Log exibida, selecione o link Mostrar Logs exibido ao lado de "Executando a compilação oryx...".

Problemas de build, como dependências incorretas em requirements.txt e erros nos scripts pré ou pós-build aparecerão nesses logs. Os erros também aparecerão se seu arquivo de requisitos não estiver nomeado como requirements.txt ou não aparecer na pasta raiz do seu projeto.

Abra a sessão SSH aberta no navegador

Para abrir uma sessão SSH direta com seu contêiner, seu aplicativo deve estar em execução.

Cole a seguinte URL no seu navegador e substitua <app-name> pelo nome do aplicativo:

https://<app-name>.scm.azurewebsites.net/webssh/host

Se você ainda não estiver autenticado, será necessário autenticar com sua assinatura do Azure para se conectar. Uma vez autenticado, consulte um shell no navegador, onde você pode executar comandos dentro de seu contêiner.

Para abrir uma sessão SSH remota no seu computador local, consulte Abrir a sessão SSH no shell remoto.

Quando você se conectar com sucesso à sessão SSH, deverá ver a mensagem "SSH CONNECTION ESTABLISHED", na parte inferior da janela. Se você vir erros como "SSH_CONNECTION_CLOSED" ou uma mensagem informando que o contêiner será reiniciado, poderá haver um erro impedindo que o contêiner do aplicativo seja iniciado. Confira a Solução de problemas a fim de obter as etapas para investigar possíveis problemas.

Regravações de URL

Ao implantar aplicativos Python no Serviço de Aplicativo do Azure para Linux, é possível que você precise lidar com regravações de URL no seu aplicativo. Isso é particularmente útil para garantir que padrões de URL específicos sejam redirecionados para os pontos de extremidade corretos sem depender das configurações externas do servidor Web. Para aplicativos Flask, os processadores de URL e o middleware personalizado podem ser usados para isso. Em aplicativos Django, o robusto dispatcher de URL permite um gerenciamento eficiente de regravações de URL.

Solução de problemas

De forma geral, a primeira etapa na solução de problemas é usar o diagnóstico do Serviço de Aplicativo:

1. No portal do Azure do aplicativo Web, selecione Diagnosticar e resolver problemas, no menu à esquerda.
2. Selecione Disponibilidade e Desempenho.
3. Examine as informações nas opções de Logs de Aplicativo, Falha de Contêiner e Problemas de Contêiner, em que os problemas mais comuns serão exibidos.

Em seguida, examine tanto os logs de implantação quanto os logs de aplicativo em busca de eventuais mensagens de erro. Esses logs geralmente identificam problemas específicos que podem impedir a implantação ou a inicialização do aplicativo. Por exemplo, o build poderá falhar se o arquivo requirements.txt estiver com o nome incorreto ou não estiver presente na pasta raiz do projeto.

As seções a seguir fornecem diretrizes adicionais para problemas específicos.

• O aplicativo não aparece – O aplicativo padrão é exibido
• O aplicativo não aparece – mensagem "Serviço não disponível"
• Não foi possível localizar setup.py ou requirements.txt
• ModuleNotFoundError na inicialização
• O banco de dados está bloqueado
• As senhas não aparecem na sessão SSH quando digitadas
• Os comandos da sessão SSH parecem estar cortados
• Ativos estáticos não aparecem em um aplicativo Django
• Uma Conexão SSL Fatal é necessária

O aplicativo não aparece

• Você pode ver o aplicativo padrão depois de implantar seu próprio código de aplicativo. O aplicativo padrão é exibido porque você não implantou o código do aplicativo no Serviço de Aplicativo ou o Serviço de Aplicativo falhou ao localizar o código do aplicativo e executou o aplicativo padrão em vez disso.

  • Reinicie o Serviço de Aplicativo, aguarde de 15 a 20 segundos e verifique o aplicativo novamente.

  • Use SSH para se conectar diretamente ao contêiner do Serviço de Aplicativo e verifique se os arquivos existem em site/wwwroot. Se os arquivos não existirem, use as seguintes etapas:

    1. Crie uma configuração de aplicativo chamada SCM_DO_BUILD_DURING_DEPLOYMENT com o valor igual a 1, reimplante seu código, aguarde alguns minutos e tente acessar o aplicativo novamente. Para obter mais informações sobre como criar configurações de aplicativo, confira Configurar um aplicativo do Serviço de Aplicativo no portal do Azure.
    2. Examine o processo de implantação, verifique os logs de implantação, corrija eventuais erros e reimplante o aplicativo.

  • Se os arquivos existem, o Serviço de Aplicativo não pôde identificar o arquivo de inicialização específica. Verifique se seu aplicativo está estruturado como o Serviço de Aplicativo espera para Django ou Flask, ou use um comando de inicialização personalizados.

• Você verá a mensagem "Serviço Indisponível" no navegador. O navegador atingiu o tempo limite aguardando uma resposta do Serviço de Aplicativo, o que indica que o Serviço de Aplicativo iniciou o servidor Gunicorn, mas o aplicativo em si não foi iniciado. Essa condição pode indicar que os argumentos do Gunicorn estão incorretos ou que há um erro no código do aplicativo.

  • Atualize o navegador, especialmente se você estiver usando os tipos de preço mais baixos no seu plano de Serviço de Aplicativo. O aplicativo pode levar mais tempo para ser iniciado quando você usa camadas gratuitas, por exemplo, e se torna responsivo depois de atualizar o navegador.

  • Verifique se seu aplicativo está estruturado como o Serviço de Aplicativo espera para Django ou Flask, ou use um comando de inicialização personalizados.

  • Examine o fluxo de log do aplicativo para verificar se há mensagens de erro. Os logs mostrarão eventuais erros no código do aplicativo.

Não foi possível localizar setup.py ou requirements.txt

• O fluxo de log mostrará a mensagem "não foi possível localizar o setup.py nem o requirements.txt. A instalação de PIP não está sendo executada". : houve falha no processo de compilação do Oryx ao localizar o arquivo requirements.txt.

  • Conecte-se ao contêiner do aplicativo Web via SSH e verifique se o arquivo requirements.txt está com o nome correto e se existe diretamente em site/wwwroot. Se ele não existir, verifique se o arquivo existe no seu repositório e se está incluído na sua implantação. Em caso afirmativo, mova o arquivo para a raiz em uma pasta separada.

ModuleNotFoundError quando o aplicativo é iniciado

Se você vê um erro como ModuleNotFoundError: No module named 'example', o Python não pôde localizar um ou mais módulos quando o aplicativo foi iniciado. Esse erro ocorre com mais frequência se você implantar o ambiente virtual com o código. Ambientes virtuais não são portáteis, portanto, um ambiente virtual não deve ser implantado com o código do aplicativo. Em vez disso, permita que o Oryx crie um ambiente virtual e instale os pacotes no aplicativo Web criando uma configuração de aplicativo, SCM_DO_BUILD_DURING_DEPLOYMENT, e definindo como 1. Essa configuração forçará o Oryx a instalar os pacotes sempre que você implantar no Serviço de Aplicativo. Para obter mais informações, consulte este artigo quanto à portabilidade do ambiente virtual.

O banco de dados está bloqueado

Ao tentar executar migrações do banco de dados com um aplicativo Django, você poderá ver "sqlite3. OperationalError: o banco de dados está bloqueado." O erro indica que seu aplicativo está usando um banco de dados SQLite, para o qual o Django está configurado por padrão, em vez de usar um banco de dados de nuvem, como o Banco de Dados do Azure para PostgreSQL.

Verifique a variável DATABASES no arquivo settings.py do aplicativo para garantir que ele esteja usando um banco de dados de nuvem em vez do SQLite.

Se estiver encontrando esse erro com a amostra em Tutorial: Implantar um aplicativo Web Django com PostgreSQL, verifique se você concluiu as etapas em Verificar configuções de conexão.

Outros problemas

• As senhas não aparecem na sessão SSH quando digitadas: por motivos de segurança, a sessão SSH mantém a senha oculta à medida que você digita. Contudo, os caracteres estão sendo gravados; por isso, digite sua senha como de costume e selecione Enter quando terminar.

• Os comandos na sessão SSH parecem ser cortados: o editor pode não estar quebrando os comandos em palavras, mas eles ainda devem ser executados corretamente.

• Os ativos estáticos não aparecem em um aplicativo Django: certifique-se de que você ativou o módulo do WhiteNoise.

• Você vê a mensagem "A Conexão SSL Fatal é necessária" : Verifique os nomes de dados e as senhas usados para acessar recursos (como bancos de dados) de dentro do aplicativo.

Conteúdo relacionado

• Tutorial: Aplicativo Python com o PostgreSQL
• Tutorial: Implantação por meio de um repositório de contêiner particular
• Serviço de Aplicativo nas Perguntas Frequentes do Linux
• Referência de variáveis de ambiente e configurações de aplicativo