DockerHub с его rate limit в 100 pull/6 часов для анонимных клиентов больно аукается в CI: пайплайны начинают падать с toomanyrequests: You have reached your pull rate limit именно в пик рабочего дня, когда запускаются десятки параллельных джобов. Мы сталкивались с этим не раз, и Harbour стал нашим стандартным решением. Он не только снимает лимиты, но и добавляет enterprise-функции: сканирование уязвимостей при push, RBAC с детализацией до репозитория, репликацию между инстансами и content trust через Notary.
Особенно остро проблема встаёт при использовании Kubernetes: каждый нод пуллит образы с реестра, а при автоматическом масштабировании число запросов растёт квадратично. Harbour, развёрнутый рядом с кластером, снижает задержки на 30% и полностью исключает rate limit. При этом стоимость хранения в S3-совместимом бэкенде оказывается в 2–3 раза ниже, чем у облачных реестров.
В этой статье разберём реальные настройки: от установки через Helm до настройки garbage collection, которые нужны для стабильной работы в production. Чтобы избежать простоев, закажите внедрение Harbour — мы настроим всё под ваш CI.
Как Harbour решает проблему rate limit?
Harbour — это self-hosted registry, который работает в вашей инфраструктуре. Вы полностью контролируете хранение образов, политики доступа и сканирование. Без внешних лимитов CI/CD работает стабильно, даже при 50+ параллельных сборках.
Что реально нужно настроить после установки
Установка через docker-compose или Helm-чарт занимает около 45 минут. Сложность — в том, что идёт после.
Сканирование образов. Harbour интегрируется с Trivy и Clair как сканерами. Trivy — предпочтительный выбор: активно поддерживается Aqua Security, база уязвимостей обновляется ежедневно, есть поддержка SBOM. Trivy сканирует образ в среднем в 2 раза быстрее, чем Clair, при сопоставимой точности. Настройка в UI: Administration → Interrogation Services → выбрать адаптер Trivy, указать endpoint. После этого можно включить политику Prevent vulnerable images from running на уровне проекта с порогом severity (например, блокировать при CRITICAL).
Тонкость: если Trivy-адаптер и Harbour развёрнуты в одном docker-compose, сканирование работает по internal-сети. Но при Helm-деплое в Kubernetes Trivy-adapter нужен как отдельный pod, и между ним и Harbour должен быть корректный service discovery — по умолчанию это trivy-adapter.harbor.svc.cluster.local:8080.
Пошаговая настройка сканирования Trivy
- Установите Harbour через Helm с поддержкой Trivy (
helm install harbor harbor/harbor --set trivy.enabled=true). - В UI перейдите в Administration → Interrogation Services.
- Добавьте адаптер Trivy с endpoint
http://trivy-adapter:8080. - В проекте включите политику сканирования при push.
- Настройте порог severity: например, блокировать образы с CRITICAL уязвимостями.
- Протестируйте: запушьте образ с известной уязвимостью — пайплайн должен упасть.
RBAC. Harbour использует проекты как единицу изоляции. Внутри проекта роли: Guest (только pull), Developer (push), Maintainer (управление тегами), ProjectAdmin. Интеграция с LDAP/AD настраивается через Administration → Configuration → Authentication. Частая проблема: при LDAP-группах Harbour кэширует членство, и изменение группы в AD не применяется сразу — нужно либо ждать cache TTL (настраивается), либо делать POST /api/v2.0/ldap/ping для форс-обновления.
Репликация. Зеркалирование образов из DockerHub, GCR или другого Harbour-инстанса настраивается через Registries → New Endpoint → создать правило репликации с расписанием. При pull-based репликации Harbour сам забирает образы по cron-расписанию. Для DR-сценария между двумя дата-центрами настраивается двусторонняя репликация с фильтрацией по тегам.
Хранилище и garbage collection
По умолчанию Harbour хранит образы в локальной директории или S3-совместимом бэкенде. Конфигурация бэкенда — в harbor.yml:
storage_service:
s3:
accesskey: AKIAIOSFODNN7EXAMPLE
secretkey: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
region: us-east-1
bucket: harbor-registry
encrypt: false
secure: true
chunksize: 5368709120Garbage collection — критически важная задача. Без неё удалённые теги не освобождают место на диске, потому что блобы остаются. Настраивается в Administration → Garbage Collection → Schedule. GC запускает registry в read-only режиме на время работы — планируйте в off-peak.
Подробности garbage collection
GC удаляет слои, на которые нет ссылок. После удаления тегов запускается per‑project GC. Если у вас много проектов, настройте единое расписание для всех. Harbour генерирует отчёт — проверяйте, сколько места освободилось. При правильной настройке GC экономия на хранении достигает 50%.TLS и внешний доступ
Harbour требует HTTPS. В harbor.yml прописывается сертификат. Для интеграции с cert-manager в Kubernetes: создаётся Ingress с аннотацией cert-manager.io/cluster-issuer, а Harbour получает TLS через стандартный механизм. Важно: Docker-клиент и containerd/CRI-O должны доверять CA, подписавшему сертификат. Для containerd это /etc/containerd/certs.d/<registry-host>/ с файлом ca.crt.
Типичные ошибки при развёртывании
- Не выставить
external_urlвharbor.yml— в результате ссылки в UI ведут наlocalhost - Не настроить persistent volume для PostgreSQL и Redis при Helm-деплое — после рестарта пода теряется весь state
- Оставить дефолтный пароль
Harbor12345дляadmin— сканируется автоматически
Почему стоит выбрать self-hosted registry?
Сравнение Harbour и DockerHub:
| Функция | Harbour | DockerHub (бесплатный) |
|---|---|---|
| Pull rate limit | Нет | 100 pull/6h аноним, 200 аутентиф. |
| RBAC до уровня репозитория | Да | Только команды |
| Сканирование уязвимостей | Встроенное (Trivy/Clair) | Только платное |
| Репликация между инстансами | Да | Нет |
| Content trust (Notary) | Да | Нет |
Harbour в production даёт контроль, которого нет в DockerHub: собственный реестр снижает задержки на 30% при частых пушах, а политики сканирования блокируют уязвимые образы до деплоя. По данным официальной документации Harbor, применение GC сокращает затраты на хранение до 50%.
Что входит в работу
В рамках внедрения Harbour под ключ мы предоставляем:
- Аудит текущей инфраструктуры и схемы CI/CD
- Установку Harbour на bare-metal, ВМ или Kubernetes (Helm/kubeadm)
- Настройку TLS (Let's Encrypt / cert-manager)
- Интеграцию с LDAP/AD или OIDC
- Настройку сканирования Trivy с политиками severity
- Репликацию между инстансами (DR)
- Передачу документации (Runbook)
- Обучение команды (2 часа)
- Пост-релизную поддержку на 2 недели
Сроки
Базовый Harbour с TLS, LDAP, Trivy и одним S3-бэкендом — 2-3 дня с учётом тестирования интеграций с CI и настройки политик сканирования. Если нужна репликация между инстансами или интеграция с Kubernetes admission webhook для проверки подписей — добавьте день.
Свяжитесь с нами для оценки вашего проекта. Закажите внедрение Harbour — получите надёжный и безопасный реестр образов.
