Runner state.orchestrate

state.orchestrate — это runner, который исполняет сценарии оркестрации из SLS-файлов, описывающих последовательность действий на разных миньонах. В отличие от state.apply, который выполняется на миньоне и управляет одной машиной, state.orchestrate выполняется на мастере и управляет всем парком миньонов, определяя, какие состояния должны быть применены на каких таргетах и в каком порядке. Запускается он командой salt-run state.orchestrate orch.deploy, где orch.deploy — путь к файлу orch/deploy.sls в file_roots в точечной нотации. У runner'а есть короткий псевдоним state.orch, который выполняет ту же функцию.

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

Orchestration-SLS пишется на YAML + Jinja, но с другим набором функций. Основные строительные блоки: salt.state — применение конкретного SLS или highstate на группе миньонов (параметры tgt — таргет, sls — список состояний, опционально highstate: True); salt.function — вызов execution-модуля на таргете, например service.restart или test.ping; salt.runner — вызов другого runner'а с мастера; salt.wait_for_event — приостановка сценария до появления события на шине. Типовой шаг выглядит так: deploy_app: salt.state: [tgt: 'web*', sls: app.deploy, require: [salt.state: migrate_db]]. Мастер публикует каждый шаг как обычное задание, ждёт возвраты от всех миньонов таргета, оценивает успех и по requisites решает, что выполнять дальше. Внутри шагов salt.state также работает batch — можно катить состояние волнами прямо из сценария.

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

Используйте state.orchestrate, когда результат зависит от порядка действий на разных машинах: сначала salt.state с миграциями на db*, затем деплой на web*, в конце salt.function с проверкой здоровья. Второй классический случай — rolling-обновления: шаг деплоя с batch: '25%' обновляет парк волнами, а упавшая волна останавливает сценарий раньше, чем сломается всё. Третий — связка с Reactor: реактор не умеет сложной логики, поэтому правильный паттерн — реактор ловит событие и вызывает state.orchestrate, а вся логика живёт в orchestration-SLS, который можно тестировать отдельно, запуская руками. Если же все шаги касаются одной машины, оркестрация не нужна, достаточно обычного состояния с requisites.

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

Частая ошибка — путать контексты: писать в orchestration-SLS обычные state-модули (pkg.installed, file.managed) без обёртки salt.state — мастер попытается применить их к самому себе. Обратная ошибка — вызывать orchestration-файл через salt '*' state.apply вместо salt-run. Ещё один источник проблем — недоступные миньоны: salt.state считает шаг проваленным, если хоть один миньон таргета не ответил, и сценарий с failhard остановится; для допустимых потерь продумывайте таргеты и обработку ошибок заранее. Наконец, следите за временем выполнения: длинный сценарий держит процесс runner'а на мастере, и таймауты шагов нужно подбирать под реальные операции, а не оставлять по умолчанию.

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

• Оркестрация
• Runners и salt-run
• state.apply и state.sls
• Requisites: require и watch
• Reactor