Faça deploy de Flask na Nodion

Faça deploy de Flask passo a passo

1. Adicione o Gunicorn às suas dependências A Nodion arranca o Gunicorn, mas não o instala, por isso inclua-o junto do Flask. Fixe a versão de Python em .python-version, porque um intervalo em pyproject.toml escolhe a versão mais recente. requirements.txt

   flask
   gunicorn

2. Mantenha o objeto app em app.py A Nodion usa o primeiro de app.py, application.py e wsgi.py que contenha Flask e executa gunicorn <ficheiro>:app com 3 workers na porta PORT que define. O objeto tem de se chamar app. app.py

   from flask import Flask
   
   app = Flask(__name__)
   
   
   @app.get("/")
   def index():
       return "Hello from Frankfurt"

3. Usa uma app factory? Adicione uma linha web Com create_app() não existe um app ao nível do módulo para encontrar, por isso indique ao Gunicorn, num Procfile, que deve chamar a factory. Esta linha substitui o comando de arranque por omissão. Procfile

   web: gunicorn "myapp:create_app()" --bind 0.0.0.0:$PORT --workers 3

4. Execute as migrações em cada deploy Com o Flask-Migrate, uma linha release: executa flask db upgrade uma vez por build, depois do build e antes de a nova versão arrancar. Se falhar, o deploy é interrompido e a versão em execução continua online. Procfile

   release: flask --app myapp db upgrade

5. Crie a aplicação e a base de dados Crie uma aplicação a partir do seu repositório na região EU Central, depois uma base de dados PostgreSQL na mesma região, e associe-a no separador Environment: chega como DATABASE_URL no deploy seguinte. Defina a sua SECRET_KEY como variável secreta, leia-a com os.environ e depois faça push.

A ter em conta

• DATABASE_URL e SQLAlchemyA DATABASE_URL da Nodion começa por postgres://, que o SQLAlchemy 1.4 e versões posteriores não aceitam. Substitua o esquema antes de a passar: postgresql:// para psycopg2, postgresql+psycopg:// para psycopg 3.
• Health checkO tráfego muda assim que / responde com 2xx ou 3xx, por isso um redirecionamento para uma página de início de sessão serve. Se / devolver 401 ou 404, adicione uma rota como /healthz e defina-a como caminho do health check nas definições da aplicação.
• Workers Celery e RQAdicione worker: celery -A myapp worker ao Procfile, juntamente com uma linha explícita web: gunicorn app:app --bind 0.0.0.0:$PORT --workers 3; sem uma linha web:, a primeira entrada do Procfile que não seja release: passa a ser o comando por omissão. Depois, no separador Processes, adicione um processo chamado worker sem porta. O Valkey na mesma região fornece-lhe REDIS_URL.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Para saber mais

• Alternativas ao Heroku com alojamento na UE: 5 opções Uma plataforma alemã e clouds norte-americanas com regiões na UE, comparadas por sede, regiões e bases de dados geridas.
• Ambientes de pré-visualização: uma aplicação por pull request Uma cópia em execução da sua aplicação para cada pull request: para que servem os ambientes de pré-visualização, onde se complicam e como a Nodion os gere.

Flask na Nodion: perguntas e respostas