Недостающие идентификаторы уровня Docker на выходе

Я только что сделал новую установку Docker на Ubuntu, используя официальные рекомендации: https://docs.docker.com/engine/installation/linux/ubuntulinux/

Когда я вытягиваю изображение, используя "sudo docker pull ubuntu", а затем "sudo docker history ubuntu", он возвращает отсутствующие идентификаторы уровней в столбцах. Используя пример документации (https://docs.docker.com/engine/reference/commandline/history/), мой вывод:

IMAGE CREATED CREATED BY SIZE COMMENT
3e23a5875458 8 days ago /bin/sh -c #(nop) ENV LC_ALL=C.UTF-8 0 B
"missing" 8 days ago /bin/sh -c dpkg-reconfigure locales && loc 1.245 MB
"missing" 8 days ago /bin/sh -c apt-get update && apt-get install 338.3 MB

и т.д. Отображается только идентификатор базового слоя, остальное "отсутствует". Я попытался установить на другой компьютер Ubuntu, подключенный к другой сети, и у него такая же проблема для любого загружаемого изображения.

Кто-нибудь знает, что вызывает это или может помочь мне исправить это? Я полагаюсь на этот идентификатор уровня, так как я собираю некоторые статистические данные о повторном использовании слоев, поэтому мне нужно, чтобы этот идентификатор отображался правильно.

Спасибо

Ответ 1

Как уже упоминалось в вопрос 20131, это может быть следствием нового docker 1.10 миграция адресации

Из Сообщение блога Docker:

Начиная с версии 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, он будет сжат для эффективности пропускной способности. Также создается манифест для описания содержимого изображения и содержит дайджесты сжатого уровня содержание. Следовательно, дайджесты для слоев в манифесте отличаются от данных, сгенерированных в их несжатом состоянии.