Faça deploy de Django na Nodion

Faça deploy de Django passo a passo

1. Adicione o Gunicorn, o WhiteNoise e um driver de base de dados A Nodion arranca o Gunicorn, mas não o instala, por isso tem de estar nas suas dependências. O Gunicorn não serve ficheiros estáticos; é o WhiteNoise que serve o que o collectstatic escreve. Fixe a versão de Python em .python-version, porque um intervalo como requires-python = ">=3.10" escolhe a versão mais recente. requirements.txt

   Django>=5.2
   gunicorn
   whitenoise
   dj-database-url
   psycopg[binary]

2. Leia as definições a partir do ambiente O collectstatic é executado durante o build, onde só existem as variáveis marcadas com Build, por isso as definições têm de poder ser importadas sem os segredos de runtime. O Django só verifica a SECRET_KEY quando é usada. Adicione o WhiteNoise logo a seguir ao SecurityMiddleware. settings.py

   import os
   import dj_database_url
   
   SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", "")
   DEBUG = os.environ.get("DJANGO_DEBUG") == "1"
   ALLOWED_HOSTS = os.environ.get("DJANGO_ALLOWED_HOSTS", "").split(",")
   CSRF_TRUSTED_ORIGINS = [f"https://{h}" for h in ALLOWED_HOSTS if h]
   
   DATABASES = {"default": dj_database_url.config(conn_max_age=600)}
   
   STATIC_ROOT = BASE_DIR / "staticfiles"
   # MIDDLEWARE: "whitenoise.middleware.WhiteNoiseMiddleware"
   # right after "django.middleware.security.SecurityMiddleware"

3. Responda ao health check antes da verificação do host O health check da Nodion chama cada instância pelo seu endereço interno, que não está em ALLOWED_HOSTS, por isso o Django responderia 400 e a release nunca entraria em produção. Coloque um pequeno middleware em primeiro lugar em MIDDLEWARE e defina /healthz como caminho do health check nas definições da aplicação. health.py

   from django.http import HttpResponse
   
   
   class HealthCheckMiddleware:
       def __init__(self, get_response):
           self.get_response = get_response
   
       def __call__(self, request):
           if request.path == "/healthz":
               return HttpResponse("ok")
           return self.get_response(request)

4. Execute as migrações em cada deploy Uma linha release: num Procfile é executada 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: python manage.py migrate --noinput

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 DJANGO_SECRET_KEY como segredo e DJANGO_ALLOWED_HOSTS com o hostname da sua aplicação e os seus próprios domínios, e depois faça push.

A ter em conta

• Celery e outros workersAdicione worker: celery -A myproject worker ao Procfile, juntamente com uma linha explícita web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT; 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 como broker.
• ASGIO comando de arranque por omissão usa WSGI. Para Channels ou views assíncronas, defina a sua própria linha web:, por exemplo com workers Uvicorn, e ponha o servidor a escutar em 0.0.0.0:$PORT.
• Ficheiros de dependênciasrequirements.txt, poetry.lock e Pipfile.lock são instalados tal como estão. Um Pipfile sem o respetivo lockfile não instala nada.

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.

Django na Nodion: perguntas e respostas