Каждый, кто поднимает свой Kubernetes-кластер, рано или поздно упирается в вопрос: где хранить Docker-образы?

Вариантов вроде бы немного, но каждый со своими граблями:

• Docker Registry — голый, без UI, без бэкапов, без RBAC. Для прототипа сойдёт, для продакшена — нет.

• Harbor — мощная штука, но требует PostgreSQL, Redis, Trivy, Core, Jobservice, Notary… Это отдельный мини-кластер со своими миграциями, обновлениями и логами.

• Nexus / GitLab Registry — либо тяжеловесные, либо привязаны к экосистеме, которая вам не нужна.

А что если нужен реестр, который:

• занимает в кластере в разы меньше ресурсов, чем Harbor;

• умеет в кластерный режим с zero-downtime обновлениями;

• делает бэкапы в S3 без привязки к CSI-драйверу;

• показывает уязвимости образов прямо в UI;

• управляется одним YAML-манифестом?

Именно для этого существует связка rgstr v1.10.1 и rgstroperator v0.5.1. В этой статье — без воды и маркетинга — разберём, какие конкретные боли SRE и DevOps-инженера она закрывает.

1. Боль: Простои при обновлениях и невозможность масштабирования

Как было раньше

В классическом Docker Registry или в standalone-режиме большинства реестров у вас один процесс на один том. Любое обновление, перезагрузка узла или сбой пода — и CI/CD встает, пока реестр не поднимется обратно.

Для маленькой команды это терпимо. Для организации, где 50 разработчиков одновременно пушат образы, а пайплайны идут 24/7 — это проблема.

Что даёт rgstr v1.10.1

Начиная с версии 1.9, rgstr поддерживает кластерный режим: несколько реплик (3 и более) работают параллельно, используя:

• PostgreSQL — для метаданных (теги, манифесты, пользователи, политики);

• S3 или RWX-том — для blob'ов (сами слои образов).

Push и pull работают на любой реплике. Обновление версии rgstr происходит через rolling update — трафик перераспределяется между живыми подами, и разработчики этого даже не замечают.

Польза

• Zero-downtime обновления. Можно накатывать новые версии rgstr в рабочее время, не останавливая CI/CD.

• Отказоустойчивость. Падение одного пода не влияет на доступность реестра.

• Горизонтальное масштабирование. Если нагрузка растёт — просто поднимаете replicas: 5. Никаких перестроек архитектуры.

2. Боль: Бэкапы, привязанные к возможностям хранилища

Как было раньше

Хотите бэкапить том реестра? В большинстве случаев это значит:

• либо полагаться на CSI-драйвер вашего облачного провайдера и настраивать VolumeSnapshotClass;

• либо ставить Longhorn и настраивать RecurringJob;

• либо писать самописный скрипт, который останавливает реестр, делает tar, кладёт в S3 и запускает обратно.

Перенесите кластер в другое место — и вся схема бэкапов ломается. А в локальных kind/minikube VolumeSnapshot часто вообще недоступен.

Что даёт rgstroperator v0.5.1

Начиная с версии 0.3, в операторе появился параметр backup.method: S3. Это значит, что сам rgstr делает бэкапы напрямую в S3-совместимое хранилище (MinIO, AWS S3, Yandex Object Storage, Cloudflare R2 — что угодно).

apiVersion: registry.rgstr.io/v1alpha1
kind: Registry
metadata:
  name: prod-registry
spec:
  replicas: 3
  backup:
    enabled: true
    method: S3
    schedule: "0 3 * * *"
    keep: 14
    s3:
      endpoint: https://s3.eu-central-1.amazonaws.com
      bucket: registry-backups
      secretRef: s3-credentials

CSI-снапшоты и Longhorn никуда не делись — они остались как альтернативные варианты. Но теперь у вас есть универсальный путь, который работает везде, где есть сеть и S3.

Польза

• Независимость от инфраструктуры. Переезжаете из Yandex Cloud в AWS, из AWS в on-premise — бэкапы продолжают работать без изменений.

• Работает даже в kind/minikube. Не нужен CSI-драйвер с поддержкой снапшотов.

• Полный Disaster Recovery в кластерном режиме. Оператор бэкапит и сам S3-бакет с образами, и PostgreSQL с метаданными. При аварии вы восстанавливаете обе части и получаете рабочий реестр со всей историей.

3. Боль: Диск растёт, уязвимости не видны, теги перезаписываются

Как было раньше

В обычном Docker Registry:

• вы не видите, сколько места занимают старые образы, пока диск не закончится;

• разработчик может случайно перезаписать тег latest или v1.0.0;

• чтобы узнать, есть ли в образе CVE, нужно отдельно гонять Trivy в CI и куда-то складывать отчёты.

В Harbor всё это есть, но, как мы помним, за это приходится платить ресурсами.

Что даёт rgstr v1.10.1

Веб-интерфейс rgstr — это уже не просто «страница для смены пароля». Это полноценная админка, в которой из коробки:

Каталог образов с деталями

• Список репозиториев, тегов, платформ (для multi-arch образов видно все архитектуры с размерами).

• Конфигурация образа: entrypoint, CMD, env, порты, volumes.

• Пошаговая история сборки с размерами каждого слоя.

Интеграция с Trivy

• Уязвимости отображаются прямо в карточке образа. Разработчик видит CVE до того, как образ уйдёт в прод.

Политики хранения (retention policies)

• Правила вида: «для репозиториев team/** оставлять последние 5 тегов dev-* и все, что моложе 30 дней».

• Применяются автоматически перед каждым плановым GC. Диск больше не растёт бесконтрольно.

Неизменяемые теги (immutable tags)

• Шаблон вроде v*.*.*-release помечается как неизменяемый.

• Попытка перезаписать такой тег через docker push вернёт ошибку tag is immutable.

• Через UI и через политики хранения такой тег тоже удалить нельзя.

Журнал аудита (audit log)

• Кто, когда и с какого IP сделал push, pull, удалил тег, вошёл в админку, ошибся паролем.

• Хранится в JSON, ротируется при 10 МБ.

Польза

• Безопасность без дополнительных инструментов. Trivy уже встроен, отчёты не нужно собирать по пайплайнам.

• Автоматическая экономия диска. Политики хранения работают по расписанию, SRE не нужно вручную чистить старые теги.

• Защита от человеческого фактора. Релизные теги физически нельзя перезаписать — ни случайно, ни по ошибке в CI.

• Расследование инцидентов. Если что-то пошло не так, в audit log сразу видно, кто и когда это сделал.

4. Боль: Хаос в доступе и небезопасные токены в CI/CD

Как было раньше

В простом Docker Registry есть два варианта:

• реестр полностью открытый (и любой, кто знает URL, может pull/push);

• реестр с basic auth, где все пароли лежат в одном файле, а токены для CI/CD — это те же учётки, что и у людей.

Когда в команде 20 человек и десяток пайплайнов, это превращается в кошмар:

• нельзя дать джуну доступ только к своему проекту;

• токен CI живёт вечно и даёт доступ ко всему;

• при увольнении сотрудника нужно менять пароли везде.

Что даёт rgstr v1.10.1

Проекты и роли

• Репозитории группируются в проекты.

• В проекте есть четыре стандартные роли:

  • admin — полный доступ;

  • maintainer — управление репозиториями и участниками;

  • developer — push/pull;

  • guest — только pull.

• Права выдаются на проект целиком.

Robot-аккаунты

• Для CI/CD создаются специальные robot-аккаунты с правами только на нужные проекты.

• У них есть срок жизни (expires_days), их можно отзывать, не трогая людей.

• Секрет робота можно перегенерировать в любой момент.

Внешняя аутентификация

• Поддержка LDAP, Active Directory и OIDC.

• Группы из каталога маппятся на роли в проектах.

• Увольнение сотрудника в AD = автоматическая блокировка доступа в реестр.

Webhooks

• На события push, delete, login_failed и другие можно повесить webhooks.

• Интеграция с Slack, Telegram, SIEM — что угодно, что принимает HTTP.

Польза

• Безопасный онбординг. Новые сотрудники получают доступ через корпоративный каталог, SRE не создаёт учётки вручную.

• Изоляция CI/CD. Пайплайны работают под robot-аккаунтами с минимально необходимыми правами.

• Аудируемость. Все действия пишутся в audit log, и его можно отправлять в SIEM через webhook.

5. Честные ограничения: где это решение вам не подойдёт

Чтобы статья была полезной, важно сразу сказать, где rgstr не закрывает задачи. Это сэкономит вам время на оценку.

1. SAML не поддерживается.
Если у вас в компании SAML — единственный вариант аутентификации, придётся либо переходить на OIDC/LDAP, либо смотреть в сторону Harbor. Поддерживаются только LDAP, Active Directory и OIDC.

2. Права только на проект, не на репозиторий.
Нельзя выдать разработчику доступ только к team/backend, но запретить team/frontend внутри одного проекта. Права всегда на весь проект. Также нет возможности создавать свои кастомные роли — только четыре стандартные.

поддерживается в версии v1.11.0

3. Кластерный режим требует PostgreSQL и S3.
Если вы хотите replicas > 1 — придётся поднимать PostgreSQL и настраивать S3-бакет (или RWX-том). Это не сложно, но это дополнительные компоненты.

4. Standalone-режим даёт простой при перезапуске.
Если вы используете rgstr без базы данных (один процесс, один том), то любой перезапуск пода или обновление версии — это кратковременный простой. Для dev-окружений это нормально, для критичных прод-систем — нет.

6. Итог: когда эта связка — правильный выбор

Связка rgstr + rgstroperator — это не «Harbor для бедных» и не «Docker Registry с UI». Это отдельный класс решений для случаев, когда:

• вам нужен полноценный реестр с UI, RBAC, бэкапами и сканером уязвимостей;

• вы не хотите тратить ресурсы кластера на тяжеловесные комбайны;

• вы хотите декларативное управление через GitOps (один YAML-манифест — и реестр развёрнут);

• вам важна независимость бэкапов от конкретного CSI-драйвера;

• у вас есть (или вы готовы поднять) PostgreSQL и S3 для кластерного режима.

В ресурсах это выглядит примерно так:

При этом по функционалу кластерный rgstr не уступает Harbor в ключевых задачах: zero-downtime обновления, бэкапы, RBAC, Trivy, audit log, политики хранения.

Если ваши задачи вписываются в описанные ограничения — это отличный способ сэкономить и ресурсы кластера, и время SRE, которое раньше уходило на поддержку тяжеловесных решений.

Ссылки:

• Реестр: github.com/piqab/rgstr v1.11.0

• Оператор: github.com/piqab/rgstroperator v0.5.1

• Helm-чарт: oci://ghcr.io/piqab/charts/rgstroperator

• Требования: Kubernetes 1.27+