MinIO как хранилище реестра контейнеров GitLab

Как обычно, немного контекста. GitLab с момента предыдущих публикаций обновился до 18.3, но каких-то существенных для нас изменений не произошло. VPS 4/4/30, Docker, Traefik. Следовательно, разворачиваем MinIO в контейнере. В документации предлагается docker run, но в моем случае целесообразно добавить сервис к GitLab через compose.yaml. Базово определение сервиса будет иметь следующий вид:

services:
  # ...
  minio:
    image: quay.io/minio/minio
    container_name: minio
    restart: always
    expose:
      - '9001'
    environment:
      MINIO_ROOT_USER: USERNAME
      MINIO_ROOT_PASSWORD: PASSWORD
    command: 'server /data --console-address ":9001"'
    labels:
      - traefik.enable=true
      - traefik.http.routers.minio.rule=Host(`minio.example.com`)
      - traefik.http.routers.minio.service=minio
      - traefik.http.services.minio.loadbalancer.server.port=9001
    volumes:
      - ./minio:/data
      - ./data/gitlab-rails/shared/registry:/registry
  # ...

Соответственно root-пользователя MinIO и его пароль определили через переменные окружения, запустили сервер с поддержкой панели управления, настроили эту самую панель в Traefik и пробросили две директории. В первой из них будут храниться сами данные MinIO, а вторая – это файловое хранилище реестра контейнеров, она понадобится для импорта.

В реальности определение сервиса скорее всего было бы сложнее, в частности с точки зрения подключения к сетям (сервисной Traefik'а и внутренней GitLab), включения сжатия трафика и т.д. Также было бы желательно поставить запуск GitLab в зависимость от старта MinIO.

Запускаем сервис (например docker compose start minio), заходим в админку, принимаем лицензию (почему-то каждый раз) и создаем «ведро» (для определенности registry). Что-то вроде и нечего там больше делать – основной упор делается на утилиту командной строки mc (не путать с Midnight Commander).

Теперь по идее надо импортировать реестр. Заходим в контейнер:

docker exec -it minio bash

В контейнере:

mc alias list

Тем самым смотрим, какие есть алиасы подключений, среди которых должен быть local. Но вообще-то мы в нем не авторизованы, поэтому:

mc alias set local http://localhost:9000 USERNAME PASSWORD

Загружаем реестр (в инструкции предлагается предварительно перевести его в режим только для чтения, но у нас и так его никто не трогает) в хранилище с помощью команды mc cp:

cd /registry
mc cp --recursive docker local/registry
exit

«Гасим» GitLab и перенастраиваем реестр на использование хранилища S3 (gitlab.rb):

registry['storage'] = {
  's3_v2' => {
    'accesskey' => 'USERNAME',
    'secretkey' => 'PASSWORD',
    'bucket' => 'registry',
    'region' => 'us-east-1',
    'regionendpoint' => 'http://minio:9000',
    'checksum_disabled' => true
  },
  'redirect' => {
    'disable' => true
  }
}

us-east-1 – это регион по умолчанию в MinIO. Отключение контрольных сумм (checksum_disabled) для такой схемы отдельно упомянуто в документации. regionendpoint в нашей конфигурации возможен только как хост сети Docker, а это, в свою очередь, требует отключения редиректа в драйвере хранилища.

По умолчанию для загрузки данных из хранилища GitLab формирует специальные временные URL, чтобы клиент (в частности Docker) обращался непосредственно к хранилищу (т.е. происходит редирект). В общем случае это хорошо с точки зрения пропускной способности, но в плане безопасности вызывает некоторые сомнения. Также возможны кое-какие проблемы, описанные в документации, особенно если вдруг взаимодействие с S3 осуществляется по http, а не https.

Если же этот редирект отключить, то GitLab будет выступать в качестве прокси. Соответственно каналы забиваются, поскольку серверу приходится пропускать трафик через себя, но зато теоретически меньше проблем и опасностей. В нашем же случае это единственный возможный вариант, так как доступ извне к API хранилища просто-напросто отсутствует.

Запускаем?

docker compose up -d

В принципе все должно заработать, но честно говоря каких-то преимуществ такого варианта я не увидел. Места занято практически столько же, но при этом возникает вопрос, а как резервировать сам MinIO.

В старом issue предложена такая команда:

mc mirror --remove --preserve $MINIO_ENV/<bucket> $BACKUPS_DIR/$BACKUP_NAME

И похоже она действительно выгружает все обратно в файлы. Для восстановления – поменять местами источник и пункт назначения. Или, теоретически, раз у нас контейнер с обычным пробросом директории, его можно остановить и заархивировать эту самую директорию.

Думаю схема раскроется в случае, если MinIO будет работать на отдельном сервере, особенно с учетом того, сколько места требует реестр. Тогда вместо того, чтобы раскатывать второй GitLab, в котором будет включен лишь один реестр, можно будет развернуть явно менее требовательное к процессору и памяти S3.

На самом деле, некоторые хостеры предлагают именно услугу S3-совместимого хранилища, которое на первый взгляд стоит дешевле VDS/VPS общего назначения. Тут, впрочем, зачастую присутствует нюанс в виде тарификации исходящего трафика, что может свести на нет всю потенциальную экономию при особо «удачном» стечении обстоятельств. У себя я вернул обычное файловое хранилище, но возможно в будущем все же попробую заказать такую услугу.

Примечание от 02.10.2025: заказал.