Django auf Nodion deployen

Django Schritt für Schritt deployen

1. Gunicorn, WhiteNoise und einen Datenbanktreiber hinzufügen Nodion startet Gunicorn, installiert es aber nicht, es gehört also in deine Dependencies. Gunicorn liefert keine statischen Dateien aus; das übernimmt WhiteNoise für alles, was collectstatic schreibt. Pinne die Python-Version in .python-version, denn ein Bereich wie requires-python = ">=3.10" nimmt das neueste Release. requirements.txt

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

2. Settings aus der Umgebung lesen collectstatic läuft im Build, dort gibt es nur Variablen mit dem Häkchen Build, die Settings müssen sich also ohne Laufzeit-Secrets importieren lassen. Django prüft SECRET_KEY erst, wenn er gebraucht wird. WhiteNoise kommt direkt hinter 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. Health Check vor der Host-Prüfung beantworten Der Health Check von Nodion ruft jede Instanz über ihre interne Adresse auf, die nicht in ALLOWED_HOSTS steht; Django würde mit 400 antworten, und das Release ginge nie live. Setz eine kleine Middleware an die erste Stelle von MIDDLEWARE und trag in den App-Einstellungen /healthz als Health-Check-Pfad ein. 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. Migrationen bei jedem Deploy ausführen Eine release:-Zeile in einer Procfile läuft bei jedem Build einmal, nach dem Build und bevor die neue Version startet. Scheitert sie, stoppt der Deploy und die laufende Version bleibt live. Procfile

   release: python manage.py migrate --noinput

5. App und Datenbank anlegen Lege eine Application aus deinem Repository in der Region EU Central an, dann eine PostgreSQL-Datenbank in derselben Region, und hänge sie auf dem Tab Environment an: Sie kommt beim nächsten Deploy als DATABASE_URL an. Setz DJANGO_SECRET_KEY als Secret und DJANGO_ALLOWED_HOSTS auf den Hostnamen der App und deine eigenen Domains, dann pushen.

Gut zu wissen

• Celery und andere WorkerErgänz die Procfile um worker: celery -A myproject worker und eine ausdrückliche Zeile web: gunicorn myproject.wsgi --bind 0.0.0.0:$PORT; ohne web:-Zeile wird der erste Procfile-Eintrag außer release: zum Standardbefehl. Dann legst du auf dem Tab Processes einen Prozess worker ohne Port an. Valkey in derselben Region liefert dir REDIS_URL als Broker.
• ASGIDer Standard-Startbefehl ist WSGI. Für Channels oder async Views setzt du eine eigene web:-Zeile, etwa mit Uvicorn-Workern, und bindest sie an 0.0.0.0:$PORT.
• Dependency-Dateienrequirements.txt, poetry.lock und Pipfile.lock werden so installiert, wie sie sind. Eine Pipfile ohne Lock-Datei installiert nichts.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Heroku-Alternativen mit EU-Hosting: 5 Optionen im Vergleich Eine deutsche Plattform und US-Clouds mit EU-Regionen, verglichen nach Sitz, Regionen und Managed Databases.
• Preview-Environments erklärt: eine App pro Pull Request Eine laufende Kopie deiner App für jeden Pull Request: wofür Preview-Environments gut sind, wo es knifflig wird und wie Nodion sie handhabt.

Django auf Nodion: Fragen und Antworten