Как развернуть приложение Django в production?

Question

Accepted Answer

Развёртывание Django в production предполагает запуск его за полноценным **WSGI/ASGI сервером** и **веб-сервером**, корректное обслуживание статических файлов, защиту параметров конфигурации и управление базой данных — что существенно отличается от встроенного сервера разработки (который **не предназначен** для production).

## Production-стек

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

Встроенный сервер разработки непригоден для production. Стандартный стек: **сервер приложений** (Gunicorn/uWSGI для WSGI, Uvicorn для ASGI/async) запускает Django с несколькими рабочими процессами, позади **веб-сервера** (nginx), который обрабатывает входящие соединения, TLS и статические файлы.

## Production-параметры (критичны для безопасности)

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

## Статические файлы

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

## База данных и миграции

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

## Типовой чек-лист развёртывания

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

## Современные подходы к развёртыванию

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

## Почему это важно

Правильное развёртывание Django в production — это критически важный навык, необходимый для запуска приложений в реальном мире. Развёртывание существенно отличается от локальной разработки, и ошибки приводят к уязвимостям безопасности, плохой производительности или неработающим приложениям.

Понимание **production-стека** — это основополагающий навык: встроенный сервер разработки (`runserver`) явно не предназначен для production (он однопоточный, небезопасный и не может обработать нагрузку), поэтому Django должен запускаться за полноценным **сервером приложений** (Gunicorn/uWSGI для WSGI или Uvicorn для ASGI/async) с несколькими рабочими процессами, перед **веб-сервером** (nginx), обрабатывающим соединения, TLS и обслуживание статических файлов.

Несколько аспектов критичны для безопасности и корректности работы: **параметры production** (особенно `DEBUG=False`, что обязательно, так как `DEBUG=True` раскрывает чувствительные traceback'и и конфигурацию злоумышленникам, плюс `ALLOWED_HOSTS`, секретный `SECRET_KEY` из переменных окружения и принудительное использование HTTPS), **обработка статических файлов** (запуск `collectstatic` и обслуживание файлов через nginx/CDN/WhiteNoise, так как Django не обслуживает их сам в production — это частая причина ошибок развёртывания), и **управление базой данных** (настоящая БД типа PostgreSQL, применение миграций, резервные копии).

Знание чек-листа развёртывания, современных подходов (Docker/контейнеры, управляемые платформы, облачное хранилище для медиафайлов, отдельные сервисы Celery workers, горизонтальное масштабирование с stateless-приложением) и операционных аспектов (логирование, мониторинг через Sentry, health checks, управление процессами) отделяет работающее production-развёртывание от хрупкого или небезопасного.

Поскольку каждое реальное приложение Django в итоге должно быть развёрнуто, а ошибки при развёртывании (оставленный `DEBUG=True`, неправильная обработка статических файлов, раскрытие секретов, использование сервера разработки) приводят к реальным проблемам безопасности и надёжности, понимание того, как правильно развёртывать Django — стек, критичные для безопасности параметры, обработка статических/медиафайлов и современные практики развёртывания — это важный, высокостоимостный навык, который демонстрирует способность запускать production-ready приложения. Это часто релевантная и профессионально-необходимая тема для любого Django-разработчика, ответственного за работающие системы.