Как сконфигурировать Docker и Docker Compose для Django приложения

Что проверяют

Понимаете ли вы разницу между «запустилось у меня» и конфигурацией, которую не стыдно выкатить: слои образа, секреты, готовность базы, статика. Следом обычно спрашивают, как вы запускаете миграции и чем dev-окружение отличается от прода.

Как отвечать

В Dockerfile:

• базовый образ: python:3.12-slim или новее. Переменные PYTHONDONTWRITEBYTECODE=1 и PYTHONUNBUFFERED=1, чтобы логи шли сразу;
• кэш слоёв: сначала COPY requirements.txt и установка зависимостей, потом код. Правка кода не переустанавливает пакеты;
• сервер: gunicorn project.wsgi:application --bind 0.0.0.0:8000, для ASGI с воркерами uvicorn. runserver только для разработки;
• безопасность: непривилегированный пользователь, .dockerignore, чтобы .git, .env и venv не попали в образ;
• статика: collectstatic на сборке, отдача через WhiteNoise или nginx.

В compose.yaml:

• сервисы: web, db на postgres:17, при необходимости redis и воркер Celery;
• ключ version: не нужен, docker compose его игнорирует и предупреждает об этом;
• секреты: через env_file или переменные окружения, в settings.py читаются из os.environ. Хост базы это имя сервиса db, а не localhost;
• готовность базы: у db healthcheck на pg_isready, у web depends_on с condition: service_healthy;
• данные: Postgres пишет в именованный том.

Миграции отдельной командой: docker compose run --rm web python manage.py migrate. Для разработки рядом кладут compose.override.yaml с bind mount кода и runserver, в проде его нет.

Где спотыкаются

Пишут depends_on без healthcheck и удивляются, что Django падает на старте: контейнер базы запущен, но Postgres ещё не принимает соединения.

Оставляют DEBUG=True, runserver и пароль открытым текстом в compose.yaml, который лежит в git.

Берут устаревшие образы вроде python:3.9 или postgres:13, у которых поддержка уже закончилась.