Я новичок в Docker и пытаюсь точно понять, что такое образ Docker . Каждое определение образа Docker использует термин «слой», но, похоже, не определяет, что подразумевается под слоем .
Из официальных документов Docker :
Мы уже видели, что образы Docker - это шаблоны только для чтения, из которых запускаются контейнеры Docker. Каждое изображение состоит из серии слоев. Docker использует объединенные файловые системы для объединения этих слоев в одно изображение. Объединенные файловые системы позволяют прозрачно накладывать файлы и каталоги отдельных файловых систем, называемых ветвями, образуя единую согласованную файловую систему.
Поэтому я спрашиваю, что такое слой (точно); Кто-нибудь может привести несколько конкретных примеров из них? И как эти слои «слипаются», образуя изображение?
https://labs.ctl.io/caching-docker-images/
) не работает. У кого-нибудь есть предложения по замене?Образ контейнера Docker создается с использованием файла Docker . Каждая строка в файле Docker создаст слой. Рассмотрим следующий фиктивный пример:
Это создаст окончательное изображение, где общее количество слоев будет Х + 3
источник
Они имеют смысл для меня на примере ...
Изучение слоев вашей сборки с помощью докера diff
Давайте возьмем надуманный пример Dockerfile:
Каждая из этих
dd
команд выводит файл 1M на диск. Давайте создадим образ с дополнительным флагом для сохранения временных контейнеров:В выводе вы увидите, что каждая из запущенных команд происходит во временном контейнере, который мы теперь храним вместо автоматического удаления:
Если вы запустите
docker diff
на каждом из этих идентификаторов контейнеров, вы увидите, какие файлы были созданы в этих контейнерах:Каждая строка с префиксом -
A
это добавление файла,C
указание на изменение существующего файла иD
указание на удаление.Вот часть TL; DR
Каждая из приведенных выше версий файловой системы контейнера входит в один «слой», который собирается, когда вы запускаете образ как контейнер. Весь файл находится в каждом слое при добавлении или изменении, поэтому каждая из этих
chmod
команд, несмотря на просто изменение бита разрешения, приводит к копированию всего файла на следующий слой. Удаленный / data / one файл все еще находится в предыдущих слоях, фактически 3 раза, и будет скопирован по сети и сохранен на диске при извлечении изображения.Изучение существующих изображений
Вы можете видеть команды, которые входят в создание слоев существующего изображения с
docker history
командой. Вы также можете запуститьdocker image inspect
на изображении и увидеть список слоев в разделе RootFS.Вот история для вышеупомянутого изображения:
Самые новые слои перечислены сверху. Следует отметить, что внизу есть два довольно старых слоя. Они приходят из самого изображения busybox. Когда вы строите одно изображение, вы наследуете все слои изображения, которые вы указываете в
FROM
строке. Существуют также слои, добавляемые для изменения метаданных изображения, напримерCMD
линии. Они практически не занимают места и предназначены для учета того, какие настройки применяются к изображению, которое вы запускаете.Почему слои?
Слои имеют пару преимуществ. Во-первых, они неизменны. После создания этот слой, идентифицируемый хэшем sha256, никогда не изменится. Эта неизменность позволяет изображениям безопасно создавать и отделяться друг от друга. Если два файла Docker имеют одинаковый начальный набор строк и построены на одном и том же сервере, они будут использовать один и тот же набор начальных слоев, экономя дисковое пространство. Это также означает, что если вы перестраиваете изображение, и только в нескольких последних строках Dockerfile происходят изменения, нужно перестраивать только эти слои, а остальные можно повторно использовать из кэша слоев. Это может очень быстро перестроить образ докера.
Внутри контейнера вы видите файловую систему изображения, но эта файловая система не копируется. Поверх этих слоев изображения контейнер монтирует свой собственный слой файловой системы для чтения и записи. Каждое чтение файла проходит через слои до тех пор, пока не достигнет слоя, который пометил файл для удаления, не найдет копию файла в этом слое или пока не закончится чтение слоев. Каждая запись вносит изменения в определенный для контейнера слой чтения-записи.
Уменьшение раздувания слоя
Недостатком слоев является создание изображений, которые дублируют файлы или отправляют файлы, которые будут удалены в более позднем слое. Решение часто состоит в объединении нескольких команд в одну
RUN
команду. В частности, когда вы изменяете существующие файлы или удаляете файлы, вы хотите, чтобы эти шаги выполнялись в той же команде, в которой они были впервые созданы. Переписанный выше Dockerfile будет выглядеть так:И если сравнить полученные изображения:
Просто соединив несколько строк в надуманном примере, мы получили то же самое результирующее содержание в нашем изображении и сократили наше изображение с 5 МБ до только 1 МБ файла, который вы видите на конечном изображении.
источник
Начиная с Docker v1.10, с введением адресного хранилища контента, понятие «уровень» стало совсем другим. Слои не имеют представления об изображении или принадлежности к изображению, они становятся просто коллекциями файлов и каталогов, которые могут совместно использоваться изображениями. Слои и изображения стали разделенными.
Например, на местном уровне , построенное изображение из базового изображения, скажем,
ubuntu:14.04
, тоdocker history
команда дает цепочку изображения, но некоторые из идентификаторов изображений , будут показаны как «не хватает» , потому что история сборки больше не загружаются. И слои, которые составляют эти изображения, можно найти черезСодержимое слоя сохраняется при
/var/lib/docker/aufs/diff
выборе драйвера хранилищаaufs
. Но имена слоев имеют случайно сгенерированный идентификатор кэша, кажется, что связь между уровнем и его идентификатором кэша известна только Docker Engine по соображениям безопасности. Я все еще ищу способ узнатьЭтот блог обеспечил много понимания.
источник
Спецификация имиджа Per Docker через The Moby Project :
Итак, по сути, слой - это просто набор изменений, внесенных в файловую систему.
источник
"Each [Docker] layer is a set of filesystem changes."
(Предполагая, что это правда.) По какой-то причине я не понял этого фундаментального вопроса при чтении многочисленных других документов / блоги / Q + A's / etc, и я подозреваю, что ограничение было их, а не мое. Несмотря ни на что, браво Адитья за то, что добрался до сути дела.Я думаю, что официальный документ дает довольно подробное объяснение: https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/ .
(источник: docker.com )
Изображение состоит из множества слоев, которые обычно создаются из Dockerfile, каждая строка в Dockerfile создает новый слой, и в результате получается изображение, которое обозначается формой
repo:tag
, напримерubuntu:15.04
.Для получения дополнительной информации, пожалуйста, прочитайте официальные документы выше.
источник
Спасибо @David Castillo за полезную информацию . Я думаю, что слой - это какое-то двоичное изменение или инструкция изображения, которую можно легко сделать или отменить. Они делаются шаг за шагом, то же самое, что слой на слое, поэтому мы назвали «слой».
Для получения дополнительной информации вы можете увидеть «историю докеров» следующим образом:
источник
Мое личное понимание состоит в том, что мы можем сравнивать слой докера с коммитом github. Для вашего базового образа (вашего нового главного репо) вы делаете несколько коммитов, каждый коммит меняет ваш главный статус, то же самое в докере, каждый слой выполняет некоторую операцию на основе предыдущего промежуточного слоя. И затем этот слой становится новым промежуточным слоем для следующего слоя.
источник
Раньше я думал, что они похожи на различия в предыдущих слоях. Прочитав некоторые ответы здесь, я не был так уверен; они описаны как наборы изменений в файловой системе . Я написал несколько файлов Docker, чтобы показать, что они больше похожи на diff, то есть они действительно зависят от предыдущих слоев.
Учитывая эти два Dockerfiles
и
можно было бы ожидать того же набора слоев, если бы они только что изменили файловую систему, но это не так:
и
Вы можете видеть, как, даже если изменения в файловой системе одинаковы в обоих случаях, порядок имеет значение.
источник