SavePearlHarbor

RGSTR: Экономим ресурсы кластера и время SRE: зачем нам нужен декларативный OCI-реестр с нативными бэкапами в S3

—

от автора

admin

Каждый, кто поднимает свой 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/v1alpha1kind: Registrymetadata:  name: prod-registryspec:  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 для кластерного режима.

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

Решение

Компоненты

Примерное потребление

Docker Registry

1 под

~50 МБ RAM

Harbor

8+ подов, PostgreSQL, Redis

2–4 ГБ RAM

rgstr standalone

1 под

~100 МБ RAM

rgstr cluster

3+ пода rgstr, PostgreSQL, S3

~500 МБ RAM + внешний PG

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

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

Ссылки:

ссылка на оригинал статьи https://habr.com/ru/articles/1100150/