Ты описываешь локальный подход к сборке, а статья про CI/CD.
Например, есть монорепозиторий, несколько команд, разные окружения и люди, которые могут вообще не знать, как сборка устроена изнутри. Им надо, чтобы просто работало и было быстро. И им проще добавить свои пакеты в requirements.txt.
Любой CI/CD сложнее docker build && docker push это уже велосипед, потому что у каждого проекта своя специфика. Кто-то использует DinD с полной пересборкой и их всё устраивает. А кто-то хочет ускориться и начинает использовать дополнительные возможности: кэш-монтирование, BuildKit, GitLab cache.
Здесь нет правильного решения. Есть то, которое решает проблемы конкретной команды.
Я смотрел этот механизм, но пришёл к выводу, что проблему с кэшем пакетных менеджеров с его помощью мне не решить.
Registry cache работает со слоями образа. Если инструкция, где устанавливаются зависимости, изменилась, Docker всё равно выполнит её заново.
Кэш-монтирование же создано именно для таких случаев. Оно сохраняет состояние кэша пакетного менеджера, а не слой.
Поэтому registry cache я бы рассматривал как дополнение, к тому что описано в статье. Если на GitLab Runner пустой кэш слоёв, то подтягиваем его из Registry. А для кэша пакетного менеджера используем кэш-монтирование.
Статья про кэш-монтирование в Docker. Как устроен этот механизм и как его использовать в GitLab CI/CD с разными GitLab Runner.
Python я взял как пример, потому что чаще всего работаю с ним. Если в run-cache.Dockerfile заменить pip на gradle или npm, примеры в статье будут работать точно так же.
Но даже если брать Python. Есть, например, сборки для GPU окружений. В таком случае в pip летит куча CUDA пакетов, и pip cache разрастается до гигабайтов. А когда идут эксперименты с разными версиями torch, алгоритмов и моделей, каждая пересборка образа может тормозить research и тестирование.
Ты описываешь локальный подход к сборке, а статья про CI/CD.
Например, есть монорепозиторий, несколько команд, разные окружения и люди, которые могут вообще не знать, как сборка устроена изнутри. Им надо, чтобы просто работало и было быстро. И им проще добавить свои пакеты в
requirements.txt.Любой CI/CD сложнее
docker build && docker pushэто уже велосипед, потому что у каждого проекта своя специфика. Кто-то использует DinD с полной пересборкой и их всё устраивает. А кто-то хочет ускориться и начинает использовать дополнительные возможности: кэш-монтирование, BuildKit, GitLab cache.Здесь нет правильного решения. Есть то, которое решает проблемы конкретной команды.
Я смотрел этот механизм, но пришёл к выводу, что проблему с кэшем пакетных менеджеров с его помощью мне не решить.
Registry cache работает со слоями образа. Если инструкция, где устанавливаются зависимости, изменилась, Docker всё равно выполнит её заново.
Кэш-монтирование же создано именно для таких случаев. Оно сохраняет состояние кэша пакетного менеджера, а не слой.
Поэтому registry cache я бы рассматривал как дополнение, к тому что описано в статье. Если на GitLab Runner пустой кэш слоёв, то подтягиваем его из Registry. А для кэша пакетного менеджера используем кэш-монтирование.
Статья про кэш-монтирование в Docker. Как устроен этот механизм и как его использовать в GitLab CI/CD с разными GitLab Runner.
Python я взял как пример, потому что чаще всего работаю с ним. Если в
run-cache.Dockerfileзаменитьpipнаgradleилиnpm, примеры в статье будут работать точно так же.Но даже если брать Python. Есть, например, сборки для GPU окружений. В таком случае в
pipлетит куча CUDA пакетов, и pip cache разрастается до гигабайтов. А когда идут эксперименты с разными версиями torch, алгоритмов и моделей, каждая пересборка образа может тормозить research и тестирование.