Виртуализация с Docker + Python-приложение

Зачем Docker нужен Python-разработчику

• Изоляция окружения: зависимости проекта не ломают систему
• Повторяемость: контейнер запускается одинаково везде
• Быстрое развёртывание: приложение переносится одной сборкой
• Удобство для CI/CD: проще автоматизировать тесты и релизы
• Масштабирование: контейнеры легко запускать в нескольких экземплярах 🚀

Базовая структура проекта

• app.py — основной код приложения
• requirements.txt — зависимости
• Dockerfile — инструкция для сборки контейнера
• .dockerignore — файлы, которые не нужно копировать в образ

Пример Dockerfile для Python-приложения

FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]

Как это работает

• FROM — задаёт базовый образ
• WORKDIR — создаёт рабочую директорию внутри контейнера
• COPY requirements.txt . — сначала копируем зависимости для кэширования слоёв
• RUN pip install ... — устанавливаем библиотеки
• COPY . . — переносим код приложения
• CMD — команда запуска

Сборка и запуск

docker build -t my-python-app .
docker run --rm my-python-app

Если приложение — веб-сервис на Flask или FastAPI, обычно пробрасывают порт:

docker run -p 8000:8000 my-python-app

Практические рекомендации

• Используйте python:slim, а не тяжёлые образы — меньше размер и быстрее доставка 📦
• Добавляйте .dockerignore, чтобы не включать venv, .git, кэши и лишние файлы
• Фиксируйте версии зависимостей в requirements.txt
• Не храните секреты в Dockerfile — передавайте через переменные окружения 🔐
• Для production лучше запускать не встроенный dev-сервер, а Gunicorn/Uvicorn

Типичные ошибки

• Копирование всего проекта до установки зависимостей — ломает кэш сборки
• Слишком большой образ из-за лишних файлов
• Запуск от root без необходимости
• Отсутствие healthcheck и логирования в сервисных приложениях