Comments 4
Как оказалось, этот подход похож на то, что делают в Ansible Container http://docs.ansible.com/ansible-container/conductor.html
Но multi-stage builds в Docker уже не решат эту проблему. Что, если пользователю не хочется знать о том, каков побочный эффект работы программы — в частности, какие файлы она создает? Например, чтобы не держать лишние явные описания всех экспортируемых путей из образа.
Я когда-то давно юзал утилиты, которые работали либо как обёртка вокруг make с перехватом сисколов вроде open/rename/symlink/mkdir/…, либо сканируя диск до и после на изменения. Если не путаю, они помогали составить список файлов, которые нужно включать в rpm-пакет (это было лет 15, если не больше, назад). Проблему упомянутую в цитате такие утилиты вроде бы вполне способны решить, и гораздо меньшей кровью.
checkinstall обёртка над make, которая, в свою очередь, использует installwatch — отслеживатель работы с файлами для любого процесса. Теоретически можно установить Chefdk / Ansible и потом по логу удалить всё ненужное. Но даже если эта схема заработает, то: 1) installwacth нужно каким-то образом добавить в систему и потом его удалить. 2) время сборки будет потрачено на установку/удаление того, что можно скачаться один раз (ansible+python). 3) чтобы не раздувать образ, нужно удалять/устанавливать на каждой стадии — ещё больше времени израсходуется впустую. 4) Установить и удалить ansible+python можно и без слежки за файлами, а, например, через apt-get, но два предыдущих пункта делают это совершенно бесполезным.
Цель описанных контейнеров — не собирать инструменты, которые можно собрать один раз, оформить в виде docker-образа и потом просто скачать.
Linux-дистрибутив from scratch для сборки Docker-образов — наш опыт с dappdeps