Configurar uma aplicação Python do Linux para Serviço de Aplicações do Azure

Este artigo descreve como Serviço de Aplicações do Azure executa aplicações Python, como pode migrar aplicações existentes para o Azure e como pode personalizar o comportamento das Serviço de Aplicações quando necessário. As aplicações Python têm de ser implementadas com todos os módulos pip necessários.

O Serviço de Aplicações motor de implementação ativa automaticamente um ambiente virtual e é executado pip install -r requirements.txt automaticamente quando implementa um repositório Git ou um pacote zipcom a automatização de compilação ativada.

Este guia fornece conceitos e instruções fundamentais para os programadores de Python que utilizam um contentor do Linux incorporado no Serviço de Aplicações. Se nunca utilizou Serviço de Aplicações do Azure, siga primeiro o tutorial Python quickstart and Python with PostgreSQL (Início rápido do Python e Python com PostgreSQL).

Pode utilizar o portal do Azure ou a CLI do Azure para configuração:

• portal do Azure, utilize a páginaConfiguração de Definições> da aplicação, conforme descrito em Configurar uma aplicação Serviço de Aplicações no portal do Azure.

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

  • Execute comandos no Cloud Shell do Azure.
  • Execute comandos localmente ao instalar a versão mais recente da CLI do Azure e, em seguida, inicie sessão no Azure com az login.

Configurar a versão do Python

• portal do Azure: utilize o separador Definições gerais na página Configuração, conforme descrito em Configurar definiçõ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 adequados para a sua aplicação Web.

  • Definir a versão do Python com o conjunto de configuração az webapp

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

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

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

Pode executar uma versão não suportada do Python ao criar a sua própria imagem de contentor. Para obter mais informações, veja Utilizar uma imagem personalizada do Docker.

Personalizar a automatização de compilação

Serviço de Aplicações sistema de compilação, denominado Oryx, executa os seguintes passos ao implementar a sua aplicação se a definição SCM_DO_BUILD_DURING_DEPLOYMENT da aplicação estiver definida como 1:

1. Execute um script de pré-compilação personalizado, se especificado pela PRE_BUILD_COMMAND definição. (O script pode, por si só, executar outros scripts python e Node.js, comandos pip e npm e ferramentas baseadas em Nós, como yarn, por exemplo, yarn install e yarn build.)

2. Execute pip install -r requirements.txt. O ficheirorequirements.txt tem de estar presente na pasta raiz do projeto. Caso contrário, o processo de compilação comunica o erro: "Não foi possível localizar setup.py ou requirements.txt; Não está a executar a instalação do pip."

3. Se manage.py for encontrada na raiz do repositório (indicando uma aplicação Django), execute manage.py collectstatic. No entanto, se a DISABLE_COLLECTSTATIC definição for true, este passo será ignorado.

4. Execute o script pós-compilação personalizado, se especificado pela POST_BUILD_COMMAND definição. (Mais uma vez, o script pode executar outros scripts python e Node.js, comandos pip e npm e ferramentas baseadas em Nós.)

Por predefinição, as PRE_BUILD_COMMANDdefinições , POST_BUILD_COMMANDe DISABLE_COLLECTSTATIC estão vazias.

• Para desativar a execução do collectstatic ao criar aplicações Django, defina a DISABLE_COLLECTSTATIC definição como true.

• Para executar comandos de pré-compilação, defina a PRE_BUILD_COMMAND definição para conter um comando, como echo Pre-build command, ou um caminho para um ficheiro de script em relação à raiz do projeto, como scripts/prebuild.sh. Todos os comandos têm de utilizar caminhos relativos para a pasta raiz do projeto.

• Para executar comandos pós-compilação, defina a POST_BUILD_COMMAND definição para conter um comando, como echo Post-build command, ou um caminho para um ficheiro de script em relação à raiz do projeto, como scripts/postbuild.sh. Todos os comandos têm de utilizar caminhos relativos para a pasta raiz do projeto.

Para outras definições que personalizam a automatização de compilação, veja Configuração do Oryx.

Para aceder aos registos de compilação e implementação, veja Registos de implementação do Access.

Para obter mais informações sobre como Serviço de Aplicações executa e cria aplicações Python no Linux, veja Como o Oryx deteta e cria aplicações Python.

Migrar aplicações existentes para o Azure

As aplicações Web existentes podem ser reimplementadas no Azure da seguinte forma:

1. Repositório de origem: mantenha o código fonte num repositório adequado, como o GitHub, que lhe permite configurar a implementação contínua mais à frente neste processo.

   • O ficheiro requirements.txt tem de estar na raiz do repositório para Serviço de Aplicações instalar automaticamente os pacotes necessários.

2. Base de dados: se a sua aplicação depender de uma base de dados, crie também os recursos necessários no Azure.

3. Recursos do serviço de aplicações: crie um grupo de recursos, Serviço de Aplicações Plano e Serviço de Aplicações aplicação Web para alojar a sua aplicação. Pode fazê-lo facilmente ao executar o comando az webapp upda CLI do Azure . Em alternativa, pode criar e implementar recursos conforme mostrado no Tutorial: Implementar uma aplicação Web Python (Django ou Flask) com o PostgreSQL. Substitua os nomes do grupo de recursos, Serviço de Aplicações Plano e a aplicação Web para serem mais adequados para a sua aplicação.

4. Variáveis de ambiente: se a sua aplicação necessitar de variáveis de ambiente, crie definições de aplicações equivalentes Serviço de Aplicações. Estas definições de Serviço de Aplicações aparecem no seu código como variáveis de ambiente, conforme descrito nas variáveis de ambiente do Access.

   • As ligações de base de dados, por exemplo, são muitas vezes geridas através destas definições, conforme mostrado no Tutorial: Implementar uma aplicação Web django com o PostgreSQL – verificar as definições de ligação.
   • Veja Definições de produção para aplicações Django para definições específicas para aplicações típicas do Django.

5. Arranque da aplicação: reveja a secção Processo de arranque do contentor mais à frente neste artigo para compreender como Serviço de Aplicações tenta executar a sua aplicação. Serviço de Aplicações utiliza o servidor Web Gunicorn por predefinição, que tem de ser capaz de localizar o objeto da aplicação ou wsgi.py pasta. Se necessário, pode Personalizar o comando de arranque.

6. Implementação contínua: configure a implementação contínua a partir de GitHub Actions, Bitbucket ou Repositórios do Azure, conforme descrito no artigo Implementação contínua para Serviço de Aplicações do Azure. Em alternativa, configure a implementação contínua a partir do Git Local, conforme descrito no artigo Implementação local do Git para Serviço de Aplicações do Azure.

7. Ações personalizadas: para efetuar ações no contentor Serviço de Aplicações que aloja a sua aplicação, como migrações de bases de dados django, pode ligar ao contentor através de SSH. Para obter um exemplo da execução de migrações de bases de dados do Django, veja Tutorial: Deploy a Django Web app with PostgreSQL - generate database schema (Tutorial: Implementar uma aplicação Web django com PostgreSQL – gerar esquema de base de dados).

   • Ao utilizar a implementação contínua, pode efetuar essas ações com comandos pós-compilação, conforme descrito anteriormente em Personalizar a automatização de compilação.

Com estes passos concluídos, deverá conseguir consolidar as alterações ao repositório de origem e implementar essas atualizações automaticamente no Serviço de Aplicações.

Definições de produção para aplicações Django

Para um ambiente de produção como Serviço de Aplicações do Azure, as aplicações django devem seguir a lista de verificação implementação do Django (djangoproject.com).

A tabela seguinte descreve as definições de produção que são relevantes para o Azure. Estas definições são definidas no ficheiro de setting.py da aplicação.

Servir ficheiros estáticos para aplicações Django

Se a sua aplicação Web django incluir ficheiros de front-end estáticos, siga primeiro as instruções sobre Gerir ficheiros estáticos na documentação do Django.

Para Serviço de Aplicações, efetue as seguintes modificações:

1. Considere utilizar variáveis de ambiente (para desenvolvimento local) e Definições de Aplicações (ao implementar na cloud) 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 podem ser alterados conforme necessário para os seus ambientes locais e na cloud. Por exemplo, se o processo de compilação dos seus ficheiros estáticos os colocar numa pasta com o nome django-static, pode definir DJANGO_STATIC_URL para /django-static/ evitar utilizar a predefinição.

2. Se tiver um script de pré-compilação que gere ficheiros estáticos numa pasta diferente, inclua essa pasta na variável Django STATICFILES_DIRS para que o processo do collectstatic Django os encontre. Por exemplo, se executar yarn build na pasta de front-end e o yarn gerar uma build/static pasta com ficheiros estáticos, inclua essa pasta da seguinte forma:

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

   Aqui, FRONTEND_DIR, para criar um caminho para onde é executada uma ferramenta de compilação como o yarn. Pode utilizar novamente uma variável de ambiente e a Definição da Aplicação conforme pretendido.

3. Adicione whitenoise ao ficheiro requirements.txt . O Whitenoise (whitenoise.evans.io) é um pacote Python que facilita que uma aplicação django de produção sirva os seus próprios ficheiros estáticos. O Whitenoise serve especificamente os ficheiros que se encontram na pasta especificada pela variável Django STATIC_ROOT .

4. No ficheiro 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 ficheiros estáticos para aplicações Flask

Se a sua aplicação Web Flask incluir ficheiros de front-end estáticos, siga primeiro as instruções sobre a gestão de ficheiros estáticos na documentação do Flask. Para obter um exemplo de serviço de ficheiros estáticos numa aplicação Flask, veja a aplicação Flask de exemplo de início rápido no GitHub.

Para servir ficheiros estáticos diretamente a partir de uma rota na sua aplicação, pode utilizar 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 implementadas no Serviço de Aplicações, as aplicações Python são executadas num contentor do Docker do Linux definido no repositório do GitHub do Python Serviço de Aplicações. Pode encontrar as configurações da imagem nos diretórios específicos da versão.

Este contentor tem as seguintes características:

• As aplicações são executadas com o Servidor HTTP WSGI do Gunicorn, com os argumentos adicionais --bind=0.0.0.0 --timeout 600.

  • Pode fornecer definições de configuração para o Gunicorn ao personalizar o comando de arranque.

  • Para proteger a sua aplicação Web contra ataques DDOS acidentais ou deliberados, o Gunicorn é executado por trás de um proxy inverso Nginx, conforme descrito em Deploying Gunicorn (docs.gunicorn.org).

• Por predefinição, a imagem de contentor base inclui apenas a arquitetura Web Flask, mas o contentor suporta outras arquiteturas compatíveis com WSGI e compatíveis com o Python 3.6+, como o Django.

• Para instalar outros pacotes, como o Django, crie um ficheiro requirements.txt na raiz do projeto que especifica as suas dependências diretas. Serviço de Aplicações instala essas dependências automaticamente quando implementa o projeto.

  O ficheiro requirements.txttem de estar na raiz do projeto para que as dependências sejam instaladas. Caso contrário, o processo de compilação comunica o erro: "Não foi possível localizar setup.py ou requirements.txt; Não está a executar a instalação do pip." Se encontrar este erro, verifique a localização do ficheiro de requisitos.

• Serviço de Aplicações define automaticamente uma variável de ambiente denominada WEBSITE_HOSTNAME com o URL da aplicação Web, como msdocs-hello-world.azurewebsites.net. Também define WEBSITE_SITE_NAME com o nome da sua aplicação, como msdocs-hello-world.

• as Node.js e npm são instaladas no contentor para que possa executar ferramentas de compilação baseadas em Nós, como o yarn.

Processo de arranque do contentor

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

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

As secções seguintes 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 quiser um controlo mais específico sobre o comando de arranque, utilize um comando de arranque 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/back-end/config da raiz do projeto, utilize os argumentos --chdir knboard/backend config.wsgi.

Para ativar o registo de produção, adicione os --access-logfile parâmetros e --error-logfile , conforme mostrado nos exemplos para comandos de arranque personalizados.

Aplicação Flask

Para o Flask, Serviço de Aplicações procura um ficheiro com o nome application.py ou app.py e inicia o Gunicorn da seguinte forma:

# 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 da aplicação principal estiver contido num ficheiro diferente, utilize um nome diferente para o objeto da aplicação ou pretenda fornecer outros argumentos ao Gunicorn, utilize um comando de arranque personalizado.

Comportamento predefinido

Se o Serviço de Aplicações não encontrar um comando personalizado, uma aplicação Django ou uma aplicação Flask, executa uma aplicação só de leitura predefinida, localizada na pasta opt/defaultsite e apresentada na imagem seguinte.

Se implementou o código e ainda vir a aplicação predefinida, consulte Resolução de problemas – A aplicação não aparece.

Mais uma vez, se espera ver uma aplicação implementada em vez da aplicação predefinida, consulte Resolução de problemas – a aplicação não é apresentada.

Personalizar o comando de arranque

Pode controlar o comportamento de arranque do contentor ao fornecer um comando de arranque personalizado ou vários comandos num ficheiro de comando de arranque. Um ficheiro de comando de arranque pode utilizar o nome que escolher, como startup.sh, startup.cmd, startup.txt, etc.

Todos os comandos têm de utilizar caminhos relativos para a pasta raiz do projeto.

Para especificar um comando de arranque ou um ficheiro de comando:

• portal do Azure: selecione a página Configuração da aplicação e, em seguida, selecione Definições gerais. No campo Comando de Arranque , coloque o texto completo do comando de arranque ou o nome do ficheiro de comando de arranque. Em seguida, selecione Guardar para aplicar as alterações. Veja Configurar definições gerais para contentores linux.

• CLI do Azure: utilize o comando az webapp config set com o --startup-file parâmetro para definir o comando ou ficheiro de arranque:

  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 arranque ou pelo nome do ficheiro de comando de arranque.

Serviço de Aplicações ignora quaisquer erros que ocorram ao processar um comando ou ficheiro de arranque personalizado e, em seguida, continua o processo de arranque ao procurar aplicações Django e Flask. Se não vir o comportamento esperado, verifique se o comando ou ficheiro de arranque não tem erros e se é implementado um ficheiro de comando de arranque para Serviço de Aplicações juntamente com o código da aplicação. Também pode verificar os Registos de diagnóstico para obter mais informações. Verifique também a página Diagnosticar e resolver problemas da aplicação no portal do Azure.

Comandos de arranque de exemplo

• Argumentos do Gunicorn adicionados: o exemplo seguinte adiciona a --workers=4 uma linha de comandos gunicorn para iniciar uma aplicação 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, veja Executar o Gunicorn (docs.gunicorn.org). Se estiver a utilizar regras de dimensionamento automático para aumentar e reduzir verticalmente a sua aplicação Web, também deve definir dinamicamente o número de trabalhadores gunicorn com a NUM_CORES variável de ambiente no comando de arranque, por exemplo: --workers $((($NUM_CORES*2)+1)). Para obter mais informações sobre como definir o número recomendado de trabalhadores gunicorn, consulte as FAQ do Gunicorn

• Ativar o registo de produção do Django: adicione os --access-logfile '-' argumentos e --error-logfile '-' à linha de comandos:

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

  Estes registos serão apresentados na Serviço de Aplicações fluxo de registos.

  Para obter mais informações, veja Registo do Gunicorn (docs.gunicorn.org).

• Módulo principal do Flask Personalizado: por predefinição, Serviço de Aplicações parte do princípio de que o módulo principal de uma aplicação Flask é application.py ou app.py. Se o módulo principal utilizar um nome diferente, tem de personalizar o comando de arranque. 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
  

• Utilizar um servidor não Gunicorn: para utilizar um servidor Web diferente, como aiohttp, utilize o comando adequado como comando de arranque ou no ficheiro de comando de arranque:

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

Aceder às definições da aplicação como variáveis de ambiente

As definições da aplicação são valores armazenados na cloud especificamente para a sua aplicação, conforme descrito em Configurar definições da aplicação. Estas definições estão disponíveis para o código da aplicação como variáveis de ambiente e acedidas com o padrão os.environ padrão.

Por exemplo, se tiver criado uma definição de aplicação chamada DATABASE_SERVER, o seguinte código obtém o valor dessa definição:

db_server = os.environ['DATABASE_SERVER']

Detetar sessão HTTPS

No Serviço de Aplicações, a terminação TLS/SSL (wikipedia.org) ocorre nos balanceadores de carga de rede, pelo que todos os pedidos HTTPS chegam à sua aplicação como pedidos HTTP não encriptados. Se a lógica da aplicação precisar de verificar se os pedidos do utilizador estão encriptados ou não, 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

As arquiteturas Web populares permitem-lhe aceder às X-Forwarded-* informações no padrão de aplicação padrão. Por exemplo, no Django, pode utilizar o SECURE_PROXY_SSL_HEADER para dizer ao Django para utilizar o X-Forwarded-Proto cabeçalho.

Aceder aos registos de diagnósticos

Pode aceder aos registos da consola gerados a partir do contentor.

Primeiro, ative o registo de contentores ao executar 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 adequados para a sua aplicação Web.

Assim que o registo de contentores estiver ativado, execute o seguinte comando para ver o fluxo de registos:

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 parar a transmissão em fluxo de registos em qualquer altura, escreva Ctrl+C.

Também pode inspecionar os ficheiros de registo num browser em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para aceder aos registos através do portal do Azure, selecione Fluxo deRegisto de Monitorização> no menu do lado esquerdo da sua aplicação.

Registos de implementação do Access

Quando implementa o código, Serviço de Aplicações executa o processo de compilação descrito anteriormente na secção Personalizar automatização de compilação. Uma vez que a compilação é executada no seu próprio contentor, os registos de compilação são armazenados separadamente dos registos de diagnóstico da aplicação.

Utilize os seguintes passos para aceder aos registos de implementação:

1. No portal do Azure da sua aplicação Web, selecioneCentro de Implementação> no menu esquerdo.
2. No separador Registos , selecione o ID de Consolidação para a consolidação mais recente.
3. Na página Detalhes do registo apresentada, selecione a ligação Mostrar Registos... que aparece junto a "Executar compilação oryx...".

Os problemas de compilação, como dependências incorretas em requirements.txt e erros em scripts pré ou pós-compilação, serão apresentados nestes registos. Também são apresentados erros se o ficheiro de requisitos não tiver exatamente o nomerequirements.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 estiver ligado com êxito à sessão SSH, deverá ver a mensagem "LIGAÇÃO SSH ESTABELECIDA" na parte inferior da janela. Se vir erros como "SSH_CONNECTION_CLOSED" ou uma mensagem a indicar que o contentor está a reiniciar, poderá estar a impedir o início do contentor da aplicação. Veja Resolução de problemas para obter os passos para investigar possíveis problemas.

Resolução de problemas

Em geral, o primeiro passo na resolução de problemas é utilizar Serviço de Aplicações Diagnostics:

1. Na portal do Azure da sua aplicação Web, selecione Diagnosticar e resolver problemas no menu esquerdo.
2. Selecione Disponibilidade e Desempenho.
3. Examine as informações nas opções Registos de Aplicações, Falhas de Contentor e Problemas de Contentor , onde serão apresentados os problemas mais comuns.

Em seguida, examine os registos de implementação e os registos de aplicações para obter quaisquer mensagens de erro. Estes registos identificam frequentemente problemas específicos que podem impedir a implementação de aplicações ou o arranque de aplicações. Por exemplo, a compilação pode falhar se o ficheiro requirements.txt tiver o nome de ficheiro errado ou não estiver presente na pasta raiz do projeto.

As secções seguintes fornecem orientações para problemas específicos.

• A aplicação não é apresentada – a aplicação predefinida é apresentada
• A aplicação não aparece – mensagem "serviço indisponível"
• Não foi possível localizar setup.py ou requirements.txt
• ModuleNotFoundError no arranque
• A base de dados está bloqueada
• As palavras-passe não aparecem na sessão SSH quando são escritas
• Os comandos na sessão SSH parecem estar cortados
• Os recursos estáticos não aparecem numa aplicação django
• A Ligação SSL Fatal é Necessária

A aplicação não aparece

• Vê a aplicação predefinida depois de implementar o seu próprio código de aplicação. A aplicação predefinida é apresentada porque não implementou o código da aplicação para Serviço de Aplicações ou Serviço de Aplicações não conseguiu localizar o código da aplicação e executou a aplicação predefinida.

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

  • Utilize o SSH para ligar diretamente ao contentor Serviço de Aplicações e verificar se os seus ficheiros existem no site/wwwroot. Se os seus ficheiros não existirem, utilize os seguintes passos:

    1. Crie uma definição SCM_DO_BUILD_DURING_DEPLOYMENT de aplicação com o nome com o valor 1, reimplemente o seu código, aguarde alguns minutos e, em seguida, tente aceder novamente à aplicação. Para obter mais informações sobre como criar definições de aplicações, veja Configurar uma aplicação Serviço de Aplicações no portal do Azure.
    2. Reveja o processo de implementação, verifique os registos de implementação, corrija quaisquer erros e volte a implementar a aplicação.

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

• Verá a mensagem "Serviço Indisponível" no browser. O browser excedeu o limite de tempo à espera de uma resposta do Serviço de Aplicações, o que indica que Serviço de Aplicações iniciado o servidor Gunicorn, mas a aplicação em si não foi iniciada. Esta condição pode indicar que os argumentos do Gunicorn estão incorretos ou que existe um erro no código da aplicação.

  • Atualize o browser, especialmente se estiver a utilizar os escalões de preços mais baixos no seu Plano do Serviço de Aplicações. A aplicação poderá demorar mais tempo a iniciar quando utilizar, por exemplo, escalões gratuitos e responde depois de atualizar o browser.

  • 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 registo da aplicação para obter quaisquer mensagens de erro. Os registos mostrarão quaisquer erros no código da aplicação.

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

• O fluxo de registos mostra "Não foi possível localizar setup.py ou requirements.txt; Não está a executar a instalação do pip.": O processo de compilação do Oryx não conseguiu localizar o ficheiro requirements.txt .

  • Ligue-se ao contentor da aplicação Web através de SSH e verifique se requirements.txt tem o nome correto e existe diretamente no site/wwwroot. Se não existir, faça do site que o ficheiro existe no seu repositório e está incluído na sua implementação. Se existir numa pasta separada, mova-a para a raiz.

ModuleNotFoundError quando a aplicação é iniciada

Se vir um erro como ModuleNotFoundError: No module named 'example', o Python não conseguiu encontrar um ou mais dos seus módulos quando a aplicação começou. Este erro ocorre com mais frequência se implementar o ambiente virtual com o código. Os ambientes virtuais não são portáteis, pelo que um ambiente virtual não deve ser implementado com o código da aplicação. Em vez disso, permita que o Oryx crie um ambiente virtual e instale os pacotes na aplicação Web ao criar uma definição de aplicação, SCM_DO_BUILD_DURING_DEPLOYMENTe defini-la como 1. Esta definição irá forçar o Oryx a instalar os pacotes sempre que implementar no Serviço de Aplicações. Para obter mais informações, veja este artigo sobre portabilidade do ambiente virtual.

A base de dados está bloqueada

Ao tentar executar migrações de bases de dados com uma aplicação Django, poderá ver "sqlite3. OperationalError: a base de dados está bloqueada." O erro indica que a sua aplicação está a utilizar uma base de dados SQLite para a qual o Django está configurado por predefinição, em vez de utilizar uma base de dados na cloud, como o PostgreSQL para o Azure.

Verifique a DATABASES variável no ficheiro settings.py da aplicação para garantir que a sua aplicação está a utilizar uma base de dados na cloud em vez do SQLite.

Se encontrar este erro com o exemplo no Tutorial: Implementar uma aplicação Web Django com o PostgreSQL, verifique se concluiu os passos em Verificar definições de ligação.

Outros problemas

• As palavras-passe não aparecem na sessão SSH quando são escritas: por motivos de segurança, a sessão SSH mantém a palavra-passe oculta quando escreve. No entanto, os carateres estão a ser gravados, por isso escreva a sua palavra-passe como habitualmente e prima Enter quando terminar.

• Os comandos na sessão SSH parecem estar cortados: o editor pode não ter comandos de moldagem de palavras, mas devem continuar a ser executados corretamente.

• Os recursos estáticos não aparecem numa aplicação django: certifique-se de que ativou o módulo whitenoise

• Verá a mensagem "A Ligação SSL Fatal é Necessária": Verifique todos os nomes de utilizador e palavras-passe utilizados para aceder a recursos (como bases de dados) a partir da aplicação.

Mais recursos

• Tutorial: aplicação Python com PostgreSQL
• Tutorial: Implementar a partir do repositório de contentor privado
• FAQ do Serviço de Aplicações no Linux
• Referência de variáveis de ambiente e definições da aplicação