Что такое реестр контейнеров: Docker Hub, GHCR и приватные registry
Основы3 минРедакция Innovialabs
Коротко
Container registry — это хранилище Docker-образов, откуда серверы и CI скачивают готовые сборки приложения. Выбирайте реестр рядом с вашим CI или облаком, тегируйте образы по коммиту или версии и настройте автоматическую очистку старых.
Коротко: что такое container registry
Container registry (реестр контейнеров) — сервер, который хранит Docker-образы и отдаёт их по запросу. Схема простая:
- CI собирает образ приложения.
- Образ отправляется в реестр командой
push. - Сервер или Kubernetes скачивает его командой
pullи запускает контейнер.
Реестр — это мост между сборкой и запуском: один и тот же образ попадает на staging и в production.
Как устроено хранение образов
Полное имя образа выглядит так:
ghcr.io/my-org/api:1.4.2
└─реестр─┘└─репозиторий─┘└тег┘
- Репозиторий — набор версий одного образа.
- Тег — человекочитаемая метка версии. Его можно перезаписать.
- Digest (
sha256:...) — неизменяемый отпечаток содержимого. Если нужна гарантия, что запускается ровно тот же образ, ссылайтесь на digest. - Слои. Образ состоит из слоёв, общие слои хранятся и скачиваются один раз — поэтому повторные
pullбыстрые.
Типичный цикл:
docker build -t ghcr.io/my-org/api:1.4.2 .
docker push ghcr.io/my-org/api:1.4.2
docker pull ghcr.io/my-org/api:1.4.2
Сравнение популярных реестров
| Реестр | Когда удобен | На что обратить внимание |
|---|---|---|
| Docker Hub | Публичные образы, open-source | Лимиты на скачивание для анонимных и бесплатных аккаунтов |
| GitHub Container Registry (GHCR) | Код и CI уже в GitHub | Права доступа привязаны к GitHub-организации |
| GitLab Container Registry | Проекты в GitLab | Встроен в проект, удобно с GitLab CI |
| Облачные (AWS ECR, Google Artifact Registry, Azure ACR) | Инфраструктура в этом облаке | Быстрый pull внутри облака, доступ через IAM |
| Self-hosted (Harbor, Distribution) | Требования к хранению данных внутри компании | Обслуживание, бэкапы и обновления — на вас |
Общий принцип: держите реестр ближе к месту запуска — это быстрее и обычно дешевле по трафику.
Стратегии тегирования
- Не полагайтесь на
latest. Непонятно, какая версия реально запущена, и откат становится лотереей. - Тег по коммиту (
api:3f9c2ab) — точная связь образа с кодом. - Семантическая версия (
api:1.4.2) — удобно для релизов и changelog. - Тег окружения (
api:staging) допустим как подвижный указатель, но деплойте по неизменяемому тегу или digest. - Хорошая практика — ставить на один образ сразу несколько тегов: версию и хэш коммита.
Очистка и хранение
Каждый CI-прогон добавляет образ, и реестр быстро растёт. Настройте retention policy:
- удалять образы без тегов (untagged);
- хранить последние N сборок для веток разработки;
- не трогать образы с релизными тегами;
- учитывать, что образ, запущенный в production, должен оставаться доступным для отката.
Большинство облачных реестров и Harbor поддерживают такие правила из коробки.
Безопасность
- Приватные образы — только в приватных репозиториях.
- Для CI используйте отдельные токены с минимальными правами, а не личный пароль.
- Не кладите секреты внутрь образа: их видно в слоях.
- Включите сканирование уязвимостей, если реестр его поддерживает.