Влияет ли количество слоев на размер, время установки или производительность текущих и будущих docker изображений?

Question

Если у меня есть 2 варианта добавления docker слоев.

Option1:

RUN python -m nltk.downloader punkt averaged_perceptron_tagger brown

Option2:

RUN python -m nltk.downloader punkt 
RUN python -m nltk.downloader brown
RUN python -m nltk.downloader averaged_perceptron_tagger 

Я понимаю, что второй вариант добавляет 3 слоя, тогда как 1-й вариант добавляет только 1 слой.

Имеет ли количество слоев влияние на размер, время установки или производительность текущего и будущего изображений docker?

Примечание: Текущий означает текущий образ. Будущее означает любое изображение, которое может использовать некоторые слои из существующего изображения, что ускоряет настройку.

Answer 1

Это влияет на время установки и может повлиять на размер. Он не должен работать, то есть под производительностью подразумевается фактическая производительность работающего приложения.

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

Что касается размера, то это действительно зависит от того, как вы строите изображение. Например, если у вас есть зависимости сборки, которые не нужны во время выполнения, образ будет больше, потому что он будет иметь такие зависимости. Говоря о python, обычно вы хотите установить build-essential для сборки своего приложения, однако после установки пакетов вам больше не нужно build-essential. Если вы не удалите его, изображение будет больше.

Чтобы удалить его, у вас есть два варианта:

• Либо вы используете длинный оператор RUN, в котором вы устанавливаете build-essential, установите нужные вам пакеты, а затем удалите build-essential, все в том же виде RUN.
• Просто используйте многоступенчатый режим и выполняйте различные этапы сборки и запуска .

Answer 2

На практическом уровне, особенно на уровне отдельных слоев, это не имеет значения. Раньше был задокументированный предел в 127 слоев на изображении; в большинстве практических образов их число не превышает 20. В принципе, прохождение слоев файловой системы Docker может быть медленнее, если их больше, но применяется кэширование файловой системы ядра Linux, и для большинства чувствительных к производительности вещей избегать обращения к диску на обычно все лучше.

Как всегда с соображениями производительности, если это действительно важно для вас, измерьте это в контексте вашего конкретного приложения c.

Я бы сказал, что на самом деле о Docker слоях изображений следует помнить три вещи:

1. Добавление слоя никогда не уменьшает размер изображения. Если вы устанавливаете что-либо в более раннюю RUN шаг и удалите его на более позднем шаге RUN, ваше изображение завершится со всем установленным контентом из более раннего слоя, а также с дополнительным слоем-заполнителем, который говорит: «Этот материал удален сейчас». Это особенно происходит вокруг инструментов сборки. @ eez0 расскажет об этом случае немного подробнее в их ответе .

2. Слои - это единица Docker кэширования изображений. Если вы повторите шаг docker build и вы запускаете идентичную команду на том же слое, который уже существовал, Docker пропустит его выполнение и повторно использует полученный слой из предыдущей сборки. Это несколько влияет на стиль Dockerfile (вы всегда хотите RUN apt-get update && apt-get install в одной и той же команде, если вы изменяете список устанавливаемых пакетов), но не влияет на производительность.

3. Вы можете docker run результат отдельного шага. Это полезный метод отладки: вывод docker build включает идентификатор изображения для каждого шага, и вы можете docker run ваш промежуточные результаты. Если какой-то шаг не удался, вы можете получить отладочную оболочку на изображении до начала этого шага и посмотреть, что на самом деле находится в файловой системе.

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

Обычная практика - попытаться собрать вещи в один RUN, но это своего рода микрооптимизация, которая обычно не имеет большого значения на практике. В случае установки пакетов я привык видеть только одну строку apt-get install или pip install в Dockerfile, и по стилю я мог бы ожидать этого и здесь. Если вы находитесь в процессе разработки, одну команду на RUN строку легче понять и отладить.