Реестр контейнеров - GitRiver Документация

Как хранить Docker-образы в GitRiver: push, pull, CI-интеграция, очистка, хранилище

GitRiver имеет встроенный Docker Registry, совместимый с OCI Distribution Spec v2. Отдельный сервис не нужен - образы хранятся прямо в платформе, привязанные к репозиторию.

Зачем

Хранить Docker-образы рядом с кодом, в том же репозитории
Автоматически собирать и публиковать образы из CI/CD
Контролировать доступ через те же права, что и к репозиторию
Не зависеть от внешних сервисов

Подключение

1. Получите токен

Для доступа к реестру нужен токен. Подойдёт:

Персональный токен (префикс gtr_pat_) - создайте в Настройки -> Токены с правами на реестр
Токен деплоя (префикс gtr_deploy_) - создайте в настройках репозитория, раздел Токены деплоя
CI-токен (CI_JOB_TOKEN) - доступен автоматически внутри CI-задач

2. Авторизуйтесь

docker login git.example.com -u ваш_логин -p gtr_pat_xxxxx

Вместо пароля укажите токен. Логин - ваше имя пользователя в GitRiver.

3. Соберите и отправьте образ

docker build -t git.example.com/owner/repo:v1.0 .
docker push git.example.com/owner/repo:v1.0

4. Скачайте образ

docker pull git.example.com/owner/repo:v1.0

Формат тега

git.example.com/{владелец}/{репозиторий}[/{образ}]:{тег}

Поддерживается произвольная вложенность: git.example.com/owner/repo/frontend/nginx:latest.

Использование в CI/CD

В CI-задачах доступны готовые переменные для работы с реестром:

jobs:
  build:
    image: docker:latest
    steps:
      - run: |
          docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
          docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
          docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Переменная	Значение
`CI_REGISTRY`	Адрес реестра (например, `git.example.com`)
`CI_REGISTRY_IMAGE`	`registry/owner/repo`
`CI_REGISTRY_USER`	Логин для авторизации
`CI_REGISTRY_PASSWORD`	Токен (= `CI_JOB_TOKEN`)

Просмотр образов

Откройте репозиторий в GitRiver
Перейдите во вкладку, где отображаются образы (в меню репозитория)
Вы увидите список образов с тегами, размерами и датами

Для каждого образа доступна информация: слои, конфигурация, платформы (для multi-arch).

Правила неизменяемости тегов

Проблема: кто-то перезаписал тег latest или v1.0 новым образом, и деплой сломался.

Решение: правила неизменяемости. Теги, соответствующие паттерну, нельзя перезаписать.

Настройка: Настройки репозитория -> Реестр -> Правила тегов.

Укажите glob-паттерн: v*, release-*, latest
Отметьте «Неизменяемый»
После этого docker push с существующим тегом вернёт ошибку

Политики хранения

Со временем образов становится много, и они занимают место. Политики хранения автоматически удаляют старые теги.

Настройка: Настройки репозитория -> Реестр -> Политики хранения.

Сохранять последние N - оставить только N самых свежих тегов
Удалять старше N дней - удалить теги старше указанного возраста
Паттерн образов - к каким образам применять правило

Сборка мусора (Garbage Collection)

После удаления тегов блобы (слои образов) остаются на диске. Чтобы освободить место, запустите сборку мусора.

Как: Администрирование -> Хранилище -> кнопка «Очистка».

Можно настроить автоматический запуск по расписанию на той же странице.

Хранилище

По умолчанию образы хранятся в файловой системе (в директории git_repos_path). Для production рекомендуется S3-совместимое хранилище - см. раздел Конфигурация -> S3.

Переключение между файловой системой и S3: Администрирование -> Хранилище. Кнопка «Тест» проверяет подключение без сохранения.

Сканирование уязвимостей

GitRiver может показывать результаты сканирования образов на уязвимости. Для этого нужен внешний сканер (например, Trivy), который загружает результаты в формате SARIF.

Включение: registry_scan_enabled = true в конфиге + путь к Trivy (trivy_path).

Результаты отображаются в детальной информации об образе.

Это Pro-функция: просмотр результатов сканирования доступен пользователям с Pro-местом.