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 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 zipcom a automação de compilação habilitada.

Nota

Atualmente, o Serviço de Aplicativo requer requirements.txt no diretório raiz do teu projeto, mesmo que tenhas um arquivo pyproject.toml. Consulte Generate requirements.txt a partir de pyproject.toml para abordagens recomendadas.

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 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 do Python

  • Portal do Azure: utilize a guia Configurações gerais na página Configuração conforme descrito em Configurar configurações gerais para contentores 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, 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 descontinuados pela organização responsável pela manutenção ou descobertos com 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, o modelo ARM ou o Bicep. Essas alternativas de implantação permitem criar tempos de execução obsoletos que foram removidos no portal, mas ainda estão a ser 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 as aplicações Python são implementadas com automação de build, o conteúdo será implementado em /tmp/<uid> e servido a partir de /tmp/<uid>, não sob . Este diretório de conteúdo pode ser acedido através da variável de ambiente APP_PATH. Quaisquer arquivos adicionais criados em tempo de execução devem ser gravados em um local sob /home ou usando Bring Your Own Storage para persistência. Mais informações sobre esse comportamento podem ser encontradas aqui.

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 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 uma aplicação Django), execute manage.py collectstatic. No entanto, se a DISABLE_COLLECTSTATIC definição for true, esta etapa será ignorada.

  4. Execute um POST_BUILD_COMMAND script pós-compilação personalizado, se esse passo for especificado 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 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 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.

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

Gere requirements.txt a partir de pyproject.toml

O Serviço de Aplicativo não oferece suporte pyproject.toml direto no momento. Se você estiver usando ferramentas como Poetry ou uv, a abordagem recomendada é gerar um compatível requirements.txt antes da implantação na raiz do seu projeto:

Usando a poesia

Usar o Poetry com o plugin de exportação:


poetry export -f requirements.txt --output requirements.txt --without-hashes

Usando uv

Usando uv:


uv export --format requirements-txt --no-hashes --output-file requirements.txt

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.

    • O arquivo 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 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 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.

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 App Service 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.

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 com 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 do Azure.

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 Definições da Aplicação (ao implantar na nuvem) para dinamicamente definir 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 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 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 tu executares yarn build na tua pasta front-end e o yarn criar uma pasta build/static contendo arquivos estáticos, deves incluir 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 até onde uma ferramenta de build como o Yarn é executada. Você pode usar novamente uma variável de ambiente e a Configuração do aplicativo conforme desejado.

  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 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 listas MIDDLEWARE 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 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 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 extras argumentos --bind=0.0.0.0 --timeout 600.

  • 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 derequirements.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.txtdeve 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 uma app Django e inicie o Gunicorn para ela se for detetada.
  3. Verifique a existência de uma aplicação Flask e inicie o Gunicorn para ela se for detectada.
  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 parâmetros --access-logfile 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, startup.txte 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 parâmetro para definir o comando ou ficheiro 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 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, o comando será 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 web populares permitem aceder às X-Forwarded-* informações no padrão da tua aplicação habitual. Por exemplo, no Django pode usar o SECURE_PROXY_SSL_HEADER para dizer ao Django para usar o cabeçalho X-Forwarded-Proto.

Aceder aos registos de diagnósticos

Você pode acessar os logs do console 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 <app-name> e <resource-group-name> por nomes apropriados para seu aplicativo 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 interromper o streaming de logs a qualquer momento, selecione Ctrl+C.

Para aceder aos logs através do portal do Azure, selecione Monitorização>Fluxo de logs no menu à esquerda para a sua aplicação.

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. No portal do Azure para a sua aplicação 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 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 seu contêiner, seu aplicativo deve estar em execução.

Use o comando az webapp ssh .

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.

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 etapas para investigar possíveis problemas.

Reescrita de URLs

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 aplicações, Falha de contenedor e Problemas de contenedor, onde aparecerão os problemas mais comuns.

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

  • 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 seus ficheiros existirem, então o App Service não conseguiu identificar o seu ficheiro de inicialização específico. 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.

  • 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 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 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 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. Esta configuração forçará o Oryx a instalar os seus pacotes sempre que for implantado 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. 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 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ê 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