Приходилось ли писать Docker файлы и работать с контейнерами

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

Писали ли вы Dockerfile руками или только запускали чужие контейнеры. За вопросом стоит проверка понимания слоёв и кэша сборки, умения собрать воспроизводимое питоновское окружение и знания, чем образ для прода отличается от локальной песочницы.

Как отвечать

Покажите минимальный рабочий файл и объясните каждое решение.

FROM python:3.12-slim
ENV PYTHONUNBUFFERED=1 PIP_NO_CACHE_DIR=1
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
USER nobody
CMD ["gunicorn", "-b", "0.0.0.0:8000", "app:app"]

Что тут важно назвать вслух:

• порядок слоёв: файл зависимостей копируется до кода, иначе правка одной строки в проекте заново тянет весь pip install;
• воспроизводимость: версии зафиксированы в requirements.txt или в lock-файле poetry, pip-tools, uv, теги базового образа не latest;
• .dockerignore: без него в контекст сборки уезжают .git, виртуальное окружение и кэши;
• процесс: приложение запускает gunicorn или uvicorn, а не встроенный dev-сервер, и работает не от root;
• multi-stage: если нужны компиляторы для колёс, они остаются в стадии сборки и в финальный образ не попадают.

Дальше можно упомянуть docker compose для локальной связки с базой, healthcheck и передачу конфигурации переменными окружения.

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

Ставят COPY . . перед установкой зависимостей. Кэш слоёв после этого не работает вообще, и каждая сборка в CI занимает минуты вместо секунд.

Берут alpine ради размера и получают обратный эффект: под musl готовых колёс часто нет, пакеты вроде numpy собираются из исходников, сборка растягивается, а в рантайме вылезают отличия libc.

Третье: секреты и root. Токен, переданный через ARG или скопированный вместе с .env, остаётся в истории слоёв и достаётся из образа целиком, а процесс от root превращает любой побег из приложения в проблему хоста.