Конфигурация

Сервер настраивается файлом config.yaml (путь передаётся флагом --config). Настройки применяются при старте — изменения требуют перезапуска сервера. Сущности (репозитории, пользователи, роли) в файле не описываются — ими управляют через веб-интерфейс.

Перечень всех параметров со значениями по умолчанию — в разделе Параметры конфигурации.

Форматы значений

Длительности и размеры записываются одинаково и в файле, и в переменных окружения:

• длительность — строка с единицей измерения: s — секунды, m — минуты, h — часы; допустимы составные значения (1h30m). Число без единицы измерения сервер отклоняет при старте;
• размер — строка с единицей измерения: K, M, G, T (или KB, MB, GB, TB); множители двоичные, поэтому 256K — это 262 144 байта. Число без единицы измерения означает байты, 0 снимает ограничение.

Переменные окружения

Любой ключ файла переопределяется переменной GALLEON_*: точки заменяются подчёркиваниями, database.host → GALLEON_DATABASE_HOST, gc.grace_period → GALLEON_GC_GRACE_PERIOD.

Правила:

• переменная окружения имеет приоритет над значением из файла;
• списки задаются через запятую: GALLEON_SERVER_MONITORING_ALLOWLIST="127.0.0.0/8,::1/128";
• не оставляйте в файле пустые родительские блоки (например, голый security: без ключей) — они могут помешать применению вложенных переменных окружения.

Обязательные параметры

Значений по умолчанию нет у следующих ключей (без них сервер не стартует):

• database.user и database.dbname — учётные данные базы данных;
• storage.default.type и путь хранилища для выбранного типа;
• security.secret_key_file — путь к файлу ключей шифрования;
• auth.bootstrap_admin — только при первом запуске с пустой базой данных.

Что где настраивается

Параметры сгруппированы по блокам:

Типовые задачи

Ограничить размер загружаемых артефактов

Собственного лимита у Galleon по умолчанию нет (server.max_upload_size: 0). Если перед сервером стоит обратный прокси, согласуйте с ним размер тела запроса (Обратный прокси).

Задать лимит на стороне Galleon:

server:
  max_upload_size: 10GB

Превышение лимита клиент видит как ошибку 413.

Включить TLS-подключение к базе данных

Режим проверки сертификата задаёт ключ database.sslmode:

database:
  sslmode: verify-full

Значения соответствуют режимам PostgreSQL: require шифрует соединение, verify-ca и verify-full дополнительно проверяют сертификат.

Собрать подробные логи для диагностики

Подробностью логирования управляют два ключа блока logging:

logging:
  level: debug
  registry_level: info

Первый ключ повышает подробность логов Galleon, второй — записей о работе с образами контейнеров; он нужен при разборе проблем с ними. Возвращайте прежние значения после диагностики: на уровне debug объём записей значительно выше.

Разрешить проксирование во внутреннюю сеть

Обращения proxy-репозиториев к приватным IP-адресам запрещены по умолчанию: loopback, диапазоны RFC 1918 (10/8, 172.16/12, 192.168/16), link-local, CGNAT (100.64/10), multicast, broadcast и ULA IPv6. Запрет проверяется при сохранении репозитория (по адресам, в которые разрешается имя внешнего реестра), при каждом соединении и на редиректах: адрес из заголовка Location проходит ту же проверку.

Чтобы разрешить конкретный внутренний адрес:

proxy:
  ssrf:
    allowlist:
      ips:
        - 10.0.0.10
      domains:
        - registry.internal.example.com

Список исключений принимает и IP-адреса, и имена хостов; имя сверяется целиком, поддомены под исключение не попадают. На приватные адреса вне списка запрет продолжает действовать. Адреса сервисов метаданных облачных провайдеров (например, 169.254.169.254) заблокированы всегда — внести их в список исключений нельзя.

Расширить пулы соединений под нагрузку

Расширьте пулы, если соединений к базе данных перестало хватать под нагрузкой. Соединения занимают параллельные сборки, фоновое построение индексов и особенно проксирование образов контейнеров: пока слой скачивается из внешнего реестра, он держит соединение (до двух на один docker pull).

Признаки нехватки:

• запросы отвечают медленно, а сама база данных при этом не загружена: активных запросов в pg_stat_activity мало, но число соединений Galleon упирается в max_open_conns — значит, запросы стоят в очереди за свободным соединением;
• слотов не хватает уже в самой базе данных: PostgreSQL перестаёт принимать новые соединения, запросы завершаются ошибкой, а в access-логе появляется поле sqlstate с кодом класса 53 — исчерпание ресурсов (Логирование).

Занятость пулов видна в PostgreSQL:

SELECT application_name, count(*) FROM pg_stat_activity GROUP BY 1 ORDER BY 2 DESC;

Метка galleon — основной пул, galleon-oci-meta — пул чтения метаданных образов; соединения, обслуживающие образы контейнеров, идут без метки.

database:
  max_open_conns: 80
  registry_max_open_conns: 40

По умолчанию — 40 и 25. После изменения пересчитайте max_connections базы данных. Galleon подключается к ней тремя пулами: два ограничены max_open_conns (поэтому в формуле оно удваивается), третий — registry_max_open_conns. Ещё несколько соединений PostgreSQL держит в резерве для суперпользователя (superuser_reserved_connections, по умолчанию 3):

max_connections >= max_open_conns × 2 + registry_max_open_conns + superuser_reserved_connections

При значениях по умолчанию это 40 + 40 + 25 + 3 = 108, поэтому для промышленной инсталляции — не меньше 110. Оставьте несколько свободных слотов для psql и разовых операций.