Частный docker registry — это не только «куда пушить образы». В продакшене он быстро становится критичной инфраструктурой: от него зависят деплой, CI, масштабирование, контроль доступа, скорость сборок и соответствие требованиям безопасности.
На практике чаще всего выбирают один из трёх подходов: Harbor, GitLab Container Registry и Docker Distribution (он же «registry:2» — базовый open-source движок).
Ниже разберём различия по архитектуре, аутентификации, политике хранения и retention, сканированию, image signing, HA/бэкапам и типовым сценариям. Цель простая: помочь выбрать решение, которое будет удобно не только «сегодня запустить», но и «год поддерживать».
Что входит в понятие docker registry (в реальности)
На низком уровне любой registry решает три задачи:
- API совместимость с Docker Registry HTTP API v2: push/pull манифестов и слоёв, ответы клиентам, работа с токенами.
- Хранение данных: бинарные слои (blobs) и метаданные (манифесты, теги, индексы).
- Контроль доступа: кто может читать/писать, и как это интегрируется с вашей IAM/SSO.
Но «продуктовый» registry почти всегда добавляет то, без чего в проде больно:
- UI и управление проектами/репозиториями;
- сканирование уязвимостей и политики допуска;
- репликацию (pull/push) между площадками;
- сбор мусора и retention по правилам;
- подпись образов (image signing) и проверку происхождения;
- аудит, логи и интеграции с мониторингом/алертингом.
Docker Distribution: минимализм, который часто недооценивают
Docker Distribution — это базовый движок registry (обычно запускается как образ registry:2). Хороший вариант, если вам нужно «просто хранилище образов» с предсказуемым поведением и минимумом сущностей. Но важно понимать границы.
Плюсы Distribution
- Простота: мало компонентов, легко поднять и отдебажить.
- Гибкость хранения: локальная ФС, S3-совместимое хранилище и другие драйверы.
- Производительность: при корректном storage backend может быть очень быстрым.
- Низкие требования к ресурсам: обычно заметно легче, чем Harbor/GitLab.
Минусы Distribution (ключевые для продакшена)
- RBAC «не про него»: часто всё сводится к basic auth/htpasswd или внешнему token service, а управление доступом превращается в кастомную историю.
- Retention не «из коробки»: жизненный цикл тегов/образов придётся строить скриптами и процессами (и помнить, что удаление тегов и освобождение места — разные операции).
- Garbage Collection требует дисциплины: GC запускается отдельно и нередко требует окна обслуживания (зависит от режима и нагрузки).
- Security-фичи отсутствуют: сканирование, подпись, политики допуска — всё внешними инструментами.
- UI нет: любая «витрина» — сторонний проект или внутренняя разработка.
Distribution хорош как строительный блок. Но в проде он часто превращается в конструктор: аутентификация, аудит, retention и сканирование появляются вокруг него отдельными сервисами и регламентами.
Если вы выбираете Distribution, заранее планируйте инфраструктуру под него (storage, бэкапы метаданных, процессы GC) так же серьёзно, как для «больших» решений.
Если registry нужен рядом с кластерами и CI, обычно удобнее вынести его на отдельные ресурсы: VDS даёт предсказуемую производительность диска/сети и упрощает масштабирование по мере роста образов и числа pull/push.
По теме операционной безопасности контейнеров может пригодиться отдельный материал: изоляция контейнеров через gVisor и Firecracker — полезный контекст для обсуждения trust boundary и supply chain.
Harbor: registry как продукт для платформенной команды
Harbor — популярный self-hosted registry для команд, которые строят внутреннюю платформу (Kubernetes, GitOps, multi-cluster, несколько окружений). Он задуман как «enterprise registry» поверх стандартной совместимости, с UI, проектами и политиками.
Что Harbor даёт «в базе»
- Проекты и RBAC: роли на уровне проекта, группы, robot accounts.
- UI: удобно для разработчиков и админов, меньше «ручной работы» вокруг тегов/репозиториев.
- Retention policies: правила по количеству артефактов, тегам, возрасту, маскам, расписаниям.
- Сканирование уязвимостей: обычно через Trivy (зависит от версии и настройки).
- Репликация: синхронизация между registry для DR/edge-сценариев.
- Поддержка OCI-артефактов: не только docker images, но и другие OCI-совместимые типы.
Image signing в Harbor: что уточнить до выбора
Под «image signing» сегодня подразумеваются разные подходы: Notary v1/v2, Cosign (Sigstore), подпись OCI-артефактов и политики верификации через admission в Kubernetes. Поэтому перед внедрением важно ответить на два вопроса:
- Чем именно подписываете: Notary/Cosign/другое.
- Где проверяете подпись: в CI, в CD, на уровне admission controller, в рантайм-политиках.
С практической точки зрения Harbor хорош тем, что «естественно» ложится в platform engineering: проекты, политики, роботы, репликация, аудит. Но галочка «подпись поддерживается» не отменяет проектирования end-to-end цепочки доверия.
Операционные особенности Harbor
- Это набор сервисов: registry, core, jobservice, БД, кеш и т.д. Значит, мониторить и обновлять нужно несколько компонентов.
- Обновления требуют аккуратности: бэкапы БД и конфигурации, проверка миграций, совместимость сканеров.
- Тюнинг storage: производительность и стоимость сильно зависят от backend storage (локальные диски, S3, NFS) и профиля доступа.
GitLab Container Registry: удобство «рядом с кодом»
GitLab Container Registry логичен, если GitLab уже центр вашего SDLC. Его сильная сторона не в том, что registry «самый функциональный», а в том, что он встроен в GitLab: проекты, пользователи, токены, CI/CD, права и аудит.
Сильные стороны GitLab Container Registry
- Единая модель доступа: права на registry наследуются от проекта/группы, привычные токены и роли.
- CI/CD интеграция: публикация образов — типовой паттерн пайплайна, без отдельной IAM-модели.
- Аудит и управление: если GitLab — ваша платформа, проще сопровождать одной командой и в одном контуре.
- Cleanup/политики хранения: механизмы есть, но детали зависят от версии, редакции и настроек.
Где GitLab Registry может быть не лучшим выбором
- Если GitLab нет или он «не главный»: тянуть GitLab ради registry обычно избыточно.
- Если нужен registry как независимый продукт: multi-tenant и платформенные сценарии часто удобнее решать «registry-first» подходом (как в Harbor).
- Если важна независимая геораспределённость: DR/репликация может упираться в общую архитектуру GitLab, особенно если хотите автономные площадки.
Retention: почему это один из главных критериев
Retention звучит скучно, но это то, что чаще всего «убивает» registry в эксплуатации. Слои образов растут быстро: каждый merge, каждый релиз-кандидат, каждое окружение. Без политики хранения через несколько месяцев обычно случается одно из трёх:
- заканчивается место, и CI падает в неожиданный момент;
- теги удаляются вручную, но место не освобождается (blob’ы ещё достижимы или GC не запускался);
- удаляется «лишнее», и ломается воспроизводимость старых релизов или откат.
Retention на практике: что продумать заранее
- Какие теги «вечные»: релизные версии, security-hotfix, образы для DR.
- Какие теги «временные»: PR/branch теги, nightly, промежуточные сборки.
- Окно отката: сколько времени реально нужно хранить образы для rollback.
- Связь с SBOM/сканированием: где храните результаты проверок и как долго.
Harbor обычно выигрывает удобством политик и видимостью в UI. GitLab выигрывает тем, что retention проще увязать с жизненным циклом проекта/веток/релизов. Distribution потребует отдельной дисциплины и автоматизации.
Image signing: не «фича», а процесс
Image signing часто ждут как кнопку: «включил — и безопасно». На практике подпись — это цепочка управления доверием:
- Где хранится ключ и кто имеет право подписывать.
- Какие события вызывают подпись: каждый билд, только релиз, только после тестов.
- Где проверяется подпись: CI, CD, Kubernetes admission, рантайм-политики.
- Что делать при провале: блокировать деплой, заводить инцидент, разрешать override по исключению.
Harbor и GitLab могут быть частью этого процесса, но редко закрывают его полностью без окружающей инфраструктуры: управления ключами, политик в кластере и контроля supply chain. Distribution почти всегда означает «собери сам».
Если вы заворачиваете доступ к registry за TLS (а в проде это must-have), заранее продумайте жизненный цикл сертификатов и ротацию. Для управляемой покупки и обновлений в корпоративных контурах часто берут SSL-сертификаты, чтобы минимизировать простои из-за внезапно истёкшего TLS.
Производительность, HA и хранение: где реальные грабли
Registry — это I/O и сеть. В продакшене вы упираетесь в три вещи: количество одновременных pull/push, латентность до storage и размер/частоту слоёв.
Storage backend
- Локальные диски: простая схема и высокая скорость, но сложнее HA и миграции.
- S3-совместимое хранилище: легче масштабировать и строить DR, но важны latency и корректная настройка кеширования/прокси.
- NFS/общая ФС: кажется удобной, но часто становится узким местом по latency и блокировкам.
HA по-взрослому
Для Harbor и GitLab Container Registry HA — это не только «поднять два инстанса». Проверьте, что у вас закрыты базовые зависимости:
- внешняя БД и её отказоустойчивость;
- кеши/очереди (если используются);
- единый backend storage для blobs;
- стратегия обновления без простоя и тестовый контур;
- бэкапы метаданных (без них blobs мало что стоят).
Distribution в HA-сценариях часто строят вокруг общего object storage и нескольких stateless-инстансов, но вопросы аутентификации и управления доступом остаются снаружи.
Сравнение по критериям (коротко, но по делу)
Когда выбирать Docker Distribution
- Нужен минимальный registry без «платформы вокруг».
- Вы готовы сами построить аутентификацию, аудит, retention и процессы GC.
- Вам важны простота и контроль над каждым компонентом.
Когда выбирать Harbor
- Нужен registry как самостоятельный продукт с UI, проектами, RBAC.
- Важны встроенные политики retention, репликация и сканирование.
- Вы строите платформу вокруг Kubernetes/OCI и хотите централизованный контур артефактов.
Когда выбирать GitLab Container Registry
- GitLab уже основной инструмент, и нужна «бесшовная» интеграция.
- Критично удобство для команд разработки и CI/CD.
- Хотите управлять доступом и жизненным циклом образов через модель GitLab проектов/групп.
Практический чеклист выбора для админа/DevOps
Перед тем как решать «Harbor vs GitLab Container Registry vs Docker Distribution», ответьте на вопросы ниже. Они обычно лучше таблиц показывают, где вы будете страдать в эксплуатации.
- Идентификация и доступ: нужен ли SSO/LDAP/OIDC, robot accounts, аудит действий?
- Retention: можете ли описать правила хранения в 3–5 понятных политик?
- Безопасность: нужен ли встроенный сканер, какие SLA на реакцию по критическим CVE?
- Image signing: кто подписывает и где проверяется подпись, что блокируем?
- DR: нужен ли второй сайт, как быстро вы должны восстановить возможность pull?
- Нагрузка: сколько одновременных pull на деплой, сколько трафика в пиковые окна?
- Команда: кто владеет registry — платформа, SRE, команда GitLab, отдельный DevOps?
Типовые архитектуры (без «магии»)
Сценарий 1: Маленькая команда, один кластер, минимум зависимостей
Часто подходит Docker Distribution на object storage или быстрые локальные диски, плюс внешний сканер в CI и строгая политика тегирования. Но важно заранее автоматизировать удаление тегов и запуск GC, чтобы не «взорваться» по диску через пару месяцев.
Сценарий 2: Платформенная команда и несколько окружений
Harbor обычно удобнее: проекты, репликация между площадками, retention, сканирование и понятный UI. Особенно если registry должен обслуживать много команд и вам нужна «витрина артефактов».
Сценарий 3: GitLab как единая платформа разработки
GitLab Container Registry логичен, когда всё завязано на GitLab: пайплайны, permissions, релизы, approvals. В таком случае вы снижаете операционные издержки за счёт «одного центра управления», даже если по отдельным возможностям Harbor может быть шире.
Итог: что выбрать
Если свести всё к практике:
- Docker Distribution — берите, когда нужен лёгкий и предсказуемый движок, а остальное вы готовы строить вокруг (или оно не нужно).
- Harbor — берите, когда нужен самостоятельный registry с UI, RBAC, репликацией, сканированием и удобным retention.
- GitLab Container Registry — берите, когда GitLab уже ядро процессов и важнее всего интеграция с проектами и CI/CD.
И не выбирайте registry по списку «фич». Выбирайте по тому, как вы будете жить с ним каждый день: как чистить, как обновлять, как делать DR, как обеспечивать цепочку доверия и как гарантировать, что нужный образ всегда можно скачать в момент деплоя.
