У меня есть базовое изображение и несколько полностью ортогональных "размеров" полностью статичных c оверлеев, которые отображаются в каталогах данных, каждый из которых имеет несколько параметров, которые я хочу переставить для создания окончательного контейнера (ов) ) в моих развертываниях. В качестве вырожденного примера базовому образу (X) во время развертывания потребуется по одному из (A, B, C), (P, D, Q) и (K, L, M). Сейчас я создаю отдельные изображения для каждой перестановки, которая мне действительно нужна: например, XADM, XBDK, et c. Проблема в том, что по мере увеличения количества измерений наложения данных stati c и увеличения количества вариантов внутри каждого измерения я сталкиваюсь с серьезными комбинаторными проблемами взрыва - нашей системе CI / CD может потребоваться 10 минут для создания каждого из них. изображение (некоторые наложения большие), и, поскольку это базовое изображение, которое изменяется чаще всего, слои плохо кэшируются.
Пока что мысли:
- генерировать каждый Layer (ABCPDQKLM) как отдельный контейнер, который заполняет том, который затем монтируется каждым из моих X-контейнеров. Это нормально, хотя мне НИКОГДА не нужно, чтобы слои были доступны для записи, и я не особенно хочу платить за постоянное хранилище, связанное с томами, которые кажутся излишними.
- переупорядочить мои слои должны изменяться от самого медленного к самому быстрому. Я могу получить некоторое улучшение от этого, но я все еще сталкиваюсь с проблемой комбинаторики: мне, вероятно, все равно придется создавать все нужные мне комбинации, но, по крайней мере, мое время сборки CI / CD будет улучшено. Я думаю, что это приводит к ухудшению общего кэширования уровня, но обмен места на время может быть разумным, и результат для каждого клиента по-прежнему хорош и не требует хранения томов во время развертывания.
Я не доволен ни одним из вариантов (или моим текущим решением). Приветствуются любые идеи.
Изменения / вопросы:
- «stati c» означает только чтение, но с практической точки зрения A / B / C каждое наложение может представлять собой несколько 100 Мбайт структуры каталогов, которые должны монтироваться / присутствовать в определенном c месте файловой системы контейнера. В каждом случае это данные, которые будут использоваться (даже с отображением памяти!) Программами в базовом образе, поэтому они должны быть, по крайней мере, очень эффективно кэшированы рядом с каждым из процессоров, которые будут его использовать. . Мне нравятся характеристики производительности запекания данных в контейнеры, но, возможно, мне следует больше доверять уровню хранения, чтобы данные должным образом кэшировались / реплицировались рядом с реальными процессорами. Это означает обмен между платой за использование места в реестре и платой за хранение фотоэлектрических модулей, но это может быть второстепенным соображением.
- По сути, каждое «измерение» - это тип обученной модели машинного обучения. Мне нужно составить размеры, выбрав правильный набор обученных моделей, которые подходят для области, необходимой для каждого из множества производственных клиентов.