Сколько RAM нужно для Harbor

MAATRIX

Ставите Harbor как приватный реестр для своих Docker-образов и упираетесь в вопрос: сколько памяти брать на сервер. Официальный минимум в документации выглядит скромно, но на практике связка из десятка контейнеров плюс сканер уязвимостей Trivy ведёт себя иначе, чем в теории. Разберём, куда уходит память по компонентам и сколько закладывать под разные сценарии — от домашней лаборатории до боевого CI/CD.

Из чего состоит Harbor и куда уходит память

Harbor — это не один процесс, а связка сервисов, поднимаемых через docker-compose (или Helm-чарт в Kubernetes). Каждый компонент решает свою задачу и ест память отдельно:

Это ориентировочные цифры по опыту эксплуатации, а не гарантированные бенчмарки — у вас они сдвинутся в зависимости от версии Harbor, числа проектов и того, сколько образов реально хранится. Но сумма по столбцу уже даёт понимание: даже полностью бездействующий Harbor с включённым Trivy держит на борту порядка 900 МБ – 1,5 ГБ занятой памяти ещё до первого пуша образа. Добавьте сюда память самой ОС, докер-демона и системные процессы — и минимальные 4 ГБ, которые часто фигурируют в статьях, оказываются впритык.

Если раньше вы поднимали более простой приватный Docker-реестр через голый registry:2, разница в аппетитах будет заметна сразу — там один контейнер занимает десятки мегабайт, а не почти гигабайт на старте.

Минимальные требования и на что они реально годятся

Официальная документация Harbor называет минимум 2 vCPU и 4 ГБ RAM для установки. Это честная цифра — Harbor действительно запустится и пройдёт docker compose up. Вопрос в другом: что вы сможете на этом делать.

На 4 ГБ RAM вы получите:

• рабочий реестр для личных проектов или маленькой команды из 2–3 человек;
• редкие push/pull без параллельной нагрузки;
• сканирование образов по одному, с ожиданием — параллельный скан двух-трёх образов уже создаёт риск OOM;
• отсутствие запаса на скачки — любой всплеск (массовая пересборка CI, garbage collection, обновление базы уязвимостей Trivy) может уронить один из контейнеров.

На практике 4 ГБ — это конфигурация для теста «works on my machine», а не для сервера, который команда использует каждый день. Если Harbor стоит на той же машине, где крутится что-то ещё (Portainer, Gitea, мониторинг), 4 ГБ становится тесно почти сразу.

Сколько RAM нужно в реальности: три сценария

Вот более честная раскладка по сценариям использования — с учётом реальной эксплуатации, а не только факта запуска:

Ключевой параметр, который тянет требования вверх — не число пользователей, а частота и параллельность операций: сколько CI-джобов одновременно пушат образы и сколько сканов Trivy выполняется параллельно. Хранилище образов само по себе (диск) растёт независимо от памяти, но retention-политики и регулярная очистка старых тегов держат его в узде — без неё диск закончится быстрее, чем не хватит RAM.

Для команды с активным CI/CD стоит сразу закладывать 8 ГБ как разумный минимум, а не 4 ГБ из документации — экономия на этом шаге обычно оборачивается перезапусками контейнеров в самый неподходящий момент, посреди рабочего дня.

Trivy-сканер: главный пожиратель памяти

Если в Harbor есть один компонент, из-за которого сервер внезапно уходит в своп — это Trivy. Логика простая: чтобы найти уязвимости в образе, сканер должен распаковать все слои, сверить пакеты с базой CVE и держать промежуточные данные в памяти. Чем толще образ (особенно на базе ubuntu или debian с кучей системных пакетов, а не alpine/distroless), тем больше пик потребления.

Что важно знать:

• База уязвимостей Trivy сама по себе занимает несколько сотен мегабайт и периодически обновляется (trivy-adapter тянет её из интернета либо из офлайн-бандла) — на момент обновления идёт дополнительная нагрузка на CPU и диск.
• Один скан крупного образа (несколько ГБ, много слоёв) может кратковременно поднять потребление памяти jobservice+trivy на 500 МБ – 1 ГБ сверх базового уровня. Точные цифры зависят от образа и версии Trivy, поэтому ориентируйтесь на запас, а не на конкретное число.
• Если в Harbor настроено автоматическое сканирование при каждом push, а CI пушит параллельно из нескольких пайплайнов, скачки могут накладываться друг на друга — тут и проявляется нехватка памяти на конфигурациях 4 ГБ.
• В harbor.yml есть параметр trivy.skip_update, который отключает автообновление базы на каждый запуск — полезно, если сервер стоит за ограниченным каналом или вы хотите контролировать момент обновления вручную по расписанию.

Практический вывод: если сканирование на уязвимости для вас не факультативная опция, а обязательная часть pipeline (что и есть основная причина ставить именно Harbor, а не голый registry), закладывайте память с запасом минимум в 1,5–2 ГБ сверх «спокойного» состояния системы — именно на скачки при сканировании.

Как настроить лимиты в docker-compose и не словить OOM

Harbor по умолчанию разворачивается docker-compose файлом без явных ограничений памяти на контейнеры — то есть теоретически любой сервис может выесть всё, что есть на хосте. Это одна из частых причин, почему сервер «внезапно» падает под нагрузкой: не хватило памяти не у Harbor в целом, а у одного конкретного контейнера, который утянул за собой соседей через OOM killer ядра.

Добавьте секцию deploy.resources (или mem_limit в старом синтаксисе compose) в docker-compose.yml, который генерирует install.sh из harbor.yml:

services:
  registry:
    mem_limit: 512m
    memswap_limit: 512m
  core:
    mem_limit: 512m
  jobservice:
    mem_limit: 768m
  trivy-adapter:
    mem_limit: 1536m
  redis:
    mem_limit: 256m
  postgresql:
    mem_limit: 768m

Логика такая: даёте каждому компоненту потолок с запасом над типичным потреблением из таблицы выше, но так, чтобы сумма лимитов не превышала физическую память сервера минус 1–1,5 ГБ на ОС и докер-демон. Если контейнер упирается в свой лимит — он перезапустится сам по себе (что видно в логах), а не утащит за собой соседние сервисы через нехватку памяти на хосте целиком.

Отдельно стоит выставить лимит на PostgreSQL через параметры shared_buffers и work_mem в конфиге БД, если база растёт — под сотни проектов и активную репликацию дефолтные настройки Harbor не всегда оптимальны. Общие принципы работы с лимитами CPU и памяти в Docker применимы и здесь: лучше явный потолок с перезапуском контейнера, чем тихое исчерпание памяти хоста.

Мониторинг потребления памяти и типичные проблемы

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

Быстрая проверка без дополнительных инструментов:

docker stats --no-stream $(docker ps --filter "name=harbor" -q)

Команда покажет текущее потребление CPU и памяти по каждому контейнеру Harbor разом — удобно, чтобы за 10 секунд понять, какой сервис ближе всего к своему лимиту.

Для постоянного контроля лучше вынести метрики в отдельный стек — если сервер уже используется под CI/CD, вероятно, там уже стоит связка мониторинга. Частые проблемы, которые всплывают именно из-за нехватки памяти:

• jobservice регулярно рестартует — обычно совпадает по времени с массовыми сканами или garbage collection; решается либо увеличением памяти, либо разнесением задач по расписанию.
• PostgreSQL «подвисает» при большом числе проектов — типично для инсталляций, где база не получала VACUUM и shared_buffers остался на дефолте под маленький инстанс.
• Push крупных образов обрывается — часто не сеть, а именно нехватка памяти у registry-контейнера при распаковке/загрузке слоёв.
• Redis не успевает обрабатывать очередь — заметно при большом числе одновременных задач от нескольких CI-раннеров; решается вертикальным апгрейдом либо ограничением параллелизма в jobservice.

Если Harbor стоит рядом с раннерами GitLab CI/CD на одном сервере, учитывайте, что сами раннеры при сборке образов тоже прожорливы — на практике конфликт за память чаще возникает не внутри Harbor, а между Harbor и соседними процессами, которые собирают и сразу пушат образы на этот же хост.

Частые вопросы