Содержание
Коротко
На Habr вышел практический разбор минимальной платформы MLOps в закрытом контуре: без публичных облаков, с приватным GitLab, реестром образов и внутренним Ingress. Автор пишет явно для инженера DevOps — не как «ещё один Kubeflow», а как путь от голого кластера до воспроизводимого конвейера моделей.
Стек знакомый: Kubernetes, ArgoCD, MLflow, DVC, MinIO, OpenBao, Prometheus. Отдельный GPU-сервер для обучения вынесен за пределы кластера. Главная боль — не выбор модных инструментов, а логистика артефактов и секретов внутри периметра.
Что произошло
До 80% проектов машинного обучения, по отраслевым оценкам, так и остаются экспериментами в Jupyter: нет процесса, как версионировать данные, сравнивать прогоны и выкатывать модель так же дисциплинированно, как сервис. Дата-сайентист мыслит экспериментом, инженер DevOps — сервисом; без общего контура получается боль и случайные секреты в образе.
Конвейер моделей отличается от обычного CI/CD. Артефакт — не только код, а ещё данные и гиперпараметры. Git не тянет гигабайтные наборы данных — в статье берут DVC с указателями в репозитории и файлами в MinIO. Десятки экспериментов сравнивают в MLflow (с PostgreSQL вместо SQLite). Модель в проде может деградировать без смены кода из‑за дрейфа данных — жизненный цикл циклический. Реестр моделей с алиасами вроде @champion даёт откат без правки кода приложения.
Платформа разделена на два контура: Kubernetes для сервиса вывода, трекинга и секретов; отдельная GPU-машина для обучения через очередь Celery + Redis и мета-воркер, который запускает Docker-образы с рантаймом nvidia. Между контурами — сеть через Ingress: компрометация GPU не равна доступу к управляющей плоскости кластера.
Почему это важно
Закрытый контур ломает привычные облачные трюки. Чарты Helm вендорят в Git, публичные образы перекладывают в приватный реестр, вместо облачного KMS — SOPS с ключами age и вспомогательным контейнером у ArgoCD. Вместо HashiCorp Vault после смены лицензии — OpenBao (совместимый API, лицензия MPL 2.0) плюс External Secrets Operator.
Автор сознательно отказался от Kubeflow на старте (тяжело и «облачно» по духу) и от Airflow как единственного оркестратора (расписание плохо стыкуется с «запусти обучение сейчас из ноутбука»). Поставка из Git собрана по схеме «приложения из приложений» с волнами синхронизации, чтобы секреты подтянулись раньше приложений.
Безопасность не «потом»: Bandit и Trivy в CI, контейнер API от непривилегированного пользователя, жёсткий контекст безопасности, прокси к сокету Docker на GPU-хосте вместо прямого /var/run/docker.sock. За скобками остаются автоматическое снятие печати (auto-unseal) для OpenBao и риск моделей в формате pickle — для прода автор честно советует безопаснее форматы вроде ONNX.
На практике
- Версионируйте данные отдельно от кода (
DVCили аналог) и храните тяжёлые файлы во внутреннем объектном хранилище. - Не оставляйте
MLflowна SQLite при нескольких воркерах — нужен нормальный сервер баз данных для хранения метаданных. - Выносите обучение на выделенный GPU-контур с очередью задач и минимальными привилегиями к API Docker.
- В изолированной среде зеркалируйте образы и чарты внутрь периметра; шифруйте секреты
GitOpsдо коммита. - Наблюдайте не только задержку API, но и признаки дрейфа: иначе «зелёный» выкат кода не спасёт качество модели.
Прототип из статьи — отправная точка, не эталон на любой масштаб. При росте объёмов пересматривают модульность, снятие печати с секретов и формат сериализации моделей.
Итог
MLOps для DevOps — это распространение привычных практик (версии, CI/CD, секреты, наблюдаемость) на данные и модели, особенно болезненно в изолированной среде. Минимальный открытый стек на Kubernetes закрывает путь от эксперимента до сервиса вывода, если честно решить логистику артефактов, а не только «поставить Jupyter с GPU».