Документация / Руководство по установке / Эксплуатация
Обновление
Обновление выполняет команда SecurityFlow: переносит образы новой версии в реестр площадки и обновляет компоненты в кластере. От площадки нужны окно без сканов и подтверждение, что резервная копия снята. Порядок ниже одинаков для любого обновления; что изменилось в конкретной версии, смотрите в Релизах, блок "Важно при обновлении".
Шаги выполняются командами kubectl. Для Core тег образа sf-core-back меняется в Job подготовки базы и во всех процессах на этом образе: интерфейс и API, приём отчётов, worker, планировщик. Состав компонентов - в разделе Установка в Kubernetes.
Что меняется при обновлении
- Образы компонентов:
sf-core-back,sf-core-front, воркеры Core,sf-radar-back,sf-radar-worker,sf-radar-front. Обновляются только компоненты, у которых вышла новая версия. - Схемы баз Core и Radar: миграции идут до переключения процессов на новый код.
- Не меняются: секреты, данные в базах, файлы Core, тома брокеров.
Сервер лицензий обновляет команда SecurityFlow отдельно. Пока он недоступен, Core продолжает работать: лицензия проверяется локально до окончания её срока.
Перед обновлением
| Шаг | Что сделать |
|---|---|
| Прочитать заметки к версии | Релизы: изменения конфигурации, ломающие миграции, требования к окну |
| Выбрать окно | время без сканов: обновление Radar back прерывает все идущие пайплайны |
| Проверить образы | все образы новой версии есть в реестре площадки |
| Снять резервную копию | базы Core и Radar, файлы Core, секреты - см. Резервное копирование. Без копии миграции не запускайте |
| Записать текущие версии | список образов всех компонентов - он нужен для отката |
for ns in securityflow-core securityflow-radar; do
kubectl -n "$ns" get deploy,statefulset,job \
-o custom-columns=KIND:.kind,NAME:.metadata.name,IMAGE:.spec.template.spec.containers[*].image
done > versions-before.txt
Порядок обновления
1. Остановить новые сканы
В Core выключите "Активно" у расписаний в "Radar" → "Расписание". Дождитесь, пока в Radar не останется пайплайнов "В ожидании" и "Выполняется", или остановите их кнопкой "Остановить все пайплайны".
2. Снять резервную копию
Снимите копию баз Core и Radar и проверьте её - Резервное копирование. Если базы копируются pgBackRest - полную копию или именованную точку восстановления с проверкой архива WAL.
3. Миграции Core
Подготовка базы Core запускается заново Job с новым образом sf-core-back. Она применяет миграции, собирает статику, проверяет администратора и имена сканеров. Пароль существующего администратора не меняется.
kubectl -n securityflow-core delete job sf-core-init
kubectl -n securityflow-core apply -f <Job sf-core-init с новым тегом>
kubectl -n securityflow-core wait --for=condition=complete job/sf-core-init --timeout=900s
kubectl -n securityflow-core logs job/sf-core-init
Если Job не завершилась, дальше не идите: процессы Core работают на старой версии. Разберите журнал Job. Если миграции успели примениться частично - восстановите базу из копии шага 2.
4. Процессы Core
Обновите образ во всех компонентах Core по одному и дождитесь каждого. Порядок: фронт, интерфейс и API, приём отчётов, worker, планировщик, разбор отчётов, помощник БД, Jira-помощник. Интерфейс и API, приём отчётов, worker и планировщик получают новый тег sf-core-back. Фронт и воркеры из образов sf-core-front, sf-core-importer, sf-core-db-helper, sf-core-jira-helper обновляются своими образами.
kubectl -n securityflow-core set image deployment/<компонент> <контейнер>=registry.example.ru/sf-core-back:<версия>
kubectl -n securityflow-core rollout status deployment/<компонент> --timeout=600s
Компоненты с двумя репликами и больше обновляются без простоя: старый под уходит после того, как новый начал отвечать. Планировщик Core обновляется со стратегией Recreate: на время перезапуска периодические задачи не ставятся. Помощник БД в одной реплике на время перезапуска недоступен.
5. Radar
- Уменьшите Radar back до одной реплики и обновите его образ. При старте он применяет миграции базы Radar (
alembic upgrade head) и обновляет каталог джоб. - Проверьте журнал: миграции прошли, сервер запущен.
- Верните две реплики.
- Обновите воркеры сканирования, планировщик Radar и фронт Radar.
kubectl -n securityflow-radar scale deployment <Radar back> --replicas=1
kubectl -n securityflow-radar set image deployment/<Radar back> <контейнер>=registry.example.ru/sf-radar-back:<версия>
kubectl -n securityflow-radar rollout status deployment/<Radar back> --timeout=600s
kubectl -n securityflow-radar logs deployment/<Radar back> | grep -E "Alembic|Uvicorn"
kubectl -n securityflow-radar scale deployment <Radar back> --replicas=2
Одна реплика на время миграций нужна потому, что каждый под Radar back применяет миграции при старте: две реплики, стартующие одновременно, выполняли бы их параллельно.
Пользовательские настройки джоб при обновлении сохраняются, если токен Radar создан: без токена в базе Radar back при старте пересоздаёт джобы из каталога. Каталог джоб пополняется новыми джобами из версии.
6. Проверка
| Что | Как | Ожидаемый результат |
|---|---|---|
| Поды | kubectl -n securityflow-core get pods, kubectl -n securityflow-radar get pods |
все Running, Job подготовки - Completed, перезапусков нет |
| Версии | kubectl -n <пространство> get deploy -o wide |
образы новой версии |
| Core | curl -sS -o /dev/null -w '%{http_code}\n' https://core.example.ru/admin/login/ |
200 |
| Radar | curl -sS https://radar.example.ru/api/v1/health-check/ |
{"is_healthy":true} |
| Вход и лицензия | вход в Core, "Глобальные настройки" → "Лицензия" | вход работает, лицензия на месте |
| Связь Core и Radar | Core: "Radar" → "Настройки" → "Статус подключения" | "Подключено", "Аутентифицировано" |
| Воркеры | Radar: "Настройки" → "Воркеры" | все поды воркера подключены |
| Скан | аудит тестового продукта | пайплайн "Завершен", аудит в Core |
7. Вернуть сканы
Включите расписания аудитов, сообщите командам, что сканирование из CI снова доступно.
Миграции
| Компонент | Когда идут | Где |
|---|---|---|
| Core | в Job подготовки базы, до обновления процессов | python manage.py migrate --no-input |
| Radar | при каждом старте Radar back | alembic upgrade head |
Миграции идут до переключения процессов, поэтому какое-то время старый код работает с новой схемой. Обычные миграции это допускают. Если релиз содержит миграцию, несовместимую со старым кодом, - например удаляет или переименовывает таблицу, - обновление идёт с остановкой: процессы в ноль, миграция, запуск новой версии. Смотрите блок "Важно при обновлении" в Релизах.
Откатить схему базы обратной миграцией нельзя - только восстановлением из резервной копии.
Откат
| Ситуация | Что сделать |
|---|---|
| Компонент не поднялся, миграции не применялись | kubectl -n <пространство> rollout undo deployment/<компонент> |
| Job подготовки базы упала до миграций | процессы Core не трогались; исправьте причину и запустите Job снова |
| Миграции применены, новая версия работает неправильно | полный откат: остановите процессы Core и Radar, восстановите обе базы из копии, снятой перед обновлением, верните образы по versions-before.txt, запустите |
При полном откате:
- восстанавливайте обе базы из копий одного момента - Core и Radar связаны аудитами и токеном Radar;
- секреты оставьте прежними: пара JWT и
DOCKER_ENCRYPTION_TOKENдолжны совпадать с теми, при которых снята копия; - после запуска Radar back остановит пайплайны, которые в копии числились идущими.
Порядок восстановления баз - Резервное копирование.
Чего не делать при обновлении
- Не меняйте
JWT_PRIVATE_KEY,JWT_PUBLIC_KEYиDOCKER_ENCRYPTION_TOKEN: сохранённые секреты интеграций и пароли реестров станут нечитаемыми. - Не держите две реплики планировщика Core или планировщика Radar даже на время обновления.
- Не обновляйте Radar back во время сканов.
- Не запускайте миграции без резервной копии.