Образы, слои, теги, digest и registry

После модуля вы сможете отличить repository, tag, digest, image ID, manifest и layer; объяснить pull через Registry API; проверить выбранную platform и использовать immutable reference в delivery.

• слои адресуются по содержимому и переиспользуются
• tag — изменяемый указатель, digest — идентификатор содержимого
• manifest описывает один platform image
• image index объединяет manifests разных платформ
• registry хранит manifests и blobs, а не запущенные containers

Полная ссылка имеет вид registry/namespace/repository:tag или registry/namespace/repository@digest. Для короткого alpine:3.21 Docker подставляет Docker Hub и официальный namespace library. Tag удобен человеку, но владелец repository может переместить его на новый manifest.

Digest вычисляется из канонического содержимого объекта. Pull по digest фиксирует конкретный manifest и проверяет полученное содержимое. Pinning повышает воспроизводимость, но не устанавливает обновления безопасности автоматически: digest должен обновляться контролируемым процессом.

Filesystem layer содержит tar-представление изменений. Image config хранит command, environment, working directory, history и ссылку на rootfs diff IDs. Manifest связывает config blob и сжатые layer blobs с media type, digest и size.

Multi-platform image обычно публикуется как OCI image index или manifest list. Index содержит descriptors platform-specific manifests. При pull Engine выбирает os/architecture/variant хоста; одинаковый tag поэтому может привести к разным platform manifests, но каждый выбор проверяется digest.

Одинаковый blob digest позволяет registry, local store и build cache не хранить и не передавать дубликат. Image ID — SHA256 digest image configuration; он не заменяет registry manifest digest из RepoDigests.

Union filesystem формирует единый rootfs из неизменяемых layers. Удаление или изменение файла создаёт запись следующего слоя, а старые bytes остаются в нижнем. Поэтому удаление secret в позднем Dockerfile step не удаляет его из истории образа.

Client обращается к /v2/, получает 200 или authentication challenge 401, получает scoped Bearer token, запрашивает manifest по tag/digest и затем недостающие blobs по digest. Redirect на object storage является нормальной частью Distribution API.

Клиент проверяет digest скачанного содержимого. Ошибки MANIFEST_UNKNOWN, UNAUTHORIZED, DENIED и TOOMANYREQUESTS требуют разных гипотез: неверный reference, credentials/scope, policy или rate limit. Повтор pull не исправляет неправильную platform или отсутствующий tag.

Digest гарантирует целостность и идентичность bytes, но не отвечает, кто и зачем их собрал. Доверие дополняют allowlist registry, минимальный base image, SBOM, vulnerability policy, signature и provenance attestation. Эти механизмы подробно рассматриваются в модуле 14.

Не используйте latest в production deployment. Осмысленный human-readable tag можно публиковать вместе с immutable digest, но фактический release должен сохранять resolved digest как evidence.

• Всегда записывайте полный source registry и namespace
• Не сравнивайте images только по tag
• Для расследования сохраняйте RepoDigests, image ID, platform и timestamps
• Не используйте docker image prune до сбора evidence
• Не распаковывайте неизвестные tar archives с правами root
• Разделяйте registry authentication failure и image integrity
• Проверяйте доступность нужной platform до rollout

Загрузите Alpine, изучите metadata и history, затем экспортируйте Docker image archive в учебный временный файл. Не делайте вывод о содержимом слоя только по CREATED BY: проверяйте manifest и blobs.

docker pull alpine:3.21
docker image ls --digests alpine
docker image inspect alpine:3.21
docker image history --no-trunc alpine:3.21
docker image inspect --format 'id={{.Id}} repoDigests={{json .RepoDigests}} size={{.Size}}' alpine:3.21

docker image save --output /tmp/docker-m3-alpine.tar alpine:3.21
tar -tf /tmp/docker-m3-alpine.tar | sort
tar -xOf /tmp/docker-m3-alpine.tar manifest.json | jq
rm /tmp/docker-m3-alpine.tar

docker image tag alpine:3.21 docker-m3:lab
docker image inspect --format '{{.Id}}' alpine:3.21 docker-m3:lab
image_ref=$(docker image inspect --format '{{index .RepoDigests 0}}' alpine:3.21)
printf 'immutable_ref=%s\n' "$image_ref"
docker pull "$image_ref"
docker image ls --digests --filter reference='alpine*'
docker image rm docker-m3:lab

docker buildx version
docker buildx imagetools inspect alpine:3.21
docker image inspect --format 'os={{.Os}} arch={{.Architecture}} variant={{.Variant}}' alpine:3.21

Критерий: два тега показывают один image ID; RepoDigest сохранён; archive содержит metadata и blobs; выбранная runtime platform объяснена через manifest index.

Запросите отсутствующий tag и классифицируйте отказ. Проверка /v2/ Docker Hub ожидаемо может вернуть 401 с WWW-Authenticate: это подтверждает Registry API и сообщает authentication realm, а не означает недоступность registry.

curl -sS -D - -o /dev/null https://registry-1.docker.io/v2/
docker pull alpine:tag-does-not-exist
docker info --format '{{json .RegistryConfig}}' | jq
docker image ls --filter reference='alpine*'
docker system df

• проверить точное имя, registry, namespace, tag или digest
• проверить DNS, TLS и системное время
• прочитать WWW-Authenticate и scope token
• проверить login без вывода credentials
• проверить platform descriptors
• учесть proxy, mirror и rate limits
• не подменять проблему случайным latest

• Почему tag не является immutable identifier?
• Чем image ID отличается от RepoDigest?
• Что связывает manifest?
• Зачем нужен image index?
• Почему удалённый поздним RUN secret остаётся в layer history?
• Что означает 401 от /v2/?
• Чего digest не доказывает об авторе image?

Модуль освоен, если вы разрешаете tag в digest, объясняете platform selection, исследуете archive без запуска и строите диагностику pull по слоям DNS → TLS → auth → manifest → platform → blob integrity.