🐳 Поиск базового образа образа Docker |

🐳 Поиск базового образа образа Docker

Мануал

Введение

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

В этом руководстве мы рассмотрим возможность просмотра базового образа с помощью Docker Scout, dive и собственных команд Docker, а также изучим ограничения каждого метода.

Просмотр базового образа с помощью Docker Scout

Определение базового образа для данного Docker-образа в большинстве случаев можно легко и надежно выполнить с помощью Docker Scout.

Если мы используем Docker Engine, нам может потребоваться установить Docker Scout отдельно.

Однако он поставляется с предустановленным Docker Desktop.

Давайте посмотрим базовый образ для postgres:17.2:

docker scout quickview postgres:17.2
...
...
Target             │  postgres:17.2       │    3C    35H    16M    36L     1?
digest           │  80cbdc6c3301        │
Base image         │  debian:12-slim      │    0C     0H     0M    23L
│                      │

Результат показывает, что базовым образом, используемым для 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:

docker history postgres:17.2
IMAGE          CREATED       CREATED BY                                      SIZE      COMMENT
80cbdc6c3301   8 days ago    CMD ["postgres"]                                0B        buildkit.dockerfile.v0
<missing>      8 days ago    EXPOSE map[5432/tcp:{}]                         0B        buildkit.dockerfile.v0
<missing>      8 days ago    STOPSIGNAL SIGINT                               0B        buildkit.dockerfile.v0
...
...
...
<missing>      8 days ago    RUN /bin/sh -c set -eux;  groupadd -r postgr…   4.32kB    buildkit.dockerfile.v0
<missing>      2 weeks ago   CMD ["bash"]                                    0B        buildkit.dockerfile.v0
<missing>      2 weeks ago   ADD rootfs.tar.xz / # buildkit                  74.8MB    buildkit.dockerfile.v0

Мы знаем, что конфигурация образа обычно заканчивается инструкцией ENTRYPOINT или CMD.

🐳 Разница между ENTRYPOINT и CMD в Dockerfile

При осмотре мы обнаруживаем, что в самом конце вывода истории docker есть инструкция CMD.

Итак, обратим внимание на инструкцию ADD после второй инструкции CMD, поскольку мы ищем инструкцию, которая изменяет содержимое образа до инструкции CMD базового образа.

Определение правильного дайджеста с помощью dive

Далее мы используем инструмент dive, чтобы получить дайджест для инструкции, рассмотренной в предыдущем шаге.

Для начала мы можем создать псевдоним для инструмента dive:

alias dive='docker run -ti --rm  -v /var/run/docker.sock:/var/run/docker.sock wagoodman/dive'

Теперь мы можем проверить postgres:17.2 с помощью dive, который возвращает дайджест для инструкции:

dive postgres:17.2
┃ ● Layers ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Cmp   Size  Command
75 MB  FROM blobs
4.3 kB  RUN /bin/sh -c set -eux;     groupadd -r postgres --gid=999;
│ Layer Details ├───────────────────────────────────────────────────────
Tags:   (unavailable)
Id:     blobs
Digest: sha256:c3548211b8264f8bfa47a6727043a64f1791b82ac965a284a7ea187e9

Примечательно, что если бы мы использовали другой образ, нам, возможно, потребовалось бы приложить больше усилий или пройти больше итераций, чтобы определить дайджест слоя.

Это зависит от того, как был собран образ.

Сопоставление дайджестов

Теперь, когда у нас есть дайджест, мы можем просто использовать цикл Bash for или аналогичную конструкцию для проверки образов и поиска того, которое содержит этот дайджест:

for image in $(docker images -q)
do
if [[ $(docker inspect $image | grep "sha256:c3548211b8264f8bfa47a6727043a64f1791b82ac965a284a7ea187e971a95e2") ]]
then
docker images | grep $image
fi
done

В нашем случае на выходе мы видим два образа: 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:

docker inspect debian:12-slim | jq '.[].RootFS'
{
"Type": "layers",
"Layers": [
"sha256:c3548211b8264f8bfa47a6727043a64f1791b82ac965a284a7ea187e971a95e2"
]
}

Таким образом, мы убедились, что debian:12-slim – это базовый образ, используемый для postgres:17.2.

Этот же метод можно использовать для определения базового образа для других образов.

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

Заключение

В этой статье мы рассмотрели, почему использование Docker Scout является одним из самых надежных способов определения базового образа.

Однако, поскольку он сканирует только Docker Hub, он не может определить базовый образ для наших частных образов.

Поэтому мы также рассмотрели проверку и обнаружение базового образа вручную с помощью истории docker, погружения и базового скрипта Bash.

Хотя в некоторых случаях этот способ работает, он очень склонен к ошибкам и не так надежен.

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

см. также:

 

Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!
Добавить комментарий