Self-hosted container registry нужен, когда важно хранить Docker-образы внутри компании, ускорить CI/CD и не зависеть от публичных сервисов. Чаще всего выбирают Nexus Repository или Harbor. Ниже — короткий практический гайд, что выбрать и как внедрить.
Что такое container registry
Это хранилище образов контейнеров: `docker push` отправляет образы в registry, `docker pull` — забирает их на серверы, в Kubernetes или в пайплайны сборки.
Зачем поднимать свой registry
- контроль доступа к образам
- работа во внутреннем контуре
- ускорение сборок и деплоя
- хранение приватных версий
- аудит, репликация и безопасность
- снижение зависимости от Docker Hub
Nexus vs Harbor: в чем разница
Nexus Repository
- универсальный артефактный менеджер
- поддерживает Docker, Maven, npm, PyPI и другие форматы
- подходит, если нужен единый репозиторий для всего DevOps-стека
- проще вписывается в инфраструктуру, где уже есть Java/CI-экосистема
Harbor
- специализированный registry для контейнеров и OCI-артефактов
- встроенные роли, проекты, web UI
- image scanning, replication, robot accounts, policy-контроль
- удобнее для Kubernetes и cloud-native сценариев
Когда выбирать Nexus
- ✅ если нужен не только Docker registry, но и единая точка хранения пакетов
- ✅ если в компании уже используют Sonatype
- ✅ если приоритет — универсальность
Когда выбирать Harbor
- ✅ если основной фокус — Docker/Kubernetes
- ✅ если нужны встроенные security-функции
- ✅ если важны удобная репликация и управление доступами
Минимальные требования к внедрению
- отдельный сервер или VM
- домен, например `registry.company.local`
- TLS/HTTPS — обязательно
- внешнее хранилище или volume под образы
- резервное копирование
- интеграция с LDAP/AD при необходимости
Базовые шаги запуска
- Развернуть Nexus или Harbor через Docker Compose / Helm
- Настроить HTTPS
- Создать проекты/репозитории
- Добавить пользователей или service accounts
- Подключить CI/CD: GitLab CI, Jenkins, GitHub Actions
- Настроить retention policy и очистку старых тегов
- Включить сканирование уязвимостей
Пример рабочего сценария
Разработчик собирает образ приложения → CI присваивает тег `app:1.2.3` → пушит в Harbor/Nexus → Kubernetes тянет образ из приватного registry. Такой подход делает поставку предсказуемой и безопасной.
На что обратить внимание
- ⚠️ не используйте registry без HTTPS
- ⚠️ ограничьте доступ по ролям
- ⚠️ не храните секреты в Dockerfile
- ⚠️ настройте garbage collection
- ⚠️ следите за размером storage и retention-политиками
Итог
Если нужен универсальный репозиторий артефактов — чаще выигрывает Nexus.
Если нужен удобный self-hosted registry для контейнеров с сильным упором на безопасность и Kubernetes — чаще выбирают Harbor. 🚀
Подборку полезных каналов про IT стоит посмотреть в закрепе — там много практики по DevOps, Kubernetes и инфраструктуре.