Jak wdrażasz aplikację Django na produkcję?

Question

Accepted Answer

Wdrażanie Django na produkcję wymaga uruchomienia jej za właściwym serwerem **WSGI/ASGI** i **serwerem sieciowym**, prawidłowego serwowania plików statycznych, zabezpieczenia ustawień i zarządzania bazą danych — znacznie różni się to od wbudowanego serwera deweloperskiego (który **nie jest** przeznaczony do produkcji).

## Stos produkcyjny

```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).
```

Serwer deweloperski jest nieodpowiedni do produkcji. Standardowy stos: **serwer aplikacji** (Gunicorn/uWSGI dla WSGI, Uvicorn dla ASGI/async) uruchamia Django z wieloma workerami, za **serwerem sieciowym** (nginx), który obsługuje przychodzące połączenia, TLS i pliki statyczne.

## Ustawienia produkcyjne (krytyczne dla bezpieczeństwa)

```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
```

## Pliki statyczne

```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)
```

## Baza danych i migracje

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

## Typowa lista kontrolna wdrażania

```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
```

## Nowoczesne podejścia do wdrażania

```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)
```

## Dlaczego to ważne

Poprawne wdrażanie Django na produkcję jest niezbędną wiedzą do przenoszenia aplikacji z rozwoju do rzeczywistego użytku i obejmuje ważne rozważania, które fundamentalnie różnią się od lokalnego rozwoju — błędy prowadzą do luk bezpieczeństwa, słabej wydajności lub uszkodzonych aplikacji.

Zrozumienie **stosu produkcyjnego** jest podstawowe: wbudowany serwer deweloperski (`runserver`) wyraźnie nie jest przeznaczony do produkcji (jest jednowątkowy, niezabezpieczony i nie potrafi radzić sobie z obciążeniem), więc musisz uruchomić Django za właściwym **serwerem aplikacji** (Gunicorn/uWSGI dla WSGI, lub Uvicorn dla ASGI/async) z wieloma workerami, przed którym stoi **serwer sieciowy** (nginx) obsługujący połączenia, TLS i serwowanie plików statycznych.

Kilka aspektów jest kryticznych dla bezpieczeństwa i poprawności: **ustawienia produkcyjne** (szczególnie `DEBUG=False`, które jest obowiązkowe, ponieważ `DEBUG=True` ujawnia wrażliwe ślady i konfigurację atakującym, plus `ALLOWED_HOSTS`, tajny `SECRET_KEY` ze zmiennych środowiska i wymuszenie HTTPS), **obsługa plików statycznych** (uruchomienie `collectstatic` i serwowanie plików przez nginx/CDN/WhiteNoise, ponieważ Django nie serwuje ich samodzielnie na produkcji — częsty błąd wdrażania), i **zarządzanie bazą danych** (rzeczywista baza danych jak PostgreSQL, stosowanie migracji, kopie zapasowe).

Znajomość listy kontrolnej wdrażania, nowoczesnych podejść (Docker/kontenery, zarządzane platformy, magazyn w chmurze dla mediów, workery Celery jako oddzielne usługi, skalowanie horyzontalne ze staną aplikacją) i zagadnień operacyjnych (logowanie, monitoring z Sentry, health checki, zarządzanie procesami) to to, co odróżnia działające wdrażanie produkcyjne od kruchego lub niezabezpieczonego.

Ponieważ każda rzeczywista aplikacja Django musi ostatecznie być wdrożona, a błędy wdrażania (pozostawienie `DEBUG=True`, nieprawidłowa obsługa plików statycznych, ujawnienie sekretów, użycie serwera deweloperskiego) powodują rzeczywiste problemy z bezpieczeństwem i niezawodnością, zrozumienie, jak prawidłowo wdrażać Django — stos, ustawienia krytyczne dla bezpieczeństwa, obsługa plików statycznych/mediów i nowoczesne praktyki wdrażania — jest ważną, wysokostawkową wiedzą, która odzwierciedla zdolność do dostarczania aplikacji gotowych do produkcji, a temat często istotny i zawodowo niezbędny dla każdego deweloperów Django odpowiedzialnego za systemy live'owe.