Wie deployest du eine Django-Anwendung in der Produktion?

Question

Accepted Answer

Das Deployment von Django in der Produktion erfordert die Ausführung hinter einem angemessenen **WSGI/ASGI-Server** und **Web-Server**, die korrekte Bereitstellung statischer Dateien, die Sicherung von Einstellungen und die Verwaltung der Datenbank — ganz anders als der integrierte Entwicklungsserver (der **nicht** für die Produktion geeignet ist).

## Der Production Stack

```text
Client → NGINX (web server) → GUNICORN (WSGI app server) → DJANGO
           │                      (runs your Python app, multiple workers)
           └─ serves static/media files directly (efficient)

❌ NEVER use `python manage.py runserver` in production — it's single-threaded,
   insecure, and not built for load. Use Gunicorn (WSGI) or Uvicorn (ASGI for async).
```

Der Entwicklungsserver ist für die Produktion ungeeignet. Der Standard-Stack: ein **Application Server** (Gunicorn/uWSGI für WSGI, Uvicorn für ASGI/async) führt Django mit mehreren Workern aus, hinter einem **Web-Server** (nginx), der eingehende Verbindungen, TLS und statische Dateien verwaltet.

## Production Settings (sicherheitskritisch)

```python
DEBUG = False                            # ❗ MUST be False — DEBUG=True leaks sensitive info
ALLOWED_HOSTS = ["example.com"]          # required when DEBUG=False
SECRET_KEY = os.environ["SECRET_KEY"]    # from the environment, NOT committed
SECURE_SSL_REDIRECT = True               # force HTTPS
SESSION_COOKIE_SECURE = True
SECURE_HSTS_SECONDS = 31536000
```

## Statische Dateien

```bash
python manage.py collectstatic           # gather static files into STATIC_ROOT
# then serve them via nginx or a CDN — or use WhiteNoise to serve them from the app
# (Django does NOT serve static files itself in production)
```

## Datenbank und Migrationen

```bash
python manage.py migrate                  # apply migrations to the production DB
# use a real database (PostgreSQL), connection pooling, regular backups
```

## Eine typische Deployment-Checkliste

```text
1. Set production environment variables (SECRET_KEY, DB credentials, DEBUG=False)
2. Run migrations (manage.py migrate)
3. Collect static files (collectstatic) → serve via nginx/CDN/WhiteNoise
4. Run the app with Gunicorn/Uvicorn (multiple workers, behind nginx)
5. Enable HTTPS (TLS certificates, e.g. Let's Encrypt)
6. Set up logging, error monitoring (Sentry), health checks
7. Add a process manager (systemd/supervisor) or use containers (Docker) + orchestration
8. Run `manage.py check --deploy` to audit security settings
```

## Moderne Deployment-Ansätze

```text
✓ Containers (Docker) + orchestration (Kubernetes) or platforms (Heroku, Railway, Render)
✓ Managed databases, separate static/media storage (S3 + CDN)
✓ Background workers (Celery) + a broker (Redis) as separate services
✓ Horizontal scaling: multiple app instances behind a load balancer (keep app STATELESS)
```

## Warum es wichtig ist

Das korrekte Deployment von Django in der Produktion ist grundlegendes Wissen, um Anwendungen von der Entwicklung zur realen Nutzung zu bringen, und es umfasst wichtige Überlegungen, die sich grundlegend von der lokalen Entwicklung unterscheiden — Fehler führen zu Sicherheitslücken, schlechter Leistung oder fehlerhaften Anwendungen.

Das Verständnis des **Production Stack** ist grundlegend: Der integrierte Entwicklungsserver (`runserver`) ist ausdrücklich nicht für die Produktion geeignet (er ist single-threaded, unsicher und kann keine Last verarbeiten), daher musst du Django hinter einem angemessenen **Application Server** (Gunicorn/uWSGI für WSGI oder Uvicorn für ASGI/async) mit mehreren Workern ausführen, der von einem **Web-Server** (nginx) verwaltet wird, der Verbindungen, TLS und die Bereitstellung statischer Dateien handhabt.

Mehrere Aspekte sind sicherheits- und korrektheitskritisch: **Production Settings** (insbesondere `DEBUG=False`, das obligatorisch ist, da `DEBUG=True` sensible Tracebacks und Konfigurationen gegenüber Angreifern offenlegt, plus `ALLOWED_HOSTS`, ein geheimer `SECRET_KEY` aus der Umgebung und HTTPS-Erzwingung), **Static-File-Handling** (das Ausführen von `collectstatic` und die Bereitstellung von Dateien über nginx/CDN/WhiteNoise, da Django diese in der Produktion nicht selbst bereitstellt — ein häufiger Deployment-Fehler), und **Datenbankverwaltung** (eine echte Datenbank wie PostgreSQL, Anwendung von Migrationen, Backups).

Die Kenntnis der Deployment-Checkliste, moderner Ansätze (Docker/Container, verwaltete Plattformen, Cloud-Speicher für Medien, Celery-Worker als separate Services, horizontale Skalierung mit einer zustandslosen App) und operativer Bedenken (Logging, Monitoring mit Sentry, Health Checks, Process Management) ist das, was ein funktionierendes Production Deployment von einem fragilen oder unsicheren unterscheidet.

Weil jede echte Django-Anwendung irgendwann deployed werden muss und weil Deployment-Fehler (mit `DEBUG=True` belassen, fehlerhafte Handhabung statischer Dateien, Offenlegen von Secrets, Verwendung des Entwicklungsservers) echte Sicherheits- und Zuverlässigkeitsprobleme verursachen, ist das Verständnis, wie man Django ordnungsgemäß deployed — der Stack, die sicherheitskritischen Einstellungen, statische/Media-Handhabung und moderne Deployment-Praktiken — wichtiges, hochriskantes Wissen, das die Fähigkeit widerspiegelt, produktionsreife Anwendungen bereitzustellen, ein häufig relevantes und beruflich wesentliches Thema für jeden Django-Entwickler, der für Live-Systeme verantwortlich ist.