Configurar um arquivo de inicialização personalizado para aplicativos Python no Serviço de Aplicativo do Azure

Neste artigo, você aprenderá quando e como configurar um arquivo de inicialização personalizado para um aplicativo Web Python hospedado no Serviço de Aplicativo do Azure. Embora um ficheiro de arranque não seja necessário para desenvolvimento local, o Serviço de Aplicações do Azure executa a sua aplicação web implementada dentro de um contentor Docker que pode usar comandos de arranque se os fornecer.

Você precisa de um arquivo de inicialização personalizado nas seguintes situações:

• Argumentos Gunicorn personalizados: Você deseja iniciar o servidor web padrão Gunicorn com argumentos extras além de seus padrões, que são --bind=0.0.0.0 --timeout 600.

• Frameworks ou Servidores Alternativos: A tua aplicação é construída com uma framework diferente do Flask ou Django, ou queres usar um servidor web diferente em vez do Gunicorn.

• Estrutura de Aplicação Não Padrão do Flask: Tem uma aplicação Flask cujo ficheiro de código principal tem um nome diferente de app.py ou application.py, ou o objeto da aplicação tem um nome diferente de app.

Ou seja, precisa de um comando de arranque personalizado, a menos que o seu projeto tenha um ficheiro app.py ou application.py na pasta raiz com um objeto de aplicação Flask chamado app.

Para obter mais informações, consulte Configurar aplicativos Python - processo de inicialização de contêiner.

Pré-requisitos

Antes de configurar um ficheiro de arranque personalizado, é necessário ter um App Service no Linux existente a executar Python. Para criar um App Service, siga o guia de início rápido do Python para o App Service. Também pode criar um App Service com a CLI do Azure:

az webapp create --resource-group <group> --plan <plan> --name <app-name> --runtime "PYTHON:3.12"

Criar um arquivo de inicialização

Quando precisar de um arquivo de inicialização personalizado, use as seguintes etapas:

1. Crie um arquivo em seu projeto chamado startup.txt, startup.sh ou outro nome de sua escolha que contenha seus comandos de inicialização. Consulte as seções posteriores deste artigo para obter detalhes sobre Django, Flask e outras estruturas.

   Um arquivo de inicialização pode incluir vários comandos, se necessário.

2. Comprometa o arquivo em seu repositório de código para que ele possa ser implantado com o restante do aplicativo.

3. No Visual Studio Code, selecione o ícone do Azure na Barra de Atividades, expanda RECURSOS, localize e expanda sua assinatura, expanda Serviços de Aplicativo, clique com o botão direito do mouse no Serviço de Aplicativo e selecione Abrir no Portal.

4. No portal do Azure, no menu de serviço à esquerda, escolhaConfiguração de Configurações>. Na página Configuração do App Service, selecione Definições gerais, introduza o nome do seu ficheiro de arranque (como startup.txt ou startup.sh) em Definições da pilha>Comando de arranque e, em seguida, selecione Guardar.

   Em alternativa, pode usar a CLI do Azure para definir o comando de arranque:

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

   Observação

   Em vez de usar um arquivo de comando de inicialização, você pode colocar o próprio comando de inicialização diretamente no campo Comando de Inicialização no portal do Azure. O uso de um arquivo de comando de inicialização é recomendado porque ele armazena sua configuração no repositório. Isso permite que o controle de versão controle as alterações e simplifica a reimplantação em outras instâncias do Serviço de Aplicativo do Azure.

5. Selecione Continuar quando solicitado a reiniciar o Serviço de Aplicativo.

   Se você acessar o site do Serviço de Aplicativo do Azure antes de implantar o código do aplicativo, um "Erro do aplicativo" será exibido porque nenhum código está disponível para processar a solicitação.

Comandos de inicialização do Django

Por padrão, o Serviço de Aplicativo do Azure localiza a pasta que contém seu arquivo de wsgi.py e inicia o Gunicorn com o seguinte comando:

# <module> is the folder that contains wsgi.py. If you need to use a subfolder,
# specify the parent of <module> using --chdir.
gunicorn --bind=0.0.0.0 --timeout 600 <module>.wsgi

Se quiseres modificar algum argumento do Gunicorn, como aumentar o valor de timeout para 1.200 segundos (),--timeout 1200 cria um ficheiro de comando de arranque personalizado. Este método sobrepõe as definições padrão com os seus requisitos específicos. Para obter mais informações, consulte Processo de inicialização de contêiner - aplicativo Django.

Comandos de arranque do Flask

Por defeito, o Serviço de Aplicações no Linux assume que a sua aplicação Flask cumpre os seguintes critérios:

• O WSGI chamável é chamado app.
• O código do aplicativo está contido em um arquivo chamado application.py ou app.py.
• O arquivo do aplicativo está localizado na pasta raiz do aplicativo.

Se o seu projeto difere desta estrutura, o seu comando de arranque personalizado deve identificar a localização do objeto da aplicação no ficheiro de formato:app_object:

• Nome de arquivo diferente e/ou nome de objeto do aplicativo: se o arquivo de código principal do aplicativo estiver hello.py e o objeto do aplicativo for nomeado myapp, o comando de inicialização será o seguinte:

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

• O ficheiro de arranque está numa subpasta: Se o ficheiro de arranque for myapp/website.py e o objeto da aplicação for app, use o argumento --chdir do Gunicorn para indicar a pasta e, em seguida, indique o ficheiro de arranque e o objeto da aplicação como habitualmente:

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

• O arquivo de inicialização está dentro de um módulo: No código python-sample-vscode-flask-tutorial , o arquivo de inicialização webapp.py está contido na pasta hello_app, que é em si um módulo com um arquivo __init__.py . O objeto app é nomeado app e definido em __init__.py. webapp.py usa uma importação relativa.

  Devido a esse arranjo, apontar Gunicorn para webapp:app produz o erro, "Tentativa de importação relativa em não-pacote", e o aplicativo não consegue iniciar.

  Nessa situação, crie um arquivo de shim que importe o objeto de aplicativo do módulo e, em seguida, faça com que o Gunicorn inicie o aplicativo usando o shim. O código python-sample-vscode-flask-tutorial , por exemplo, contém startup.py com o seguinte conteúdo:

  from hello_app.webapp import app
  

  O comando de inicialização é:

  gunicorn --bind=0.0.0.0 --workers=4 startup:app
  

Para obter mais informações, consulte Processo de inicialização do contêiner - aplicativo Flask.

Outros frameworks e servidores web

O contêiner do Serviço de Aplicativo que executa aplicativos Python tem o Django e o Flask instalados por padrão, juntamente com o servidor Web Gunicorn.

Para usar um framework diferente do Django ou Flask (como Falcon, FastAPI e outros), ou para usar um servidor web diferente:

• Inclua o framework e o servidor web no seu ficheirorequirements.txt .

• No comando de inicialização, identifique a função chamável WSGI conforme descrito na seção anterior para Flask.

• Para iniciar um servidor web diferente do Gunicorn, use um python -m comando em vez de invocar o servidor diretamente. Por exemplo, o comando a seguir inicia o servidor uvicorn , supondo que o WSGI chamável seja nomeado app e encontrado em application.py:

  python -m uvicorn application:app --host 0.0.0.0
  

  Usa python -m porque os servidores web instalados através de requirements.txt não são adicionados ao ambiente global Python e, portanto, não podem ser invocados diretamente. O python -m comando invoca o servidor de dentro do ambiente virtual atual.

Implante seu aplicativo

Depois de configurar o ficheiro de arranque, precisa de implementar o código da aplicação no App Service. Use a CLI do Azure ou o método de implementação que preferir:

az webapp up --name <app-name>

Para mais opções de implementação, consulte Melhores práticas de implementação.