Runner state.orchestrate

state.orchestrate — это runner, который исполняет сценарии оркестрации: SLS-файлы, описывающие последовательность действий на разных миньонах. Ключевое отличие от state.apply — точка исполнения. 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'а на мастере, и таймауты шагов нужно подбирать под реальные операции, а не оставлять по умолчанию.

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

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

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

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

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