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

Este artigo descreve como o Serviço de Aplicativo do Azure executa aplicativos Python, como você pode migrar aplicativos existentes para o Azure e como personalizar o comportamento do Serviço de Aplicativo quando necessário. Os aplicativos Python devem 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 é executado pip install -r requirements.txt para você quando você implanta um repositório Git ou quando implanta um pacote zip com a automação de compilação habilitada.

Este guia fornece conceitos-chave e instruções para desenvolvedores Python que usam um contêiner Linux integrado no Serviço de Aplicativo. Se você nunca usou o Serviço de Aplicativo do Azure, primeiro siga o tutorial de início rápido do Python e Python com PostgreSQL.

Você pode usar o portal do Azure ou a CLI do Azure para configuração:

• Portal do Azure, use a página Configuração de Definições> 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.

  • Execute comandos no Azure Cloud Shell.
  • Execute comandos localmente instalando a versão mais recente da CLI do Azure e, em seguida, entre no Azure usando 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 configurações gerais para contêineres do Linux.

• CLI do Azure:

  • Mostrar a versão atual do Python com 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 az webapp config set

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

  • Mostrar todas as versões Python suportadas no Serviço de Aplicativo do Azure com az webapp list-runtimes:

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

Você pode executar uma versão não suportada do Python criando sua própria imagem de contêiner. Para obter mais informações, veja Utilizar uma imagem personalizada do Docker.

Personalizar a automatização de compilação

O sistema de compilação do Serviço de Aplicativo, chamado Oryx, executa as seguintes etapas quando você implanta seu aplicativo, se a configuração SCM_DO_BUILD_DURING_DEPLOYMENT do aplicativo estiver definida como 1:

1. Execute um script de pré-compilação personalizado, se essa etapa for especificada pela PRE_BUILD_COMMAND configuração. (O script pode executar outros scripts Python e Node.js, comandos pip e npm e ferramentas baseadas em Node, como yarn, por exemplo, yarn install e yarn build.)

2. Execute o pip install -r requirements.txt. O arquivo requirements.txt deve estar presente na pasta raiz do projeto. Caso contrário, o processo de compilação relata o erro: "Não foi possível encontrar setup.py ou requirements.txt; Não está executando pip install."

3. Se manage.py for encontrado na raiz do repositório (indicando um aplicativo Django), execute manage.py collectstatic. No entanto, se a DISABLE_COLLECTSTATIC configuração for true, esta etapa será ignorada.

4. Execute um POST_BUILD_COMMAND script pós-construção personalizado, se essa etapa for especificada pela configuração. (Novamente, o script pode executar outros scripts Python e Node.js, comandos pip e npm e ferramentas baseadas em Node.)

Por padrão, as PRE_BUILD_COMMANDconfigurações , POST_BUILD_COMMANDe e DISABLE_COLLECTSTATIC estão vazias.

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

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

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

Para obter outras configurações que personalizam a automação de compilação, consulte Configuração do Oryx.

Para acessar os logs de compilação e implantação, consulte Acessar logs de implantação.

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

Migrar aplicativos existentes para o Azure

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

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

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

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

3. Recursos do serviço de aplicativo: crie 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 az webapp upda CLI do Azure . Ou, você pode criar e implantar recursos como mostrado em 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 ser mais adequado ao seu aplicativo.

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

   • As conexões de banco de dados, por exemplo, geralmente são gerenciadas por meio dessas configurações, como mostrado em Tutorial: Implantar um aplicativo web Django com PostgreSQL - verificar as configurações de conexão.
   • Consulte Configurações de produção para aplicativos Django para configurações específicas para aplicativos Django típicos.

5. Inicialização do aplicativo: revise 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 deve ser capaz de encontrar seu objeto de aplicativo ou wsgi.py pasta. Se precisar, você pode personalizar o comando de inicialização.

6. Implantação contínua: configure a implantação contínua a partir de Ações do GitHub, Bitbucket ou Repositórios do Azure, 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 dentro do contêiner do Serviço de Aplicativo que hospeda seu aplicativo, como migrações de banco de dados Django, você pode se conectar ao contêiner por meio de SSH. Para obter um exemplo de execução de migrações de banco de dados Django, consulte 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-compilação, conforme descrito anteriormente em Personalizar automação de compilação.

Com essas etapas concluídas, você poderá confirmar alterações no repositório de origem e implantar automaticamente essas atualizações no Serviço de Aplicativo.

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

Para 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 descreve as configurações de produção relevantes para o Azure. Essas configurações são definidas no arquivo setting.py do aplicativo.

Servir arquivos estáticos para aplicativos Django

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

Para o Serviço de Aplicativo, você faz as seguintes modificações:

1. Considere o uso de variáveis de ambiente (para desenvolvimento local) e Configurações do aplicativo (ao implantar na nuvem) para definir dinamicamente o Django STATIC_URL e STATIC_ROOT as variáveis. 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 pode ser alterado conforme necessário para os seus ambientes locais e na nuvem. Por exemplo, se o processo de compilação para seus 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. Se você tiver um script de pré-construção que gera arquivos estáticos em uma pasta diferente, inclua essa pasta na variável Django para que o processo do collectstatic Django STATICFILES_DIRS os encontre. Por exemplo, se você executar yarn build em sua pasta front-end e o yarn gerar uma build/static pasta 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 construir um caminho para onde uma ferramenta de construção como o fio é executada. Você pode usar novamente uma variável de ambiente e a Configuração do aplicativo conforme desejado.

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

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

   STATICFILES_STORAGE = ('whitenoise.storage.CompressedManifestStaticFilesStorage')
   

5. Modifique também as MIDDLEWARE listas e INSTALLED_APPS para incluir 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
   ]
   

Servir arquivos estáticos para aplicativos Flask

Se o seu aplicativo web Flask incluir arquivos front-end estáticos, primeiro siga as instruções sobre 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 servir arquivos estáticos diretamente de uma rota em seu aplicativo, você pode usar o send_from_directory método:

from flask import send_from_directory

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

Características do contentor

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 Python do Serviço de Aplicativo. Você pode encontrar as configurações de imagem dentro dos diretórios específicos da versão.

Este contentor tem as seguintes características:

• Os aplicativos são executados usando o Gunicorn WSGI HTTP Server, usando os argumentos --bind=0.0.0.0 --timeout 600extras.

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

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

• Por padrão, a imagem do contêiner base inclui apenas o framework web Flask, mas o contêiner suporta outros frameworks compatíveis com WSGI e Python 3.6+, como o Django.

• Para instalar outros pacotes, como o Django, crie um arquivo de requirements.txt na raiz do seu projeto que especifique suas dependências diretas. Em seguida, o Serviço de Aplicativo instala essas dependências automaticamente quando você implanta seu projeto.

  O arquivo requirements.txt deve estar na raiz do projeto para que as dependências sejam instaladas. Caso contrário, o processo de compilação relata o erro: "Não foi possível encontrar setup.py ou requirements.txt; Não está executando pip install." Se você encontrar esse erro, verifique o local do seu arquivo de requisitos.

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

• npm e Node.js são instalados no contêiner para que você possa executar ferramentas de compilação baseadas em Node, como yarn.

Processo de inicialização do contêiner

Durante o arranque, o Serviço de Aplicações no contentor do Linux executa os seguintes passos:

1. Use um comando de inicialização personalizado, se fornecido.
2. Verifique a existência de um aplicativo Django e inicie o Gunicorn para ele se for detetado.
3. Verifique a existência de um aplicativo Flask e inicie o Gunicorn para ele se for detetado.
4. Não se for encontrada nenhuma outra aplicação, iniciar uma aplicação predefinida incorporada no contentor.

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

Aplicação Django

Para aplicações Django, o Serviço de Aplicações procura um ficheiro chamado wsgi.py no código da aplicação e, em seguida, executa o Gunicorn com o seguinte comando:

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

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

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

Aplicação Flask

Para Flask, o Serviço de Aplicativo procura um arquivo chamado application.py ou app.py e inicia o 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 aplicativo estiver contido em um arquivo diferente, use um nome diferente para o objeto do aplicativo. Se você quiser fornecer outros argumentos para o Gunicorn, use um comando de inicialização personalizado.

Comportamento predefinido

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

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

Personalizar 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 comando de inicialização. Um arquivo de comando de inicialização pode usar qualquer nome que você escolher, como startup.sh, startup.cmd, startup.txt e assim por diante.

Todos os comandos devem usar caminhos relativos para a pasta raiz do projeto.

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

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

• CLI do Azure: use o comando az webapp config set com o --startup-file parâmetro para definir o comando ou arquivo 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 pelo nome do arquivo de comando de inicialização.

O Serviço de Aplicativo ignora quaisquer erros que ocorram ao processar um comando ou arquivo de inicialização personalizado e, em seguida, continua seu processo de inicialização procurando por aplicativos Django e Flask. Se você não vir o comportamento esperado, verifique se o comando ou arquivo de inicialização está livre de erros e se um arquivo de comando de inicialização foi implantado no Serviço de Aplicativo junto 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.

Exemplo de comandos de inicialização

• Argumentos Gunicorn adicionados: O exemplo a seguir adiciona o --workers=4 argumento a uma linha de comando 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 Executando o Gunicorn. Se você estiver usando regras de dimensionamento automático para dimensionar seu aplicativo Web para cima e para baixo, você também deve definir dinamicamente o número de trabalhadores do Gunicorn usando a NUM_CORES variável de ambiente em 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 as Perguntas frequentes do Gunicorn.

• Habilite o log de produção para o Django: adicione os --access-logfile '-' argumentos 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 logs 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 assume que o módulo principal de um aplicativo Flask é application.py ou app.py. Se o módulo principal usa um nome diferente, você deve personalizar o comando de inicialização. Por exemplo, se tiver uma aplicação Flask cujo módulo principal seja hello.py e o objeto de aplicação Flask nesse ficheiro tenha o nome myapp, o comando é o seguinte:

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

  Se o seu módulo principal estiver numa subpasta, como website, especifique essa pasta com o argumento --chdir:

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

• Use um servidor não-Gunicorn: Para usar um servidor web diferente, como aiohttp, use o comando apropriado como o comando de inicialização ou no arquivo de comando de inicialização:

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

Acessar as configurações do aplicativo como variáveis de ambiente

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

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

db_server = os.environ['DATABASE_SERVER']

Detetar sessão HTTPS

No Serviço de Aplicativo, a terminação TLS/SSL acontece nos balanceadores de carga de rede, portanto, todas as solicitações HTTPS chegam ao seu aplicativo como solicitações HTTP não criptografadas. Se a lógica da aplicação precisar de verificar se os pedidos do utilizador estão ou não encriptados, 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

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

Aceder aos registos de diagnósticos

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

Primeiro, ative o log de 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.

Quando o log de 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 não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Para interromper o streaming de logs 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>do fluxo de logs no menu do lado esquerdo do seu aplicativo.

Acessar logs de implantação

Quando você implanta seu código, o Serviço de Aplicativo executa o processo de compilação descrito anteriormente na seção Personalizar automação de compilação. Como a compilação é executada em seu próprio contêiner, os logs de compilação 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 Centro de Implantação 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 que aparece ao lado de "Executando a compilação do oryx...".

Problemas de compilação, como dependências incorretas no requirements.txt e erros em scripts pré ou pós-compilação, aparecerão nesses logs. Os erros também aparecem se o arquivo de requisitos não tiver o nome requirements.txt ou não aparecer na pasta raiz do projeto.

Abrir sessão SSH no browser

Para abrir uma sessão SSH direta com o seu contentor, a sua aplicação deve estar em execução.

Cole o seguinte URL no browser e substitua <app-name> pelo nome da aplicação:

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

Se ainda não estiver autenticado, é necessário fazê-lo com a sua subscrição do Azure para se ligar. Uma vez autenticado, pode ver uma shell no browser, na qual pode executar comandos dentro do seu contentor.

Para abrir uma sessão SSH remota a partir do computador local, veja Abrir sessão SSH a partir da shell remota.

Quando você estiver conectado com êxito à sessão SSH, você 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 está reiniciando, um erro pode estar impedindo que o contêiner do aplicativo seja iniciado. Consulte Solução de problemas para obter etapas para investigar possíveis problemas.

Regravações de URL

Ao implantar aplicativos Python no Serviço de Aplicativo do Azure para Linux, talvez seja necessário lidar com regravações de URL em seu aplicativo. Isso é particularmente útil para garantir que padrões de URL específicos sejam redirecionados para os pontos de extremidade corretos sem depender de configurações de servidor Web externo. Para aplicações Flask, processadores de URL e middleware personalizado podem ser usados para conseguir isso. Em aplicativos Django, o despachante de URL robusto permite o gerenciamento eficiente de regravações de URL.

Resolução de Problemas

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

1. No portal do Azure para seu aplicativo Web, selecione Diagnosticar e resolver problemas no menu à esquerda.
2. Selecione Disponibilidade e Desempenho.
3. Examine as informações nas opções Logs de aplicativos, Falha de contêiner e Problemas de contêiner, onde os problemas mais comuns aparecerão.

Em seguida, examine os logs de implantação e os logs do aplicativo para verificar se há mensagens de erro. Esses logs geralmente identificam problemas específicos que podem impedir a implantação ou a inicialização do aplicativo. Por exemplo, a compilação pode falhar se o arquivo requirements.txt tiver o nome de arquivo errado ou não estiver presente na pasta raiz do projeto.

As secções seguintes fornecem orientações para questões específicas.

• O aplicativo não aparece - o aplicativo padrão é exibido
• A aplicação não aparece - mensagem "serviço indisponível"
• Não foi possível encontrar 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 na sessão SSH parecem estar cortados
• Os ativos estáticos não aparecem em um aplicativo Django
• Conexão SSL fatal é necessária

O aplicativo não aparece

• Vê a aplicação predefinida depois de implementar o seu próprio código de aplicação. O aplicativo padrão aparece porque você não implantou o código do aplicativo no Serviço de Aplicativo ou o Serviço de Aplicativo não conseguiu localizar o código do aplicativo e executou o aplicativo padrão.

  • Reinicie o Serviço de Aplicações, aguarde 15 a 20 segundos e verifique novamente a aplicação.

  • Use SSH para se conectar diretamente ao contêiner do Serviço de Aplicativo e verificar se seus arquivos existem em site/wwwroot. Se os seus ficheiros não existirem, utilize os seguintes passos:

    1. Crie uma configuração de aplicativo nomeada SCM_DO_BUILD_DURING_DEPLOYMENT com o valor de 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, consulte Configurar um aplicativo do Serviço de Aplicativo no portal do Azure.
    2. Revise seu processo de implantação, verifique os logs de implantação, corrija quaisquer erros e reimplante o aplicativo.

  • Se os ficheiros existirem, o Serviço de Aplicações não conseguiu identificar o ficheiro de arranque específico. Verifique se a aplicação está estruturada como Serviço de Aplicações para o Django ou o Flask, ou utilize um comando de arranque personalizado.

• Você verá a mensagem "Serviço indisponível" no navegador. O navegador atingiu o tempo limite de espera por 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 níveis de preços mais baixos em seu plano do 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 que você atualiza o navegador.

  • Verifique se a aplicação está estruturada como Serviço de Aplicações para o Django ou o Flask, ou utilize um comando de arranque personalizado.

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

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

• O fluxo de log mostra "Não foi possível encontrar setup.py ou requirements.txt; Não está executando pip install.": O processo de compilação do Oryx não conseguiu encontrar seu arquivo requirements.txt .

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

ModuleNotFoundError quando o aplicativo é iniciado

Se você vir um erro como ModuleNotFoundError: No module named 'example', o Python não conseguiu encontrar um ou mais de seus módulos quando o aplicativo foi iniciado. Esse erro ocorre com mais freqüência se você implantar seu ambiente virtual com seu código. Os ambientes virtuais não são portáteis, portanto, um ambiente virtual não deve ser implantado com o código do seu aplicativo. Em vez disso, permita que o Oryx crie um ambiente virtual e instale seus pacotes no aplicativo Web criando uma configuração SCM_DO_BUILD_DURING_DEPLOYMENTde aplicativo e definindo-a como 1. Essa configuração forçará o Oryx a instalar seus pacotes sempre que você implantar no Serviço de Aplicativo. Para obter mais informações, consulte este artigo sobre portabilidade de ambiente virtual.

O banco de dados está bloqueado

Ao tentar executar migrações de banco de dados com um aplicativo Django, você pode 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 em nuvem, como o Banco de Dados do Azure para PostgreSQL.

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

Se você estiver encontrando esse erro com o exemplo em Tutorial: Implantar um aplicativo Web Django com PostgreSQL, verifique se você concluiu as etapas em Verificar configuraçõ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 sua senha oculta quando você digita. Os caracteres estão sendo gravados, no entanto, 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 ser comandos de quebra automática de texto, mas eles ainda devem ser executados corretamente.

• Os ativos estáticos não aparecem em um aplicativo Django: certifique-se de ter ativado o módulo WhiteNoise.

• Você verá a mensagem "Conexão SSL fatal é necessária": verifique todos os nomes de usuário e senhas usados para acessar recursos (como bancos de dados) de dentro do aplicativo.

Conteúdos relacionados

• Tutorial: Aplicativo Python com PostgreSQL
• Tutorial: Implantar a partir do repositório de contêiner privado
• FAQ do Serviço de Aplicações no Linux
• Referência de variáveis de ambiente e configurações de aplicativo