Ответ 1
Как уже упоминалось в вопрос 20131, это может быть следствием нового docker 1.10 миграция адресации
Начиная с версии 1.1, мы полностью меняем способ, которым Docker обращается к данным изображения на диске.
Раньше каждое изображение и слой использовали случайно присвоенный UUID.
В 1.10 мы реализовали адресный метод содержимого с использованием идентификатора на основе безопасного хэша данных изображения и уровня.
Вот почему thaJeztah комментарии:
Я думаю, что это ожидается; содержимое-адресуемое хранилище больше не использует "родительские" изображения для объединения слоев изображения вместе.
Вновь вытащенные изображения также больше не будут отображать промежуточные изображения (эти "отсутствующие" изображения будут отображаться только для изображений, которые присутствовали на хосте, но были перенесены в новое хранилище).
Обновление июня 2016 года (3 месяца спустя)
Найджел Браун содержит подробную статью об этих "недостающих" изображениях.
Объяснение идентификаторов изображений докеров
Слой или "diff" создается во время процесса сборки образа Docker и возникает, когда команды запускаются в контейнере, которые создают новые или измененные файлы и каталоги.
Эти новые или измененные файлы и каталоги "закреплены" как новый уровень.Исторически (pre Docker v1.10) каждый раз, когда новый слой был создан в результате действия фиксации, Docker также создал соответствующее изображение, которое было идентифицировано случайно генерируемым 256-битным UUID, обычно называемым идентификатор изображения
Один из больших драйверов для изменения произошел из отсутствия средства обнаружения, было ли изменено содержимое изображения во время нажатия или вытаскивания из реестра, например, Docker Hub. Это привело к
Итак, когда изображение Docker вытаскивается из реестра, а команда истории докеров используется для раскрытия его содержимого, вывод предоставляет нечто похожее:
$ docker history swarm IMAGE CREATED CREATED BY SIZE COMMENT c54bba046158 9 days ago /bin/sh -c #(nop) CMD ["--help"] 0 B <missing> 9 days ago /bin/sh -c #(nop) ENTRYPOINT &{["/swarm"]} 0 B <missing> 9 days ago /bin/sh -c #(nop) VOLUME [/.swarm] 0 B <missing> 9 days ago /bin/sh -c #(nop) EXPOSE 2375/tcp 0 B <missing> 9 days ago /bin/sh -c #(nop) ENV SWARM_HOST=:2375 0 B <missing> 9 days ago /bin/sh -c #(nop) COPY dir:b76b2255a3b423981a 0 B <missing> 9 days ago /bin/sh -c #(nop) COPY file:5acf949e76228329d 277.2 kB <missing> 9 days ago /bin/sh -c #(nop) COPY file:a2157cec2320f541a 19.06 MB
Значение
<missing>
в полеIMAGE
для всех, кроме одного из слоев изображения, вводит в заблуждение и немного неудачно. Он передает предложение об ошибке, но нет ошибки, поскольку слои больше не являются синонимами соответствующего изображения и идентификатора.
Я думаю, было бы более уместно оставить поле пустым.Кроме того, идентификатор изображения ассоциируется с самым верхним слоем, но на самом деле идентификатор изображения не "принадлежит" ни одному из слоев. Скорее, слои коллективно принадлежат изображению и предоставляют определение своей файловой системы.
Но (локальные или удаленные изображения):
локально созданные изображения на хосте Docker обрабатываются несколько иначе.
Общий контент созданного образа остается неизменным - это объект конфигурации, содержащий элементы конфигурации, включая упорядоченный список дайджестов уровня.Однако, когда слой выполняется во время сборки изображения на локальном хосте Docker, одновременно создается "промежуточное" изображение.
Как и все другие изображения, у него есть элемент конфигурации, который представляет собой список дайджеста уровня, который должен быть включен как часть изображения, а его идентификатор или дайджест содержит хеш объекта конфигурации. Промежуточные изображения не помечены именем, но у них есть ключ "Родитель", который содержит идентификатор родительского изображения.Цель промежуточных изображений и ссылка на родительские изображения - это облегчить использование Docker кэша сборки.
$ docker history jbloggs/my_image:latest IMAGE CREATED CREATED BY SIZE COMMENT 26cca5b0c787 52 seconds ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "/bin/b 0 B 97e47fb9e0a6 52 seconds ago /bin/sh -c apt-get update && apt-get inst 16.98 MB 1742affe03b5 13 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B <missing> 13 days ago /bin/sh -c #(nop) ADD file:5d8521419ad6cfb695 125.1 MB
В этом примере верхние два слоя создаются во время сборки локального изображения, в то время как нижние слои поступают из базового изображения для сборки (например, команда Dockerfile
FROM debian
).Мы можем использовать команду
docker inspect
для просмотра дайджеста слоя, связанного с изображением:Команда
docker history
показывает изображение как имеющее четыре слоя, ноdocker inspect
предлагает только три слоя.
Это связано с тем, что две командыCMD
создают метаданные для изображения, не добавляют никакого содержимого, и поэтому "diff" пуст.
Дайджест5f70bf18a08a
- это хэш SHA256 пустого слоя и разделяется обоими слоями.Когда локально построенное изображение помещается в реестр, загружается только листовое изображение вместе с его составными слоями, а последующее нажатие другого узла Docker не даст никаких промежуточных родительских изображений.
Это связано с тем, что после того, как изображение станет доступным другим потенциальным пользователям на разных узлах Docker через реестр, оно становится доступным только для чтения, а компоненты, поддерживающие кеш сборки, больше не требуются. Вместо идентификатора изображения
<missing>
вставляется в вывод истории на своем месте.Наконец:
В дайджестах, которые Docker использует для "diff" уровня на хосте Docker, содержится хэш файл sha256 из архивного содержимого diff. Перед тем, как слой будет загружен в реестр как часть push, он будет сжат для эффективности пропускной способности. Также создается манифест для описания содержимого изображения и содержит дайджесты сжатого уровня содержание. Следовательно, дайджесты для слоев в манифесте отличаются от данных, сгенерированных в их несжатом состоянии.