3.1.1 · блок 3

Идея контейнеров: образ, контейнер, изоляция

Зачем это нужно

На вашем ноутбуке Python 3.11, библиотеки установлены «как получилось», путь к данным — /Users/student/data.csv. На сервере коллеги — другая версия ОС, другие пакеты, другие пути. Классическая фраза «у меня работает» — главный враг командной разработки и особенно ML, где воспроизводимость эксперимента критична.

Контейнеры решают проблему одинакового окружения: приложение упаковывается вместе с зависимостями и запускается одинаково на ноутбуке, в CI и в Kubernetes. Этот урок — фундамент блока «Платформа»: без понимания образа и контейнера дальше не получится ни собрать Docker-образ модели, ни выкатить inference-сервис в кластер.

Основные идеи

Образ (image) и контейнер (container). Образ — неизменяемый «шаблон»: файловая система слоями, команда запуска, переменные окружения. Контейнер — запущенный экземпляр образа: процесс с изолированным видением файловой системы, сети и PID. Один образ → много контейнеров (как один .exe можно запустить несколько раз).

Слои и кэш. Образ строится слоями (слой ОС, слой зависимостей, слой кода). Если слой не менялся — Docker переиспользует кэш при сборке. Поэтому в Dockerfile сначала копируют requirements.txt, устанавливают пакеты, и только потом — исходники: при изменении кода не переустанавливаются все библиотеки.

Изоляция, но не виртуальная машина. Контейнер делит ядро Linux с хостом (namespaces + cgroups). Он легче VM: стартует за секунды, потребляет меньше RAM. Но изоляция слабее, чем у полноценной VM — для курса этого достаточно; в продакшене поверх контейнеров обычно стоит оркестратор (Kubernetes).

Registry. Образ публикуют в реестр (Docker Hub, GitLab Container Registry, Harbor). CI собирает образ → пушит по тегу (my-model:1.2.3) → Kubernetes или другой сервер тянет (pull) и запускает. Тег — это версия артефакта, как commit hash для кода.

Связь с ML. Модель inference — это не только файл .pkl или .onnx, но и runtime: Python, FastAPI, CUDA-библиотеки. Контейнер фиксирует всё это. Data Scientist может отдать MLE образ «как в эксперименте», а не список «поставь вот эти 47 пакетов».

Как это выглядит на практике

Вы пишете простой FastAPI-сервис, который отдаёт предсказание модели:


docker pull python:3.11-slim
docker build -t fraud-scorer:0.1.0 .
docker run -p 8000:8000 fraud-scorer:0.1.0
curl http://localhost:8000/health

На машине разработчика и в Jenkins после docker build получается один и тот же образ (при одинаковом Dockerfile и базовом образе). DevOps не спрашивает «какая у тебя версия numpy» — она зашита в слои.

Типичный путь ML-сервиса:

1. DS проверяет модель локально в контейнере.

2. MLE добавляет Dockerfile в Git.

3. Jenkins собирает образ и пушит в registry.

4. Kubernetes создаёт Pod из этого образа.

Команды, которые стоит знать на старте: docker images, docker ps, docker logs <container>, docker stop.

Что сделать после занятия

[ ] Объясните одногруппнику разницу между образом и контейнером на примере вашего учебного Python-проекта.
[ ] Запустите официальный образ nginx локально, откройте порт 8080, зайдите в браузере — убедитесь, что контейнер живёт отдельно от хоста.
[ ] Найдите в Docker Hub образ python:3.11-slim и прочитайте, какие теги бывают (slim, alpine, без суффикса).

Официальные материалы

Открыть интерактивную версию