Почему Docker Hub не кэширует автоматические сборки репозиториев по мере создания изображений?

Docker Hub Automated Build Repositories, похоже, не кэширует изображения. По мере его сборки он удаляет все промежуточные контейнеры. Это то, как оно предназначалось для работы, или я делаю что-то неправильно? Было бы очень приятно не перестраивать все для каждого небольшого изменения. Я думал, что это должно быть одним из лучших преимуществ докера, и кажется странным, что их строитель не использует его. Так почему же он не кэширует изображения?

UPDATE: Я начал использовать Codeship для создания своего приложения, а затем запускал удаленные команды на моем сервере DigitalOcean, чтобы скопировать созданные файлы и запустить команду сборки docker. Я до сих пор не знаю, почему Docker Hub не кэширует.

Ответы

Ответ 1

Отказ от ответственности: я ведущий инженер-программист на Quay.io, приватном реестре контейнеров Docker, поэтому это обоснованное предположение, основанное на той же проблеме, с которой мы столкнулись в нашей собственной реализации системы сборки.

Учитывая мой опыт работы с системами сборки Dockerfile, я подозреваю, что Docker Hub не поддерживает кеширование из-за того, как кеширование реализовано в Docker Engine. Кэширование для сборки Docker работает путем сравнения команд, которые должны выполняться против существующих слоев, найденных в памяти.

Например, если Dockerfile имеет форму:

FROM somebaseimage
RUN somecommand
ADD somefile somefile

Затем код сборки Docker будет:

  • Проверьте, существует ли соответствие somebaseimage
  • Проверьте, есть ли локальное изображение с командой RUN somecommand, чей родитель является предыдущим изображением
  • Проверьте, есть ли локальное изображение с командой ADD somefile somefile + хеширование содержимого somefile (чтобы убедиться, что оно недействительно при изменении somefile), родителем которого является предыдущее изображение

Если какой-либо из вышеперечисленных шагов соответствует, тогда эта команда будет пропущена в процессе сборки Dockerfile, вместо этого будет использовано кэшированное изображение. Тем не менее, одна из ключевых проблем этого процесса заключается в том, что для поиска и проверки совпадений требуется, чтобы кешированные изображения были присутствующими на машине сборки. Наличие всех всех изображений на узлах сборки будет крайне неэффективным, что затрудняет решение этой проблемы.

На Quay.io мы решили проблему кэширования, создав вариацию кода кэширования Docker, который может предварительно скопировать эти команды/хэши, а затем спросить наш реестр для кешированных слоев, загрузив их на компьютер только после того, как мы нашли самый эффективный набор кеширования. Это потребовало значительных изменений модели данных в нашем коде реестра.

Если вам нужна дополнительная информация, мы предоставили технический обзор того, как мы это делаем в этом разговоре: https://youtu.be/anfmeB_JzB0?list=PLlh6TqkU8kg8Ld0Zu1aRWATiqBkxseZ9g