Перейти к основному содержимому

DockerHub и реестры образов

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Инженеру

DockerHub и реестры образов​

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

По аналогии с GitHub, у Docker есть реестр с тысячами готовых образов — Docker Hub. Это самое популярное место для поиска и загрузки образов.

Play ITЗагрузка интерактивного демо…

Как выбирать образ для проекта​

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

  • образ поддерживается официальной командой проекта или верифицированным издателем;
  • есть понятная версия и регулярные обновления;
  • документация описывает переменные окружения, порты и ограничения;
  • образ подходит по архитектуре (amd64, arm64) и лицензии;
  • история тегов прозрачная, без резких "плавающих" изменений.

Карманный чеклист из девяти пунктов (официальный образ, pinned-тег, сканирование) — 9 практик Dockerfile.

Поиск образов через интерфейс.​

Чтобы найти образ на Docker Hub, откройте hub.docker.com и введите в поиск название технологии: nginx, mysql, python.

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

После того, как нашли нужный образ, вы можете запустить его с помощью команды docker run. Например:

docker run -d -p 80:80 nginx

Разбор:

  • docker run — если образа nginx нет локально, Engine сначала выполнит pull с Docker Hub (по умолчанию nginx:latest).
  • -d — контейнер в фоне.
  • -p 80:80 — HTTP на порту 80 хоста уходит в порт 80 контейнера.
  • nginx — официальный образ веб-сервера; подходит как быстрый smoke-тест Docker.

Эта команда скачает и запустит официальный образ Nginx.

Поиск образов через CLI​

Если удобнее работать в терминале, используйте docker search для поиска образов прямо из CLI:

docker search python

Разбор:

  • docker search — поиск образов в Docker Hub (или настроенном index) по подстроке python.
  • Результат — таблица — NAME, DESCRIPTION, STARS, OFFICIAL, AUTOMATED.
  • OFFICIAL помечает образы, поддерживаемые upstream-проектом или Docker Library.
  • Для продакшена после search обычно открывают страницу образа и смотрят теги и digest.

Вывод команды будет в виде таблицы:

  • NAME : Название образа.
  • DESCRIPTION : Краткое описание.
  • STARS : Популярность образа (чем больше звезд, тем лучше).
  • OFFICIAL : Указывает, является ли образ официальным.
  • AUTOMATED : Указывает, был ли образ автоматически собран.

Теги, digest и воспроизводимость​

Для стабильных релизов важна точная фиксация версии образа.

  • Тег (myapp:1.4.2) удобен для людей и релизного процесса.
  • Digest (@sha256:...) фиксирует конкретный артефакт и защищает от подмены под тем же тегом.

Пример запуска по digest:

docker pull nginx@sha256:<digest>
docker run nginx@sha256:<digest>

Разбор:

  • nginx@sha256:<digest> — ссылка на конкретный слой манифеста, а не на плавающий тег latest.
  • docker pull — скачивает ровно тот артефакт, чей digest указан; тег может совпасть у другого содержимого.
  • docker run с тем же digest — гарантирует тот же бинарный состав при запуске на любом хосте.
  • <digest> заменяют на значение с Hub или из docker inspect после pull.

В продакшене команда обычно сочетает оба подхода: хранит релизный тег и проверяемый digest в CI/CD.

Другие реестры контейнеров​

Помимо Docker Hub, существуют другие реестры образов:

  • Quay.io — альтернативный реестр контейнеров, который часто используется для корпоративных проектов.
  • GitHub Container Registry — реестр, интегрированный с GitHub. Многие проекты публикуют свои образы здесь.
  • Amazon ECR — сервис AWS для хранения и управления Docker-образами.
  • Google GCR — реестр от Google Cloud.

Если хотим использовать образ из другого реестра, нужно указать полный путь к образу, включая домен реестра. Например:

docker run quay.io/bitnami/nginx

Разбор:

  • quay.io — хост альтернативного registry (Red Hat Quay).
  • bitnami/nginx — путь репозитория: организация/имя образа на этом registry.
  • Без тега подставляется latest — в проде лучше указывать версию явно.
  • Полное имя registry/namespace/image:tag обязательно, если образ не на Docker Hub.

Для работы с Amazon ECR придётся сначала выполнить аутентификацию:

aws ecr get-login-password | docker login --username AWS --password-stdin <aws_account_id>.dkr.ecr.<region>.amazonaws.com

Разбор:

  • aws ecr get-login-password — одноразовый токен для ECR (нужны IAM-права и настроенный AWS CLI).
  • | — передаёт пароль в stdin следующей команды.
  • docker login --username AWS --password-stdin — стандартный логин Docker в ECR; пользователь всегда AWS.
  • URL registry — <account>.dkr.ecr.<region>.amazonaws.com; подставьте свой account ID и регион.
  • Без успешного login docker pull/run из ECR вернёт unauthorized.

И только затем можно запустить образ:

docker run <aws_account_id>.dkr.ecr.<region>.amazonaws.com/repo-name:tag

Разбор:

  • Полное имя образа включает хост ECR, имя репозитория repo-name и тег tag.
  • После docker login Engine может скачать слои из приватного registry аккаунта.
  • docker run создаёт контейнер из этого образа (добавьте -d, -p, env по необходимости).
  • Плейсхолдеры <aws_account_id>, <region>, repo-name, tag — ваши значения из консоли AWS.

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

docker run python:3.9
docker run python:3.10
docker run python:latest

Разбор:

  • python:3.9 и python:3.10 — разные минорные ветки интерпретатора; образы несовместимы по содержимому слоёв.
  • python:latest — указатель на последний стабильный тег библиотеки; может смениться при следующем pull.
  • Каждая команда при отсутствии локального образа скачает соответствующий тег с Hub.
  • В CI/CD фиксируют конкретный тег или digest, а не полагаются на latest.

latest: Последняя версия (по умолчанию).

Увидеть доступные теги можно на странице образа в реестре. К примеру, на Docker Hub будет вкладка Tags.

image-10.png

Создание своих образов​

Если вы не нашли подходящий образ, вы можете создать свой, используя Dockerfile. После создания образа вы можете загрузить его в Docker Hub или другой реестр.

Нужно сначала создать аккаунт на Docker Hub, а затем авторизоваться в CLI:

docker login

Разбор:

  • Аутентификация CLI в Docker Hub (логин/пароль или token).
  • Учётные данные сохраняются в ~/.docker/config.json для последующих push/pull.
  • Для Hub имя пользователя в теге образа должно совпадать с аккаунтом (или организацией).

Потом нужно пометить образ:

docker tag my-image username/my-image:tag

Разбор:

  • docker tag — создаёт дополнительную метку того же image ID под именем для registry.
  • my-image — локальное имя после docker build.
  • username/my-image:tag — формат Hub: пользователь/репозиторий:тег.
  • Без корректного тега push уйдёт не в тот репозиторий или завершится ошибкой.

И загрузить:

docker push username/my-image:tag

Разбор:

  • Загружает все недостающие слои образа в удалённый registry.
  • username/my-image:tag должен совпадать с тем, что указали в docker tag.
  • После push образ доступен команде через docker pull username/my-image:tag.
  • Крупные образы push'ат дольше — слои, уже есть в registry, не пересылаются.

Базовая модель публикации в команде​

Обычно процесс строят так:

  1. CI собирает образ из Dockerfile.
  2. Образ тегируется версией релиза и коротким commit SHA.
  3. Выполняется сканирование уязвимостей.
  4. Только после проверки образ публикуется в registry.
  5. Деплой использует именно опубликованный тег из реестра.

Такой процесс заметно снижает вероятность "ручных" и неотслеживаемых изменений.

Локальные образы​

Запуск контейнера из образа (локальный кэш → реестр):

docker run <image>:<tag>

Разбор:

  • <image>:<tag> — имя репозитория и версия; без тега Docker подставит :latest.
  • Engine сначала ищет образ в локальном store, затем тянет из настроенного registry.
  • docker run создаёт контейнерный слой поверх образа (writable layer).
  • Плейсхолдеры заменяют на реальные значения, например nginx:1.25-alpine.

Далее Docker:

  • Docker проверяет, есть ли указанный образ в локальном хранилище образов на ПК. Локальное хранилище — это кэш, где хранятся все образы, которые скачали или создали. Если тег не указан, будет подставляться тег latest.
  • Если образ существует в локальном хранилище, Docker будет использовать его для запуска;
  • Если образ не найден локально, Docker пытается скачать его из удалённого реестра:
    • отправляет запрос в реестр, чтобы найти образ с указанным именем и тегом;
    • если образ найден, он скачивается и сохраняется в локальном хранилище;
    • после загрузки образа Docker запускает контейнер.

Таким образом, Docker работает по приоритету:

Локальное хранилище - Удалённый реестр - Ошибка (если нет нигде).

Разбор:

  • Схема приоритета при docker run: сначала локальный кэш образов на хосте.
  • Если тега нет локально — pull из настроенного registry (Docker Hub, ECR и т.д.).
  • Если образ нигде не найден — ошибка manifest unknown / pull access denied.
  • Строка не команда shell, а мнемоника цепочки решений Engine.
  • Понимание порядка помогает отладить "почему тянется старая версия" (кэш vs registry).

Локальные образы хранятся в системе в виде слоёв (layers). Каждый слой представляет собой изменение, сделанное в процессе сборки образа. Это позволяет эффективно использовать дисковое пространство и кэширование.

Локальные образы хранятся в каталоге Docker на компьютере. Расположение зависит от операционной системы:

  • Linux : /var/lib/docker/
  • Windows (Docker Desktop) : Внутри виртуальной машины WSL2 или Hyper-V.
  • macOS (Docker Desktop) : Внутри виртуальной машины. Список локальных образов:
docker images

Разбор:

  • Список образов в локальном кэше — REPOSITORY, TAG, IMAGE ID, CREATED, SIZE.
  • Один IMAGE ID может иметь несколько тегов (после docker tag).
  • Помогает понять, что уже скачано и сколько места занимает store.

В выводе будут следующие столбцы:

  • REPOSITORY : Имя образа.
  • TAG : Тег образа (версия).
  • IMAGE ID : Уникальный идентификатор образа.
  • CREATED : Дата создания образа.
  • SIZE : Размер образа.

Чтобы удалить образ, используется команда:

docker rmi <image_id>

Разбор:

  • docker rmi — удаляет образ по IMAGE ID или имени:тегу.
  • Нельзя удалить образ, на котором висит существующий контейнер (даже остановленный) — сначала docker rm.
  • Удаление освобождает диск; общие слои с другими образами остаются, пока есть ссылки.

Если образ используется хотя бы одним контейнером (даже остановленным), Docker выдаст ошибку. Поэтому перед удалением образа нужно удалить сначала контейнер:

docker rm <container_id>

Разбор:

  • Удаляет контейнер (остановленный; для работающего — -f).
  • <container_id> — ID или имя из docker ps -a.
  • После удаления всех контейнеров, ссылающихся на образ, можно выполнить docker rmi.

Когда Docker скачивает образ из удалённого реестра, он делает это поэтапно, слой за слоем. Образ состоит из нескольких слоёв, каждый из которых соответствует одной инструкции в Dockerfile. Например:

FROM ubuntu:20.04
RUN apt-get update
RUN apt-get install -y python3

Разбор:

  • FROM ubuntu:20.04 — базовый слой образа Ubuntu 20.04.
  • RUN apt-get update — отдельный слой с обновлённым индексом пакетов внутри образа.
  • RUN apt-get install -y python3 — ещё один слой с установленным Python; -y — без интерактивных вопросов apt.
  • При pull каждый слой качается отдельно; уже имеющиеся слои (тот же ubuntu:20.04) переиспользуются.

Здесь будет три слоя:

  • Базовый образ ubuntu:20.04.
  • Результат выполнения apt-get update.
  • Результат выполнения apt-get install -y python3.

Docker загружает только те слои, которых ещё нет в локальном хранилище. Если часть слоёв уже есть (например, базовый образ ubuntu:20.04), Docker использует их повторно.

Чтобы узнать, какие образы были скачаны из удалённого реестра, а какие созданы локально, используйте команду:

docker inspect <image_id>

Разбор:

  • Выводит JSON-метаданные образа — Env, Cmd, Entrypoint, RootFS (список layer diff IDs), Labels, RepoTags.
  • По RootFS.Layers видно цепочку слоёв и отличие от другого тега.
  • <image_id> — короткий или полный ID из docker images.
  • Полезно отличить локально собранный образ от скачанного и проверить digest.

Docker активно использует кэширование для оптимизации работы с образами. Если вы запускаете один и тот же образ несколько раз, Docker не будет заново скачивать его, если он уже есть локально. Если вы создаёте новый образ с помощью Dockerfile, Docker использует кэширование слоёв, чтобы ускорить процесс сборки.

Связанные статьи​

Содержание