Запуск, остановка и масштабирование

Core и Radar состоят из нескольких процессов, которые общаются через очереди RabbitMQ. На странице - какие процессы есть, как их запускать и останавливать, что масштабируется и как, какие таймауты и чистки работают сами.

Команды kubectl ниже рассчитаны на развёртывание из раздела Установка в Kubernetes. Имена Deployment задаются при установке - в командах они даны в угловых скобках.

Процессы и очереди

Core

Компонент	Процесс	Очередь или порт	Реплики	Что масштабировать
Интерфейс и API	gunicorn AppSec.wsgi, MODE=web	порт 8000	2 и больше	реплики, GUNICORN_WORKERS × GUNICORN_THREADS
Приём отчётов	gunicorn importer.wsgi, MODE=importer	порт 8001	2 и больше	реплики, IMPORTER_GUNICORN_WORKERS × IMPORTER_GUNICORN_THREADS; память под размер отчёта
Worker	Celery, MODE=worker	appsecpanel_worker	2 и больше	реплики
Планировщик	Celery beat, MODE=beat	ставит задачи в очереди	ровно 1	не масштабируется
Разбор отчётов	Celery importer_service, образ sf-core-importer	importer_service	2-4	реплики × --concurrency = слотов разбора
Помощник БД	образ sf-core-db-helper	db_helper_*	ровно 1	AUTOMATION_WORKER_CONCURRENCY
Jira-помощник	Celery jira_helper_service, образ sf-core-jira-helper	jira_helper_service	1-2	реплики, --concurrency
Фронт	nginx	порт 80	2-3	реплики

Очередь appsecpanel_worker обслуживает запуск пайплайнов в Radar, задачи интеграций с системами контроля версий и реестрами, уведомления, расписания и сверку лицензии.

Загруженный отчёт процесс приёма читает в память целиком и кладёт в RabbitMQ аргументом задачи разбора. Отчёты, которые ждут разбора, переживают перезапуск процессов Core: они лежат в очереди брокера. Пайплайны, которые ждут в очереди Radar, перезапуск Radar back не переживают - см. Перезапуск компонентов.

Radar

Компонент	Процесс	Очередь или порт	Реплики	Что масштабировать
Radar back	uvicorn	порт 8090	2	API_WORKERS
Пайплайн-воркер	Celery pipeline_worker, --disable-prefetch	pipeline_queue	2 пода на узел scan	MAX_SCALEWORKERS_COUNT, число подов и узлов
Utils-воркер	Celery utils_worker	utils_queue	в каждом поде воркера	--concurrency
Планировщик Radar	Celery beat	ставит ежедневную очистку в utils_queue	ровно 1	не масштабируется
Фронт Radar	nginx	порт 8080	2	реплики

Один процесс пайплайн-воркера выполняет один пайплайн. Джобы внутри пайплайна идут строго по очереди. Число одновременных пайплайнов на под равно MAX_SCALEWORKERS_COUNT: воркер не берёт задачу, пока не освободился слот.

Запуск

Запускайте снизу вверх:

1. PostgreSQL, RabbitMQ Core, RabbitMQ Radar, Redis.
2. Core: Job подготовки базы - только при установке и обновлении, затем интерфейс и API, приём отчётов, worker, планировщик, разбор отчётов, помощник БД, Jira-помощник, фронт.
3. Radar: Radar back, затем воркеры сканирования, планировщик Radar, фронт.

kubectl -n securityflow-core scale deployment <компонент> --replicas=<N>
kubectl -n securityflow-core wait --for=condition=available deployment --all --timeout=600s
kubectl -n securityflow-radar scale deployment <компонент> --replicas=<N>
kubectl -n securityflow-radar wait --for=condition=available deployment --all --timeout=600s

После запуска проверьте платформу по таблице из раздела Мониторинг и журналы.

Остановка

1. Остановите новые сканы: в Core выключите "Активно" у расписаний в "Radar" → "Расписание", предупредите команды, которые запускают сканы из CI.
2. Дождитесь окончания пайплайнов в Radar: "Пайплайны", статус "Выполняется". Или остановите их кнопкой "Остановить все пайплайны".
3. Остановите Radar: фронт, воркеры сканирования, планировщик, Radar back.
4. Остановите Core: фронт, интерфейс и API, приём отчётов, worker, планировщик, разбор отчётов, помощник БД, Jira-помощник.
5. Брокеры, Redis и PostgreSQL останавливайте, только если это нужно для работ на них.

kubectl -n securityflow-radar scale deployment <компонент> --replicas=0
kubectl -n securityflow-core scale deployment <компонент> --replicas=0

Перезапуск компонентов

Компонент	Что происходит при перезапуске
Интерфейс и API, приём отчётов, фронты	при двух репликах и более - без простоя, если реплики перезапускаются по очереди
Планировщик Core	стратегия Recreate: на время перезапуска периодические задачи не ставятся
Помощник БД	одна реплика: на время перезапуска автоматика разбора и запись находок ждут
Radar back	при каждом старте останавливает все пайплайны "В ожидании" и "Выполняется", очищает очередь пайплайнов и применяет миграции базы Radar
Под воркера сканирования	пайплайны в его слотах прерываются вместе с томами Docker пода. В Radar они остаются "Выполняется", пока их не закроет глобальный таймаут или перезапуск Radar back
Планировщик Radar	пока он не работает, ежедневная очистка не запускается

kubectl -n securityflow-core rollout restart deployment/<компонент>
kubectl -n securityflow-core rollout status deployment/<компонент>

Масштабирование

Core

• Интерфейс и API. Поднимайте реплики при росте числа пользователей и запросов API. В образе по умолчанию gunicorn работает с 1 процессом и 1 потоком - один запрос за раз. В Kubernetes задаётся 4 × 4.
• Приём отчётов. Каждый запрос держит отчёт в памяти, поэтому у этого процесса больше памяти и меньше процессов: 2 × 4, limit 4 GiB. Лимит размера отчёта задаёт ingress - client-max-body-size 100m.
• Разбор отчётов. Слотов разбора = реплики × --concurrency. Добавляйте реплики, если очередь importer_service растёт в пик. Расчёт - Расчёт ресурсов.
• Помощник БД. Работает строго в одной реплике. Держите AUTOMATION_WORKER_CONCURRENCY не меньше 6.
• Планировщик. Строго одна реплика.

Radar

• Слоты сканирования. Одновременных пайплайнов = поды воркера × MAX_SCALEWORKERS_COUNT. В типовом развёртывании 3 слота на под и 2 пода на узел scan, limit пода 20 GiB: 6 GiB на слот и 2 GiB на Docker.
• Новые слоты добавляйте подами воркера, а подам - узлами scan. Поды воркера должны попадать только на узлы scan: задайте им toleration к taint dedicated=scanners:NoSchedule и привязку к узлам scan.
• Utils-воркер. Запускается с --concurrency=2 в команде контейнера: без флага Celery поднимает столько процессов, сколько CPU на узле.
• Radar back и планировщик Radar. Radar back - 2 реплики, планировщик Radar - строго одна: иначе очистка запустится несколько раз.

Сколько воркеров подключено и сколько слотов занято - Radar: "Настройки" → "Воркеры" ("Пайплайн" и "Утилиты": "Воркеры:", "Потоки:", "Всего:", "Используется:"). Пусто - "Нет Доступных Воркеров": пайплайны не запускаются.

kubectl -n securityflow-radar scale deployment <воркер сканирования> --replicas=<N>
kubectl -n securityflow-core set env deployment/<Core web> GUNICORN_WORKERS=4 GUNICORN_THREADS=4

Таймауты

Таймаут	Где задаётся	По умолчанию	Что происходит
Таймаут джобы	Radar: джоба → "Таймаут джобы (в минутах)"	10 минут у сканеров каталога, 1 минута у Code Downloader; 0 - без таймаута	контейнер джобы останавливается, джоба "Джоба прервана по тайм-ауту"
Таймаут пайплайна	Radar: "Настройки" → "Таймаут Пайплайнов" → "Глобальный таймаут пайплайнов (в минутах)"	0 - без таймаута	пайплайн "Выполняется" дольше таймаута останавливается со статусом "Тайм-аут"

Таймауты проверяет Radar back раз в 10 секунд. Проверка работает, только если у Radar back задан ACCESS_TOKEN.

Рекомендации:

• Задайте глобальный таймаут больше самого долгого пайплайна. Без него пайплайн, прерванный потерей пода воркера, остаётся "Выполняется" до перезапуска Radar back.
• Для крупных репозиториев поднимите таймаут Code Downloader: одной минуты может не хватить на клонирование.

Фиксированные таймауты:

Обращение	Таймаут
Воркер → API Radar back	10 с
Воркер → Core, отправка отчёта	20 с
Core → Radar	60 с на POST-запросы, в том числе запуск пайплайнов; 10 с на остальные
Core → сервер лицензий, сверка	10 с, LICENSE_CHECK_TIMEOUT
Core → URL уведомлений	10 с

Очистка Radar

Настройки: Radar → "Настройки" → "Очистка".

Поле	По умолчанию	Что удаляется
"Дней хранить артефакты до очистки"	1	тома Docker старше N дней по дате создания и одноимённые контейнеры
"Дней хранить пайплайны до очистки"	1	записи пайплайнов, завершённых больше N дней назад, вместе с инстансами джоб и их логами

Срок хранения пайплайнов не может быть меньше срока хранения артефактов. Очистка запускается каждый день в 00:00 по расписанию Celery, по умолчанию это 00:00 UTC.

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

Записи пайплайнов можно очистить вручную, тома при этом не трогаются:

curl -sS -H "Authorization: Bearer <токен Radar>" \
  https://radar.example.ru/api/v1/pipelines/clean-old-pipelines/

"Удалить Образы Джоб" удаляет из Docker воркера все образы, указанные в джобах. "Удалить Образ" в карточке джобы - образ одной джобы. Образ снова скачается при следующем запуске джобы: воркер скачивает образ при каждом запуске.

Docker в подах воркера

В Kubernetes у каждого пода воркера свой Docker. Ежедневную очистку выполняет один utils-воркер, и она затрагивает только Docker его пода. Поэтому у каждого пода воркера есть свой контейнер очистки Docker по таймеру - см. Установка в Kubernetes. Без такой очистки на узле scan копится около 8 ГБ томов в сутки.

Прерывание скана

Чтобы прервать скан, используйте "Остановить Пайплайн": команда завершает процесс пайплайна на любом поде воркера. Контейнер текущей джобы может доработать до таймаута джобы.