ЯдроКодаподготовка к экзаменам
Учебная платформа

Загружаем материалы

Подготавливаем материалы и навигацию по разделу.

Docker registry: теги, latest, digest и команды push и pull

Автор: · Обновлено

Registry хранит образы для передачи между машинами. Тег — читаемое имя ссылки на образ; digest — идентификатор содержимого. Для разработки удобен тег dev, для доставки полезна связь между релизом, исходным коммитом и конкретным digest. Ни имя latest, ни сегодняшняя дата не делают ссылку неизменяемой.

Как читается имя

registry.example.com/team/api:2026.09

Здесь registry.example.com — адрес реестра, team/api — путь репозитория, 2026.09 — тег. Если registry не указан, Docker обычно обращается к Docker Hub; если тег пропущен, подразумевается latest. Latest — обычный тег, который издатель может назначить произвольному образу. Он не означает «самая новая версия по времени». Правила image tag.

Для локального эксперимента используйте dk-message:1 из урока Dockerfile:

docker tag dk-message:1 dk-message:release
docker image inspect dk-message:1 --format '{{.Id}}'
docker image inspect dk-message:release --format '{{.Id}}'

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

Pull и фиксация результата

docker pull alpine:3.22
docker image inspect alpine:3.22 --format '{{json .RepoDigests}}'
docker run --rm alpine:3.22 cat /etc/alpine-release

После pull inspect показывает известные локальному хранилищу registry-digests. Для закреплённого запуска используйте полное значение из вывода, например форму alpine@sha256:..., подставив реальный digest вместо многоточия. Digest задаёт содержимое, но не гарантирует отсутствие уязвимостей или доверие к издателю. Pull по digest.

У multi-platform образа есть digest индекса и digests вариантов архитектур. Сравнивая результаты на двух машинах, уточните, какой уровень сравниваете. Локальный .Id образа — тоже не обязательный синоним digest опубликованного манифеста.

Публикация собственного образа

Следующие команды предназначены для вашего репозитория в registry. Замените YOUR_NAMESPACE на свою область имён, создайте репозиторий по правилам сервиса и выполните вход через docker login. Не публикуйте образ, пока не проверили его содержимое: секреты, случайно добавленные COPY, распространяются вместе со слоями.

docker tag dk-message:1 YOUR_NAMESPACE/dk-message:2026.09
docker push YOUR_NAMESPACE/dk-message:2026.09
docker pull YOUR_NAMESPACE/dk-message:2026.09
docker run --rm YOUR_NAMESPACE/dk-message:2026.09

Ожидайте тот же текст приложения и digest в журнале успешного push. Для собственного registry укажите hostname и при login, и в теге. Пароль или токен не передавайте литералом командной строки; в CI используйте секрет окружения и поддерживаемый ввод --password-stdin. Команда push.

Если публикация пока не нужна, остановитесь на локальном tag и pull официального образа: эти упражнения не требуют вашего публичного репозитория.

Почему после pull работает старая версия

Pull обновляет локальную ссылку, но не подменяет файловую систему уже работающего контейнера. Для нового образа нужен новый экземпляр. В Compose последовательность обычно включает docker compose pull для сервисов с image и затем docker compose up -d. На production это часть процедуры обновления с проверками готовности и откатом, а не случайная команда во время расследования.

denied при push обычно требует проверки учётной записи, hostname и права записи в namespace. manifest unknown при pull — проверки имени и тега. no matching manifest — проверки доступности нужной платформы. Эти сообщения нельзя лечить одним общим «docker prune».

Упражнение

Создайте два локальных тега одного образа и сравните ID. Измените message.txt, соберите новый тег и запустите оба варианта. Запишите план отката: какой конкретный образ запускать и как проверить ответ. Объясните, почему перезапись тега latest не является надёжной записью истории релиза и почему digest стоит хранить вместе с метаданными сборки.

Источники