Состояния (states)

Состояние (state) — это описание того, как должен выглядеть фрагмент системы: пакет установлен, сервис запущен, файл имеет нужное содержимое и права. Вместо последовательности команд («выполни apt install, потом systemctl start») вы декларируете конечный результат, а Salt сам вычисляет, что нужно сделать на конкретном миньоне, чтобы к этому результату прийти. Это главный слой Salt поверх удалённого выполнения: execution-модули отвечают на запрос «сделай сейчас», состояния — «приведи и держи в таком виде». Именно система состояний превращает Salt из «параллельного SSH» в полноценный инструмент управления конфигурацией уровня Ansible или Puppet.

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

Состояния описываются в SLS-файлах — YAML (по умолчанию с Jinja-препроцессором), которые лежат на файловом сервере мастера в file_roots (обычно /srv/salt). Минимальный пример /srv/salt/nginx.sls:

nginx:
  pkg.installed: []
  service.running:
    - enable: True
    - require:
      - pkg: nginx

Здесь nginx — ID-декларация, pkg.installed и service.running — вызовы state-модулей. Команда salt 'web*' state.apply nginx отправляет задание миньонам; каждый миньон сам скачивает SLS с мастера, рендерит его (Jinja → YAML → структура данных), компилирует в упорядоченный список состояний и выполняет локально. Ключевое свойство — идемпотентность: state-модуль сначала проверяет фактическое состояние системы и вносит изменения только при расхождении с описанным. Если nginx уже установлен и запущен, повторный прогон вернёт Result: True с пустым Changes. Поэтому состояния можно применять регулярно по расписанию: система каждый раз «дотягивается» до описанной нормы, а ручной дрейф на серверах автоматически откатывается.

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

Состояния — правильный выбор для всего, что должно быть воспроизводимо: базовая настройка серверов (пользователи, sshd, пакеты), раскатка приложений, конфиги сервисов. Практический признак, что пора переходить от cmd.run к состояниям, — вы второй раз выполняете одну и ту же последовательность команд. Разовые операции (перезапустить сервис при отладке, собрать диагностику, почистить кэш) остаются за execution-модулями: оборачивать их в state — лишняя работа без выгоды. По сравнению с Ansible-плейбуками SLS-файлы декларативнее: нет «шагов», есть целевое состояние плюс явные зависимости через requisites. А поскольку исполнение происходит на самих миньонах, применение состояний к тысячам хостов масштабируется без пропорционального роста нагрузки на управляющую машину.

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

Главный антипаттерн — писать состояния как скрипт из цепочки cmd.run: такой SLS не идемпотентен, при каждом прогоне показывает «изменения» и делает бессмысленным контроль дрейфа; если без cmd.run не обойтись, добавляйте условия unless/creates. Вторая ошибка — полагаться на порядок следования блоков в файле вместо явных зависимостей: порядок в SLS сохраняется, но при include и разрастании кода связи нужно фиксировать через require/watch. Третья — править те же конфиги руками на сервере и удивляться, что Salt их перезаписал: источник истины либо в состояниях, либо нигде. Наконец, не применяйте новые состояния сразу на прод — сначала прогоните их с test=True и посмотрите план изменений.

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

• SLS-файлы и YAML
• State-модули
• state.apply и state.sls
• Requisites: require и watch
• Режим test=True