Как определить дайджест базового образа на Docker Hub?

Вопрос или проблема

Я ищу способ определить базовый образ, используемый другим образом Docker, вплоть до SHA256-дескриптора, желательно без необходимости загружать любой из них. Раньше я мог делать это через список слоев Docker Hub, но из-за недавних изменений я больше не понимаю эту информацию.

Возьмем, к примеру, buildpack-deps:bullseye. В настоящее время страница, описывающая этот образ для архитектуры amd64, выглядит следующим образом: Docker Hub page for buildpack-deps:bullseye showing the use of Debian base image

Полное имя слоя Debian – debian:462c6ce11eb710059fc8f666a474b173b1674bac6783683d74dba550e190d276, но это не соответствует ни одному существующему дескриптору:

$ sudo docker pull debian@sha256:462c6ce11eb710059fc8f666a474b173b1674bac6783683d74dba550e190d276
Error response from daemon: manifest for debian@sha256:462c6ce11eb710059fc8f666a474b173b1674bac6783683d74dba550e190d276 not found: manifest unknown: manifest unknown

Действительно, аналогичная страница для debian:bullseye показывает другой дескриптор, хотя образ на один день старше:

Docker Hub page for debian:bullseye, showing the digests that don't match

Поскольку образ debian:bullseye старше, его следовало выбрать в качестве базового образа при создании buildpack-deps:bullseye. Размер слоя одинаковый, так что это вполне может быть правдой — но я не вижу никакого ID, который был бы упомянут в buildpacks-deps:bullseye и позволял бы мне отслеживать точный, базовый ID образа с 100% гарантией.

Есть ли способ получить доступ к этой информации и если да, то как это сделать?

Ответ или решение

Для вас, как эксперта IT, наверняка важно уметь точно определить базовый образ Docker, на основе которого создаётся другой образ, используя SHA256 дайджест. Это позволяет проверять подлинность и отслеживать изменения в зависимости от актуальных основ, особенно при учёте мер безопасности и стабильности.

Теория

Чтобы глубже понять, как именно происходит эта проверка, необходимо рассмотреть, как Docker хранит и управляет образами и слоями. Docker образы состоят из множества слоёв. Каждый слой – это набор изменений по сравнению с предыдущим состоянием (например, установленные пакеты, изменения в файловой системе и т.д.). Эти слои формируются в "цепочку", где каждый слой опирается на предыдущий. Контент каждого слоя идентифицируется и проверяется с помощью SHA256 дайджеста – уникальной строки, определяющей содержимое слоя.

Однако, Docker Hub, популярный репозиторий образов Docker, не всегда предоставляет полную информацию об этих слоях, особенно если вы пытаетесь получить эти данные без прямого скачивания. Это связано с тем, что хранимые данные могут изменяться со временем из-за обновлений и перетираний.

Пример

Рассмотрим ваш пример с образом buildpack-deps:bullseye. Допустим, вы видите имя базового образа как debian:462c6ce11eb710059fc8f666a474b173b1674bac6783683d74dba550e190d276. Однако при попытке использовать этот идентификатор, он не распознается. Это может случиться из-за того, что этот идентификатор не соответствует опубликованному манифесту, видимому извне. Для вас это создаёт проблему, когда необходимо точно определить, на каком именно образе основан ваш текущий образ.

Применение

Чтобы точно определить базовый образ и его идентификатор, можно попробовать следующие подходы:

  1. Использование Docker Registry HTTP API V2: Официальное Docker API предоставляет возможность получить эти данные без загрузки образа. Вы можете обратиться к API, чтобы собрать информацию о манифесте образа, и далее – о его слоях.

    Примерный HTTP-запрос может выглядеть следующим образом:

    GET https://registry.hub.docker.com/v2/library/debian/manifests/bullseye

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

  2. Анализ Dockerfile: Если в репозитории доступен исходный файл Dockerfile, который использовался для сборки образа, вы сможете посмотреть, какой базовый образ указан там. Это же касается BuildKit, если он использовался в вашем сценарии – он сохраняет эти данные в истории коммитов.

  3. Используйте утилиты для анализа образов: Существуют утилиты, такие как skopeo, позволяющие инспектировать образы в удалённых репозиториях без их загрузки. Например, с помощью

    skopeo inspect docker://docker.io/library/buildpack-deps:bullseye

    вы получите JSON-ответ с информацией о манифесте, включая ссылки на базовые образы.

  4. МедиаType анализ и сравнение слоёв: Некоторые образы могут делиться слоями. Анализируя метаданные слоёв (их размеры и типы), можно выявить идентичные элементы и тем самым восстановить цепь до базового слоя.

Эти инструменты и методики позволят вам с большей вероятностью определить искомую информацию. Они помогут обойти текущие ограничения Docker Hub и подготовят к возможным изменениям в будущем. И помните, что Docker активно обновляет свои технологии и инструменты, так что не забывайте следить за обновлениями документации и новыми функциями API, которые могут упростить вашу работу.

Оцените материал
Добавить комментарий

Капча загружается...