Сервер для Harbor
Приватный реестр образов Docker и OCI внутри контура: хранение слоёв, проекты и роли, контроль уязвимостей, репликация между площадками и жизненный цикл образов без зависимости от публичных сервисов.
Почему реестру нужен отдельный сервер
- Рост слоёв образов — одни и те же базовые слои переиспользуются, но версии и сборки быстро занимают дисковый объём.
- CI/CD обращается к реестру постоянно — каждый push и pull создаёт нагрузку на сеть и диск.
- Безопасность поставки — внутри нужны подпись образов (Cosign/Notary), сканирование CVE и политики доступа по проектам.
- Доступность сборок — если реестр недоступен, останавливаются и деплой, и масштабирование контейнеров.
Что определяет конфигурацию Harbor
| Параметр | Влияние на сервер | Что закладывать |
|---|---|---|
| Число образов и слоёв | Занимаемый объём хранилища | Ёмкие диски с планом роста и сборкой мусора |
| Интенсивность CI/CD | Сеть и скорость записи при push/pull | 10/25GbE, быстрый пул под активные слои |
| Сканирование уязвимостей | Периодическая CPU-нагрузка (Trivy) | Достаточно ядер, скан по расписанию вне пика |
| Репликация | Трафик между реестрами площадок | Вторая площадка, каналы и расписание синхронизации |
| Число проектов и пользователей | Минимальная нагрузка на БД метаданных | PostgreSQL и Redis из комплекта, небольшие ресурсы |
Команда разработки
Один реестр, десятки проектов- PowerEdge R360 / R450, 1×CPU 8–16 ядер
- 64 ГБ RAM
- 4× SSD 1.92–3.84 ТБ в RAID 5/6
- 2× 1GbE/10GbE, один сайт
Активный CI/CD
Множество сборок и pull- PowerEdge R660 / R760, 2×CPU 16–24 ядра
- 128 ГБ RAM
- 8–12× SSD/NVMe 3.84 ТБ, отдельный пул под кэш
- 2× 10/25GbE, сканирование по расписанию
Реестр с репликой
Две площадки, высокая доступность- 2× PowerEdge R660/R760 (или основной + резервный сайт)
- 128–256 ГБ RAM на узел
- Внешнее хранилище или ёмкие пулы с каждой стороны
- 25GbE, репликация проектов, общий балансировщик
Оцениваем объём образов
Считаем число проектов, средний размер образа, частоту версий и плановый рост; включаем очистку тегов и garbage collection.
Подбираем диски и сеть
Основное — ёмкость и пропускание сети: 10/25GbE заметно сокращает время push/pull в пайплайне.
Разворачиваем Harbor и политики
Настраиваем проекты, RBAC, проекты с приватностью, сканер Trivy, подпись и правила репликации.
Подключаем CI/CD и проверяем восстановление
Прописываем реестр в GitLab/Jenkins, проверяем pull при сбое узла и сценарий восстановления из резервной копии.
Для интеграторов, сборщиков ПАК и проектных поставок
Поставляем серверы под приватные реестры контейнеров для закрытых контуров, тендерных проектов и поставок ПАК. Закрывающие документы, договорная гарантия Beijing Xinchuan, отгрузка и доставка в РФ и страны СНГ. По оборудованию — запрос на admin@sell-server.com.
Harbor — это только реестр Docker?
Нет, он поддерживает артефакты OCI: образы, Helm-чарты, подписи и другие артефакты; вокруг них есть проекты, роли, сканирование и репликация.
Почему не использовать Docker Hub?
Для закрытого контура, скорости сборок, контроля уязвимостей и лимитов публичного сервиса собственный реестр надёжнее; он не зависит от интернета и чужой политики.
Нужен ли высокодоступный кластер?
Для критичного CI/CD — да: stateless-компоненты за балансировщиком, внешние PostgreSQL/Redis и общее или реплицируемое хранилище. Для небольшой команды достаточно одного сервера с бэкапом.
Что реально занимает место?
Слои образов и их версии. Политики retention и garbage collection удаляют неиспользуемые слои, поэтому их настраивают сразу вместе с планом дисков.
Подберём сервер под ваш реестр образов
Пришлите число проектов, объём слоёв и интенсивность CI/CD — вернём конфигурацию и цену в рабочем дне.
Запросить конфигурацию← Все сценарии подбора сервера