Django deployen, ohne von Hand ein Procfile zu schreiben

Eine Django-App weiß bereits fast alles, was ein Host braucht, um sie zu betreiben: requirements.txt sagt, ob Celery existiert, psycopg sagt, dass sie Postgres braucht, manage.py sagt, was zu migrieren ist. Das meiste PaaS-Onboarding fragt trotzdem nach dieser Information, als Config-Datei oder Dashboard-Formular – ein zweiter Ort, an dem sie aus dem Takt mit dem tatsächlichen Code geraten kann.

Was erkannt wird, statt konfiguriert

Django selbst wird aus requirements.txt, pyproject.toml oder einem manage.py, das es importiert, erkannt – kein Framework-Flag zu setzen.
python manage.py migrate --no-input läuft als Release-Schritt, bevor die neue Version Traffic erhält.
python manage.py collectstatic --noinput läuft automatisch im Build-Schritt – dieselbe Konvention, die Herokus Python-Buildpack verwendete, sodass WhiteNoise oder jedes STATIC_ROOT-Setup einfach funktioniert, ohne eine Dockerfile-Zeile hinzuzufügen. Eine App, die django.contrib.staticfiles nicht nutzt, ist davon einfach unberührt.
psycopg in den Abhängigkeiten stellt Postgres bereit und injiziert DATABASE_URL; ein Redis-Client (redis, django-redis, rq) macht dasselbe für REDIS_URL.
Celery, Celery Beat, RQ, Huey, Dramatiq und Django-Q werden jeweils automatisch als Worker-Prozess angeboten, wenn sie eine Abhängigkeit sind – nicht etwas, das man von Grund auf in ein Procfile verdrahten muss.

railyard create my-app https://github.com/me/my-app --addons postgres,redis

oder dieselbe URL ins Dashboard eingefügt, sobald GitHub verbunden ist.

Prozesse, auf die 12-Factor-Art

web, worker und ein geplanter beat-Prozess sind derselbe Build, jeweils mit einem anderen Befehl gestartet – nicht drei separate Apps, die man von Hand synchron halten muss:

web:    gunicorn myproject.wsgi:application --bind 0.0.0.0:$PORT
worker: celery -A myproject worker --loglevel=info
beat:   celery -A myproject beat --loglevel=info

Lass das Procfile ganz weg, und die Erkennung bietet den Worker von sich aus an, basierend darauf, welche Job-Library schon eine Abhängigkeit ist. Skaliere jeden davon unabhängig:

railyard scale my-app worker=2

Das eine, das es wert ist, vor dem ersten Deploy zu prüfen

Gunicorns Standardannahme ist ein WSGI-Modul unter wsgi:application – wenn das Projektlayout es anderswo platziert, ist das die eine Zeile, die es sich lohnt, explizit im Startbefehl zu setzen, statt sich auf die Vermutung zu verlassen. Alles andere danach (Migrationen, statische Dateien, Worker) folgt automatisch, sobald der Web-Prozess tatsächlich startet.

Config und Secrets

DJANGO_SETTINGS_MODULE, SECRET_KEY und jedes Feature-Flag leben unter Variables, oder railyard env:set my-app KEY=VALUE – reine Umgebungsvariablen, nicht ins Image eingebacken, sodass derselbe Build unverändert von Staging bis Produktion läuft. DATABASE_URL und REDIS_URL lösen pro Umgebung automatisch aus dem auf, was auf der Canvas angehängt ist.

Vollständige Referenz: Django-Docs, Workers und geplante Jobs.