От эксперимента до продакшена: управляем жизненным циклом Docker-образов для ML

Когда у каждой команды свой Dockerfile, за год в registry накапливаются десятки почти одинаковых образов. Собирают их на ноутбуках, чужой воспроизвести никто не может, а обновление минорной версии Python превращается в квартальный проект.

Дата-сайентисты тут ни при чём. Писать Dockerfile - не их работа, и когда DS говорит «окружение», он имеет в виду список библиотек. Не мультистейдж и не корпоративные зеркала пакетов. И уж точно не разницу между образом под GPU-инференс и образом под JupyterHub. Всю эту специфику платформа должна прятать, поэтому мы дали командам DSL: перечисли нужные библиотеки, остальное соберётся само.

Инфраструктурный слой образов мы вынесли в отдельный монорепозиторий и описали декларативно. Вместо россыпи Dockerfile - манифест, где стадии заданы явно: эксперимент, обучение, продакшен-сервинг, с общей базой и наследованием. CI читает каталог и генерирует по нему вложенный pipeline. Путь от эксперимента до релиза - несколько ручных кнопок.

В докладе - устройство этой машинерии. catalog.yaml как реестр и точка входа для CI, image.yaml как описание образа, маршрутизация релизов по префиксам git-тегов, изоляция MR-сборок от продакшен-имён. И вторая половина: как всё это не разваливается на образах весом в десятки гигабайт. Дельта-сборка через FROM родительской стадии, кэш, источник которого резолвится из registry на лету, и приём, до которого мы дошли не сразу: базой цепочки стоит продакшен-образ, а не эксперимент.

Доклад для платформенных и инфраструктурных инженеров, MLOps и всех, кто поддерживает сборку контейнеров для нескольких команд. История про то, как спроектировать декларативную сборку поверх CI и не утонуть в копипасте pipeline'ов.