Образи, шари, теги, 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 підвищує відтворюваність, але не встановлює security updates автоматично: 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. Зрозумілий 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.