Partilhar via

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

Implantar no 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 motor de implementação de Serviços de Aplicações ativa automaticamente um ambiente virtual e instala dependências de um requirements.txt, pyproject.toml, ou setup.py ficheiro quando implementa um repositório Git ou quando implementa um pacote zipcom automação de compilações ativada.

Este artigo fornece conceitos-chave e instruções para desenvolvedores Python que usam um contêiner Linux interno no Serviço de Aplicativo. Se você nunca usou o Serviço de Aplicativo, primeiro conclua o tutorial de início rápido do Python e Flask, Django ou FastAPI com PostgreSQL.

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

Nota

O Linux é a única opção de sistema operacional para executar aplicativos Python no Serviço de Aplicativo. Python no Windows não é mais suportado. No entanto, você pode criar sua própria imagem de contêiner personalizada do Windows e executá-la no Serviço de Aplicativo. Para obter mais informações, consulte Usar uma imagem personalizada do Docker.

Configurar a versão 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 usando 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 usando az webapp config set:

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

    • Mostrar todas as versões do Python suportadas no Serviço de Aplicativo usando 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, consulte Usar uma imagem personalizada do Docker.

O que acontece com tempos de execução desatualizados no Serviço de Aplicativo?

Tempos de execução desatualizados são preteridos pela organização mantenedora ou têm vulnerabilidades significativas. Assim, eles são removidos das páginas de criação e configuração no portal. Quando um tempo de execução desatualizado é oculto do portal, qualquer aplicativo que ainda esteja usando esse tempo de execução continua a ser executado.

Se você quiser criar um aplicativo com uma versão de tempo de execução desatualizada que não é mais mostrada no portal, use a CLI do Azure, um modelo ARM ou Bicep. Essas alternativas de implantação permitem criar tempos de execução preteridos que são removidos do portal, mas ainda estão sendo suportados.

Se um tempo de execução for totalmente removido da plataforma do Serviço de Aplicativo, o proprietário da assinatura do Azure receberá um aviso por email antes da remoção.

Personalizar a automatização de compilação

Nota

Quando os aplicativos Python são implantados com automação de compilação, o conteúdo é implantado e servido a partir de /tmp/<uid>, não em /home/site/wwwroot. Você pode acessar esse diretório de conteúdo usando a variável de APP_PATH ambiente. Você deve gravar todos os arquivos adicionais criados em tempo de execução em um local sob /home ou usando Bring Your Own Storage para persistência. Para obter mais informações sobre esse comportamento, consulte Python Build Changes.

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 próprio 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. Instale dependências. O sistema de compilação verifica os seguintes ficheiros na raiz do projeto:

    • requirements.txt: Executa pip install -r requirements.txt.
    • pyproject.toml com uv.lock: Utiliza uv.
    • pyproject.toml com poetry.lock: Utiliza poetry.
    • pyproject.toml: Utiliza poetry.
    • setup.py: Corre pip install ..

    Nota

    Se pyproject.toml estiver presente mas uv.lock estiver ausente, o App Service define o uso do Poetry por padrão, mesmo que poetry.lock também esteja ausente. Para usar uv, deve incluir uv.lock na sua implantação.

    Se nenhum destes ficheiros for encontrado, o processo de compilação reporta o erro "Não foi possível encontrar setup.py ou requirements.txt; Não está a correr a instalação do pip."

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

  4. Execute um script pós-construção personalizado, se essa etapa for especificada na POST_BUILD_COMMAND 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 configurações PRE_BUILD_COMMAND, POST_BUILD_COMMAND 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 à 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 à pasta raiz do projeto.

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

Para obter informações sobre como 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.

Nota

As definições PRE_BUILD_SCRIPT_PATH e POST_BUILD_SCRIPT_PATH são idênticas a PRE_BUILD_COMMAND e POST_BUILD_COMMAND e são suportadas para fins de compatibilidade com versões anteriores.

Uma configuração chamada SCM_DO_BUILD_DURING_DEPLOYMENT, se contiver true ou 1, dispara uma compilação do Oryx que acontece durante a implantação. A configuração é true quando você implanta usando o Git, o comando az webapp upda CLI do Azure e o Visual Studio Code.

Nota

Sempre use caminhos relativos em todos os scripts pré e pós-compilação porque o contêiner de compilação no qual o Oryx é executado é diferente do contêiner de tempo de execução no qual o aplicativo é executado. Nunca confie no posicionamento exato da pasta do projeto do aplicativo dentro do contêiner (por exemplo, que ela seja colocada em site/wwwroot).

Migrar aplicativos existentes para o Azure

Você pode reimplantar aplicativos Web existentes no 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 mais tarde nesse processo.

    • O seu ficheiro de dependência (como requirements.txt, pyproject.toml ou setup.py) deve estar na raiz do seu repositório se quiser que o App Service instale automaticamente os pacotes necessários.

  2. Base 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 criar esses recursos facilmente executando o comando az webapp upda CLI do Azure . Ou você pode criar e implantar recursos como mostrado no tutorial Flask, Django ou FastAPI com PostgreSQL. Substitua os nomes do grupo de recursos, do plano do Serviço de Aplicativo e do aplicativo Web por nomes adequados para 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.

  5. Inicialização do aplicativo. Consulte a seção Processo de inicialização de contêiner mais adiante neste artigo para obter informações sobre como o Serviço de Aplicativo tenta executar seu aplicativo. O Serviço de Aplicativo usa o servidor Web Gunicorn por padrão. O Gunicorn 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 local do Git 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 usando 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.

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, os aplicativos Django devem seguir as orientações na 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.

Configuração de Django Instruções para o Azure
SECRET_KEY Armazene o valor em uma configuração do Serviço de Aplicativo, conforme descrito em Configurações do aplicativo do Access como variáveis de ambiente. Como alternativa, você pode armazenar o valor como um segredo no Cofre da Chave do Azure.
DEBUG Crie uma DEBUG configuração no Serviço de Aplicativo com o valor 0 (false) e carregue o valor como uma variável de ambiente. Em seu ambiente de desenvolvimento, crie uma DEBUG variável de ambiente com o valor 1 (true).
ALLOWED_HOSTS Na produção, o Django exige que você inclua a ALLOWED_HOSTS URL do aplicativo na matriz de settings.py. Você pode recuperar essa URL em tempo de execução usando o código os.environ['WEBSITE_HOSTNAME']. O Serviço de Aplicativo define automaticamente a WEBSITE_HOSTNAME variável de ambiente para a URL do aplicativo.
DATABASES Defina configurações no Serviço de Aplicativo para a conexão de banco de dados e carregue-as como variáveis de ambiente para preencher o DATABASES dicionário. Como alternativa, você pode armazenar os valores (especialmente o nome de usuário e a senha) como segredos do Cofre da Chave.

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 de 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 colocá-los em uma pasta chamada django-static, você pode definir DJANGO_STATIC_URL como /django-static/ para evitar o uso do padrão.

  2. Se tiveres um script de pré-compilação que gera ficheiros estáticos numa pasta diferente, inclui 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 em sua pasta front-end e o Yarn gerar uma build/static pasta contendo arquivos estáticos, inclua essa pasta como mostrado aqui:

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

    Neste código, FRONTEND_DIR é usado para construir um caminho para onde uma ferramenta de compilação como o Yarn é executada. Você pode usar novamente uma variável de ambiente e uma configuração de aplicativo, se desejar.

  3. Adicione whitenoise ao 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 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 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 em gerenciamento de 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 ficheiros estáticos diretamente de uma rota na sua aplicação, 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 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 nos diretórios específicos da versão.

Este contentor tem as seguintes características:

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

  • 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 com Python 3.6 e posterior, como o Django.

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

    O ficheiro de dependência tem de estar na raiz do projeto, caso contrário as dependências não serão instaladas. Se esse arquivo não estiver na raiz, 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 chamada WEBSITE_HOSTNAME que contém a URL do aplicativo Web, como msdocs-hello-world.azurewebsites.net. Ele também define WEBSITE_SITE_NAME, que contém 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 o 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 aplicativos Django, o Serviço de Aplicativo procura um arquivo chamado wsgi.py no código do aplicativo e executa o 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

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.

Captura de ecrã da página Web predefinida do Serviço de Aplicação no Linux.

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 ou startup.txt.

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

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

  • Portal do Azure. Em Definições no painel esquerdo da página da aplicação, selecione Configuração e, em seguida, selecione Definições gerais. Na caixa Comando de inicialização , digite 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 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. E você pode verificar 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 that contains 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 mais informações, consulte Registo 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 você tiver um aplicativo Flask cujo módulo principal é hello.py e o objeto do aplicativo Flask nesse arquivo for chamado myapp, este é o comando:

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

    Se o módulo principal estiver em uma subpasta, como site, especifique essa pasta com o --chdir argumento:

    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 por meio do padrão os.environ padrão.

Por exemplo, se você criar 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']

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 do seu aplicativo precisar verificar se as solicitações do usuário estão criptografadas, inspecione o X-Forwarded-Proto cabeçalho:

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 SECURE_PROXY_SSL_HEADER para configurar o Django para usar o X-Forwarded-Proto cabeçalho.

Aceder aos registos de diagnósticos

Você pode acessar os logs do console que são gerados de dentro do contêiner.

Para ativar o log de contêiner, execute o seguinte comando:

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

Substitua os <app-name> valores e <resource-group-name> por nomes apropriados para a sua aplicação web.

Depois de ativar o log de contêiner, execute o seguinte comando para ver o fluxo de log:

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

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para parar a transmissão de registos a qualquer momento, use o atalho de teclado Ctrl+C.

Para acessar logs no portal do Azure, selecione Monitoramento> dofluxo de logs no painel esquerdo do seu aplicativo.

Aceder aos 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. Na página do portal do Azure para seu aplicativo Web, selecioneCentro de Implantação> no painel esquerdo.
  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 ficheiro de dependências e erros em scripts pré-compilação ou pós-compilação, aparecem nestes registos. Os erros também aparecem se o ficheiro de dependência não estiver na pasta raiz do projeto.

Abrir sessão SSH em um navegador

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

Use o comando az webapp ssh .

Se você não estiver autenticado, precisará autenticar com sua assinatura do Azure para se conectar. Quando você é autenticado, vê um shell no navegador onde pode executar comandos dentro do contêiner.

Conexão SSH

Nota

Todas as alterações feitas fora do /home diretório são armazenadas no próprio contêiner e não persistem após uma reinicialização do aplicativo.

Para abrir uma sessão SSH remota a partir da sua máquina local, consulte Abrir sessão SSH a partir do shell remoto.

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 informações sobre como investigar possíveis problemas.

Reescrita de URLs

Ao implantar aplicativos Python no Serviço de Aplicativo para Linux, talvez seja necessário lidar com regravações de URL em seu aplicativo. Esse método é 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 aplicativos Flask, você pode usar processadores de URL e middleware personalizado para conseguir isso. Em aplicativos Django, o dispatcher de URL 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. Na página do portal do Azure para seu aplicativo Web, selecione Diagnosticar e resolver problemas no painel esquerdo.
  2. Selecione Disponibilidade e Desempenho.
  3. Examine as informações em Logs de Aplicativos, Falha de Contêiner e Problemas de Contêiner, onde os problemas mais comuns aparecem.

Em seguida, examine os registos de implantação e os registos da aplicação 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 ficheiro de dependência 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

  • 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 porque o Serviço de Aplicativo não conseguiu localizar o código do aplicativo e executou o aplicativo padrão.

    • Reinicie o aplicativo, aguarde 20 segundos e verifique o aplicativo novamente.

    • 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, siga os seguintes passos:

      1. Crie uma configuração de aplicativo nomeada SCM_DO_BUILD_DURING_DEPLOYMENT com um valor de , reimplante seu código, aguarde 1alguns 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 seus ficheiros existirem, o Serviço de Aplicação não conseguiu identificar o seu ficheiro de arranque. Certifique-se de que seu aplicativo esteja estruturado como o Serviço de Aplicativo espera para Django ou Flask, ou use um comando de inicialização personalizado.

  • Você verá a mensagem "Serviço indisponível" no navegador. O navegador atingiu o tempo limite aguardando uma resposta do Serviço de Aplicativo. Isso 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 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 personalizado.

    • Examine o fluxo de log do aplicativo em busca de 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 logs mostra "Não foi possível encontrar o setup.py ou o requirements.txt; O pip install não está a ser executado." O processo de compilação do Oryx falhou ao encontrar o seu ficheiro requirements.txt, pyproject.toml ou setup.py.

    • Liga-te ao contentor da aplicação web via SSH e verifica se o teu ficheiro de dependência está corretamente nomeado 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 a aplicação é iniciada.

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ça 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 settings.py do aplicativo para garantir que seu aplicativo esteja usando um banco de dados na 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. No entanto, os caracteres estão sendo gravados, portanto, digite sua senha como de costume e selecione Enter quando terminar.

  • Os comandos na sessão SSH parecem estar truncados: o editor pode não estar a aplicar a quebra automática de linhas, mas eles devem ainda ser executados corretamente.

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

  • Você vê 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

  • Last updated on