Введение
Образы играют важную роль в основной функциональности Docker. Иногда сложная история работы Docker с образами затрудняет определение правильного базового образа для конкретного образа Docker.
В этом руководстве мы рассмотрим возможность просмотра базового образа с помощью Docker Scout, dive и собственных команд Docker, а также изучим ограничения каждого метода.
Просмотр базового образа с помощью Docker Scout
Определение базового образа для данного Docker-образа в большинстве случаев можно легко и надежно выполнить с помощью Docker Scout.
Если мы используем Docker Engine, нам может потребоваться установить Docker Scout отдельно.
Однако он поставляется с предустановленным Docker Desktop.
Давайте посмотрим базовый образ для postgres:17.2:
Результат показывает, что базовым образом, используемым для postgres:17.2, является debian:12-slim.
Однако при использовании Docker Scout есть некоторые ограничения, поскольку для определения базового образа он полагается исключительно на Docker Hub.
В результате, если у нас есть образ, созданный и хранящийся вне реджестри Docker Hub, Docker Scout не сможет определить его, когда мы будем использовать его в качестве основы для другого образа.
Поиск базового образа вручную
В случаях, когда Docker Scout не может определить базовый образ, может потребоваться ручная проверка для определения правильного базового образа.
Однако ручная идентификация может привести к неверным предположениям о базовом образе.
Это ограничение возникает из-за того, что при создании образа Docker в слое нового образа сохраняются только изменения, внесенные в базовый образ.
Метаданные о базовом образе, использованном для образа, не содержатся ни в одном из слоев, что затрудняет определение правильного базового образа.
Давайте рассмотрим процесс поиска базового образа:
- Определите последний слой базового образа с помощью команды docker history.
- Просмотрим дайджест этого слоя с помощью инструмента dive.
- Сопоставим дайджест с дайджестом слоев существующих на данный момент образов в развертывании Docker.
Используемый нами процесс предполагает, что базовый образ находится на той же машине.
Однако если базовый образ не присутствует на той же машине, процесс идентификации становится практически невозможным.
Использование истории docker для определения базового образа
Опять же, поскольку большинство частных образов обычно хранят свой базовый образ локально, мы предполагаем, что базовый образ присутствует в системе.
Перечислим все слои в postgres:17.2:
Мы знаем, что конфигурация образа обычно заканчивается инструкцией ENTRYPOINT или CMD.
🐳 Разница между ENTRYPOINT и CMD в Dockerfile
При осмотре мы обнаруживаем, что в самом конце вывода истории docker есть инструкция CMD.
Итак, обратим внимание на инструкцию ADD после второй инструкции CMD, поскольку мы ищем инструкцию, которая изменяет содержимое образа до инструкции CMD базового образа.
Определение правильного дайджеста с помощью dive
Далее мы используем инструмент dive, чтобы получить дайджест для инструкции, рассмотренной в предыдущем шаге.
Для начала мы можем создать псевдоним для инструмента dive:
Теперь мы можем проверить postgres:17.2 с помощью dive, который возвращает дайджест для инструкции:
Примечательно, что если бы мы использовали другой образ, нам, возможно, потребовалось бы приложить больше усилий или пройти больше итераций, чтобы определить дайджест слоя.
Это зависит от того, как был собран образ.
Сопоставление дайджестов
Теперь, когда у нас есть дайджест, мы можем просто использовать цикл Bash for или аналогичную конструкцию для проверки образов и поиска того, которое содержит этот дайджест:
В нашем случае на выходе мы видим два образа: postgres:17.2 и debian:12-slim:
postgres 17.2 80cbdc6c3301 8 days ago 435MB debian 12-slim 762d928e7cfb 2 weeks ago 74.8MB
Поскольку мы уже проверяем postgres:17.2, переходим к debian:12-slim, чтобы убедиться, что он содержит только те слои, которые мы видели при использовании dive:
Таким образом, мы убедились, что debian:12-slim – это базовый образ, используемый для postgres:17.2.
Этот же метод можно использовать для определения базового образа для других образов.
Очень важно, что когда у нас есть несколько образов, ответвляющихся от одного и того же образа в качестве базового, процесс идентификации может стать утомительным.
Заключение
В этой статье мы рассмотрели, почему использование Docker Scout является одним из самых надежных способов определения базового образа.
Однако, поскольку он сканирует только Docker Hub, он не может определить базовый образ для наших частных образов.
Поэтому мы также рассмотрели проверку и обнаружение базового образа вручную с помощью истории docker, погружения и базового скрипта Bash.
Хотя в некоторых случаях этот способ работает, он очень склонен к ошибкам и не так надежен.
Это особенно актуально, когда базовый образ не существует в той же системе, так как в этом случае метод становится непригодным.
см. также:
- 🐳 Как очистить логи контейнера Docker
- 🐳 Самоучитель по логированию контейнеров Docker для начинающих
- 🐳 Монтируем безопасные секреты во временя сборки с помощью Docker и Docker Compose
- 🐳 Разница между chroot и Docker
- 🐳 Защита паролей в Docker
- 🐳 Как средства Docker защищают контейнерные среды
- 📡 Передача любых файлов из командной строки – создание собственного безопасного и быстрого сайта временной передачи c Docker