Что делает команда docker pull?

Что проверяют

Понимаете ли вы, откуда берётся образ вашего сервиса на сборке и на проде. От java-разработчика ждут не пересказа справки, а понимания реестров, тегов и воспроизводимости: почему одна и та же строка запуска вчера и сегодня может дать разный контейнер.

Как отвечать

docker pull скачивает образ из реестра в локальное хранилище демона и ничего не запускает. Если имя без реестра, подставляется Docker Hub; если без тега, подставляется latest. Скачиваются слои, которых нет локально, уже имеющиеся переиспользуются по своему дайджесту, поэтому второй образ на той же базе тянется заметно быстрее.

Что стоит упомянуть:

• пин по дайджесту образ@sha256:... даёт неизменяемую ссылку, тег такой гарантии не даёт;
• --platform linux/amd64 спасает, когда собираете на ноутбуке с архитектурой arm, а сервер amd64;
• приватный реестр требует docker login, в CI это отдельный шаг;
• --all-tags тянет все теги репозитория, в скриптах почти всегда ошибка.

Для Java рядом лежит практический слой: базовый образ с JRE тянется один раз и кэшируется, а слой с вашим jar меняется каждую сборку, поэтому в Dockerfile зависимости кладут отдельным слоем от кода приложения.

Где спотыкаются

Говорят, что pull сначала проверяет локальный кэш и не ходит в сеть, если образ есть. Наоборот: pull всегда запрашивает у реестра манифест для тега и докачивает недостающие слои. Работа «по локальному, без сети» это поведение docker run, когда образ уже загружен.

Считают latest обозначением самой свежей версии. Это обычный подвижный тег, который кто-то вручную переставляет: два pull в разные дни могут дать разные образы. На проде фиксируют конкретный тег или дайджест.

Не учитывают ограничения публичного реестра. Анонимные загрузки с одного адреса лимитируются по частоте, и в CI это выглядит как внезапная ошибка о превышении лимита запросов. Лечится авторизацией или зеркалом реестра внутри своей инфраструктуры.