Batch-выполнение

По умолчанию Salt выполняет команду на всех миньонах таргета одновременно — в этом его сила и скорость, но иногда это именно то, чего делать нельзя. Перезапустить сервис сразу на всех веб-серверах — значит уронить сервис целиком; запустить pkg.upgrade на тысяче машин — значит устроить шторм запросов к репозиторию. Batch-выполнение решает это: флаг -b (или --batch-size) ограничивает число миньонов, работающих одновременно. salt '*' -b 10% service.restart nginx перезапустит nginx волнами по десять процентов парка — остальные ждут своей очереди, и сервис остаётся доступным.

Как это работает

Размер батча задаётся числом (-b 10 — по десять миньонов) или процентом (-b 10% — десятая часть от отвечающих). Механика скользящего окна: мастер публикует задание первой группе, и как только какой-то миньон вернул результат, его место в окне занимает следующий из очереди — размер активной группы держится постоянным, а не «волна закончилась — начали новую». Перед стартом Salt проверяет доступность миньонов, чтобы процент считался от реально живых машин. Поведением при ошибках управляет опция --batch-wait (пауза между запусками) и параметр failhard — с ним первая же ошибка останавливает раздачу задания дальше. Batch доступен не только из CLI: в orchestration-SLS у функции salt.state есть параметр batch, так что rolling-стратегия описывается декларативно, в коде сценария.

Когда применять

Первый сценарий — rolling-операции над сервисами за балансировщиком: рестарты, деплой, применение состояний, где одновременная недоступность всех узлов недопустима. -b 25% даёт четыре волны — компромисс между скоростью и запасом прочности. Второй — защита разделяемых ресурсов: обновление пакетов на большом парке бьёт по зеркалу репозитория, массовый state.apply с закачкой артефактов — по файловому серверу мастера; батчи размазывают нагрузку во времени. Третий — осторожные изменения: прогнать рискованную команду сначала на -b 5, посмотреть на возвраты первой волны и только потом отпускать на весь парк. Если же операция безопасна и лёгкая (test.ping, чтение фактов) — батчить незачем, параллельность тут и есть преимущество Salt.

Типичные ошибки

Классика — перезапуск сервиса на всём парке без батча: формально команда отработала, фактически сервис лежал, пока все узлы стартовали. Обратная крайность — слишком мелкий батч на большом парке: -b 1 на тысяче машин растягивает операцию на часы, и таймаут CLI может истечь раньше, чем дойдёт очередь до последних. Ещё одна ловушка — процент от живых: -b 50% при половине упавших миньонов означает совсем не ту волну, на которую вы рассчитывали; проверяйте парк через salt-run manage.status перед раскаткой. И помните, что batch не отменяет requisites: порядок операций внутри одной машины задаётся состояниями, batch управляет только тем, сколько машин работает одновременно.

Как это работает

Когда применять

Типичные ошибки

Связанные понятия

Полезные ресурсы