Кэш-монтирование или Cache mount в Docker. Использование кэш-монтирования в GitLab CI/CD

[Arzamasov]

Очень познавательно, спасибо. Буду держать в закрепе!

[alexandraa_va]

очень полезно! благодарю!

[PetyaUmniy]

А в чем смысл делать это в python?
Модули они ведь и так кешируются на уровне слоя докер образа и больше не собирается пока файлик с их дефинициями не меняется. Вы зачем-то меняете его часто?
Зачем еще раз кешировать их первоисточники во внешнем кеше?
Я понимаю что-нибудь тяжелое и отвратительное из разряда ынтерпраза или мобилок - gradle с 20 гигобайтным кешем...
Но python - это не серьезно.
Как будто бы разительное усложнение системы и близко не окупит профита от ускорения сборки.

[Arut1995]

Статья про кэш-монтирование в Docker. Как устроен этот механизм и как его использовать в GitLab CI/CD с разными GitLab Runner.

Python я взял как пример, потому что чаще всего работаю с ним. Если в run-cache.Dockerfile заменить pip на gradle или npm, примеры в статье будут работать точно так же.

Но даже если брать Python. Есть, например, сборки для GPU окружений. В таком случае в pip летит куча CUDA пакетов, и pip cache разрастается до гигабайтов. А когда идут эксперименты с разными версиями torch, алгоритмов и моделей, каждая пересборка образа может тормозить research и тестирование.

[PetyaUmniy]

Когда что-то отлаживаю в докер поступаю проще.
Не редактирую/переписываю слой с установкой софта, а просто добавляю еще одну установку слоем выше. Таким образом сокращается дельта которую будет вносить изменения для отладки. Порой делаю как в > 2 уровней. Когда наотлаживался - объединяю слои и релижу.
Это так же покрывает все другие возможные сценарии: установки пакетов, копирования файлов, артефактов из других слоев - чего угодно. И в таком случае не нужно для каждого отдельного сценария изобретать свой велосипед, который потом пришлось бы поддерживать.

[Arut1995]

Ты описываешь локальный подход к сборке, а статья про CI/CD.

Например, есть монорепозиторий, несколько команд, разные окружения и люди, которые могут вообще не знать, как сборка устроена изнутри. Им надо, чтобы просто работало и было быстро. И им проще добавить свои пакеты в requirements.txt.

Любой CI/CD сложнее docker build && docker push это уже велосипед, потому что у каждого проекта своя специфика. Кто-то использует DinD с полной пересборкой и их всё устраивает. А кто-то хочет ускориться и начинает использовать дополнительные возможности: кэш-монтирование, BuildKit, GitLab cache.

Здесь нет правильного решения. Есть то, которое решает проблемы конкретной команды.

[silentz]

Мы в кровавом ынтерпрайзе просто собираем голден образ с мавеном и всеми либами = мавен образ с .m2 папкой с нашими зависимостями = 1.5гб. в докерфайле два шага - сборка мавеном и перекладывание сорсов в jvm образ. Все запускается параллельно, никаких танцев с dind и dood

[Rostiix]

А вы не рассматривали registry cache?

[Arut1995]

Я смотрел этот механизм, но пришёл к выводу, что проблему с кэшем пакетных менеджеров с его помощью мне не решить.

Registry cache работает со слоями образа. Если инструкция, где устанавливаются зависимости, изменилась, Docker всё равно выполнит её заново.

Кэш-монтирование же создано именно для таких случаев. Оно сохраняет состояние кэша пакетного менеджера, а не слой.

Поэтому registry cache я бы рассматривал как дополнение, к тому что описано в статье. Если на GitLab Runner пустой кэш слоёв, то подтягиваем его из Registry. А для кэша пакетного менеджера используем кэш-монтирование.