state.apply и state.sls

state.apply — основная команда применения состояний, и вокруг неё есть путаница, которую стоит снять один раз. Исторически в Salt существуют две функции: state.sls (применить перечисленные SLS-файлы) и state.highstate (применить всё, что назначено миньону через top.sls). state.apply — это удобная обёртка поверх обеих: с аргументом (state.apply nginx) она работает как state.sls nginx, без аргументов (state.apply) — как state.highstate. В повседневной работе достаточно одной state.apply, но понимать, что стоит за каждым вариантом, нужно — от этого зависит, применяете вы точечное изменение или всю конфигурацию хоста разом.

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

Типовые вызовы с мастера и локально на миньоне:

salt 'web*' state.apply                 # highstate: всё из top.sls
salt 'web*' state.apply nginx           # только nginx/init.sls
salt 'web*' state.apply nginx,users     # несколько SLS за один прогон
salt-call state.apply nginx test=True   # локально на миньоне, dry-run

Мастер публикует задание, каждый миньон скачивает нужные SLS (для highstate — предварительно вычислив свой список по top file), рендерит, компилирует и исполняет их локально, а результат возвращает мастеру: по каждому состоянию — Result, Changes, Comment и длительность, в конце — сводка Succeeded/Failed. Код возврата ненулевой, если хоть одно состояние упало, что удобно для CI. Одновременно на миньоне может идти только один прогон состояний: параллельный запуск завершится ошибкой конфликта; аргумент queue=True вместо отказа поставит новый прогон в очередь. Полезные дополнительные аргументы: pillar='{...}' — переопределить pillar-значения на время прогона, exclude — исключить состояния, а state.sls_id применяет один конкретный ID из SLS — самый быстрый способ отладить единственное состояние.

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

Правило простое: точечные изменения — state.apply <sls>, полная конвергенция — state.apply без аргументов. Раскатываете правку конфига nginx — применяйте только nginx: прогон быстрее, diff читается, радиус поражения ограничен. Highstate запускайте при вводе хоста в строй, после правок общих профилей и регулярно по расписанию, чтобы дрейф не накапливался. Хорошая привычка для прода: сначала state.apply nginx test=True и просмотр плана, затем реальный прогон; на большом парке добавляйте батчи (--batch-size 10%), чтобы не перезапустить сервис на всех хостах одновременно. В masterless-режиме те же функции вызываются через salt-call --local state.apply.

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

Частая ошибка новичка — жить только точечными state.apply <sls> и никогда не запускать highstate: назначенные в top file состояния месяцами не применяются, и первый же полный прогон приносит лавину неожиданных изменений. Обратная крайность — гонять highstate ради каждой мелочи и ждать полного прогона там, где хватило бы state.sls_id. Помните, что state.apply nginx без test=True применяет изменения немедленно — «посмотреть, что будет» так нельзя. Ошибка «The function state.apply is running as PID …» означает незавершённый или зависший прогон: посмотрите его через saltutil.running, при необходимости снимите saltutil.kill_job, а не перезапускайте миньон вслепую.

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

• Состояния (states)
• top.sls и highstate
• Режим test=True
• salt-call и masterless-режим
• Batch-выполнение