Разве сжатие / выравнивание образа докера не повлияет на кеширование реестра?
Предположим, у вас есть изображение докера, и вы сгладили его или раздавили, чтобы уменьшить его размер. Это полезно для артефактов времени выполнения, поэтому они могут потреблять минимальные ресурсы для хранения и передачи / извлечения.
Но мне интересно, есть ли компромисс между выравниванием (создание одного сжатого слоя) и повторным использованием слоя, который происходит со стороны реестра контейнера, когда вы нажимаете свое изображение, чтобы сохранить его.
Вот пример: предположим, у вас есть изображение с несколькими слоями - обычное старое изображение Docker - и его размер может быть 500 МБ. Вы используете сжатие или сплющивание, чтобы сжать его в один слой размером 250 МБ.
Теперь предположим, что вам нужно внести изменения в свое изображение, создать версию 2. Версия 2 - очень незначительное изменение в позднем слое контейнера, возможно, изменение имени файла настроек прямо перед CMD инструкция или что-то.
В случае, когда вы поместили несколько расширенных слоев в реестр, когда вы собираетесь отправить это новое изображение, в кэше реестра нужно будет хранить только различный конечный слой, что, возможно, будет означать общий размер (для исходное изображение и ваше новое изображение версии 2 вместе) будут, скажем, 550 МБ или что-то в зависимости от того, какой последний слой изменился.
Между тем, в случае, когда вы сгладили его, ваше новое изображение версии 2 - это просто какое-то совершенно новое однослойное изображение, не имеющее общей истории с оригинальным контейнером. (Возможно, ваш локальный экземпляр Docker может видеть историю слоев, относящуюся к выравниванию, но в реестре ее нет).
В этом случае вам придется хранить примерно 500 МБ в реестре: 250 МБ каждая для первой и второй версий образа.
Ясно, что вы можете видеть, как только мы сделаем это в третий раз, общее пространство сглаженных изображений на самом деле больше, чем пространство постепенных изменений изображений с расширенным слоем.
Что-то мне не хватает в том, как это работает? Он предполагает, что вы захотите выполнить выравнивание только в тот момент, когда вы отправляете контейнер в конечный пункт назначения для использования, но обычно вам не нужно выполнять выравнивание при хранении в реестре.
Могут быть угловые случаи, когда базовое изображение настолько велико, а выравнивание дает настолько большое уменьшение размера, что оно того стоит, но я пытаюсь понять общий случай, и я не могу найти документацию, в которой обсуждается этот конкретный аспект выравнивания слоев.
1 ответ
Сжатие изображения лишает возможности использовать кэшированные слои изображений и увеличивает дисковое пространство, используемое при наличии нескольких копий изображения. По этой причине я еще не видел, чтобы это использовалось с моими клиентами. Предпочтительный способ сделать это - настроить Dockerfile для максимального повторного использования кэша предыдущих сборок образа.
Если вы видите уменьшение изображения на 50% из-за сквоша, часто есть лучший способ структурировать Dockerfile, чтобы избежать раздувания слоя. Обычная ситуация, которую я знаю о том, что сжатие улучшается, это когда вам нужно скопировать большой файл из контекста с помощью COPY а затем изменить или позже удалить этот файл в будущем RUN команда. Там нет способа связать COPY а также RUN командуй вместе. Вы можете конвертировать COPY к RUN curl http://local-artifact-repo/..., Или с многоэтапными сборками, теперь вы можете выполнить все COPY и другие RUN команды в один этап, а затем COPY результат в финальном изображении. Последний COPY приведет к созданию совершенно нового слоя, даже если вы внесете лишь незначительное изменение, но при этом цепочка команд в RUN,