Добавление больших файлов в докер во время сборки

Question

Моему сервису нужны некоторые большие файлы, когда он работает (~ 100–500 МБ). Эти файлы могут время от времени меняться, и я не против перестроить свой контейнер и повторно развернуть его, когда это произойдет.

Мне интересно, как лучше всего сохранить его и использовать во время сборки, чтобы любой член команды мог обновить контейнер и перестроить его.

Моя лучшая идея на данный момент - хранить эти большиефайлы в git LFS в разных ветках для каждой версии.Чтобы я мог добавить его в свой Dockerfile:

RUN git clone -b 'version_2.0' --single-branch --depth 1 https://...git.git

Таким образом, если эти большие файлы изменятся, мне просто нужно изменить version_2.0 в Dockerfile и перестроить.

Есть ли другой рекомендуемый способ?Я подумал о том, чтобы сохранить эти файлы в Dropbox, и просто получить их со ссылкой, используя wget во время сборки

PS - эти большие файлы являются весами для некоторых Deep-Network

Правка - ВопросВот какой разумный способ хранить большие файлы в докере, так что один разработчик / команда может изменить файл и соответствующий код, и он будет задокументирован (git) и может быть легко использован и даже развернут другой командой (по этой причинепросто большие файлы на локальном ПК - это плохо, потому что их нужно отправить другой команде)

Answer 1

На самом деле все сводится к тому, как вы строите свой контейнер. Например, мы строим наши контейнеры, используя плагин Jenkins & fabric8 io как часть сборки maven.Мы используем ADD с URL-адресом удаленного источника (Nexus).

Как правило, вы можете использовать URL в качестве источника.так что это зависит от того, к какому хранилищу у вас есть доступ.1. Вы можете создать корзину S3 и предоставить доступ к вашему узлу Docker Builder.Вы можете добавить ADD http://example.com/big.tar.xz /usr/src/things/ в файл Docker для сборки

вы можете загружать большие файлы в хранилище артефактов (например, Nexus или Artifactory) и использовать его в ADD

, если вы создаете с помощью Jenkins, в том жеhost создайте папку и настройте веб-сервер для обслуживания этого контента с помощью конфигурации virtualhost.Затем используйте этот URL.

Оптимальным решением будет то, которое будет дешевле с точки зрения усилий и затрат без ущерба для безопасности.

Answer 2

Тома, живущие как отдельные узлы и разделенные между командами

Просто чтобы дополнить @ ответ Эмори , я бы посоветовал вам использовать Постоянные тома Кубернетеса для вашего точногодело.

Как это могло бы помочь?

Как вы сказали, есть несколько команд, каждая команда может запустить POD , который в простых терминах представляет собой группу контейнеров и спецификациюих взаимодействия (например, запуск, передача данных и т. д.).Другими словами, это логическая связь между несколькими контейнерами.Такие POD обычно запускаются в кластере и управляются ядром Kubernetes.

Постоянные тома - это еще один ресурс в кластере, содержащий данные.По сравнению с обычными томами, они повторно отображаются в кластере и могут быть доступны для разных POD, указав PersistentVolumeClaims .

. При использовании этого подхода вы можете:

• иметь нольвремя простоя ваших контейнеров (при необходимости репликация POD в кластере)
• обновление весов вашей сети любым членом команды (или подмножеством вашей команды)
• получение обновлений весов изPOD без взаимодействия с контейнерами

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

Answer 3

Если вы рассматриваете даже Dropbox, почему бы вам не рассмотреть AWS S3?Или вы можете смонтировать их в какой-то том или файловую систему.

Answer 4

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

Загрузка этого нового изображения также просто загрузит этот последний слой.

Что касается повторного развертывания,вам необходимо убедиться, что все данные (config, tmp, ...) хранятся в томе.«Перераспределение» может затем использовать docker run ... --volumes-from=old-container ... и быть немедленно доступным снова.

Answer 5

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

Если твоей службе нужны большие файлы при работе, и они время от времени меняются, то

• не включай их визображение;но вместо этого
• смонтируйте их как тома,

Answer 6

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

Затем, когда другие члены команды хотят обновить, они просто обновляют инструкцию FROM в Dockerfile.

При таком подходе неважно, где вы сохраняете исходные файлы, поскольку они используются только один раз при создании базового образа.

Answer 7

Эти файлы могут время от времени изменяться, и я не против перестроить свой контейнер и повторно развернуть его, когда это произойдет.

Тогда контроль за исходным кодом не являетсялучше всего подходит для такого артефакта.

Служба хранения бинарных артефактов, например Nexus или Artifactory (которые имеют бесплатные версии и имеют собственный образ докера, если вам нужноone) больше подходит для этой задачи.

Оттуда ваш Dockerfile может получать из Nexus / Artifactory ваши большие файлы.
См. здесь правильное кэширование и аннулирование кэша .