top.sls и highstate

top.sls — это карта соответствия «какие миньоны получают какие состояния». Отдельные SLS-файлы описывают, что настраивать; top file отвечает на вопрос где: веб-серверы получают nginx, базы — postgres, и все — базовый профиль с пользователями и sshd. Полный набор состояний, который top file назначает конкретному миньону, называется highstate. Команда salt '*' state.highstate (или state.apply без аргументов) — центральный ритуал эксплуатации Salt: «приведи всю инфраструктуру к описанной норме». Именно top file превращает набор разрозненных SLS в единую модель инфраструктуры, которую можно применять целиком, регулярно и предсказуемо.

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

Файл top.sls лежит в корне file_roots (обычно /srv/salt/top.sls). Верхний уровень — окружения (base — по умолчанию), внутри — цели таргетинга и списки SLS:

base:
  '*':
    - common
    - users
  'web*':
    - nginx
  'G@os_family:Debian and G@role:db':
    - match: compound
    - postgres

По умолчанию цель — glob по ID миньона; строка - match: compound (или grain, pcre, nodegroup) переключает тип таргетинга. При запуске highstate миньон запрашивает у мастера top file, вычисляет, под какие цели он подпадает, — совпадения суммируются, поэтому миньон web1 из примера получит common, users и nginx — затем скачивает и компилирует все назначенные SLS в единый список состояний и применяет его. Окружения (base, dev, prod) сопоставляются с разными каталогами file_roots или ветками при использовании GitFS; какое окружение использовать, задаётся опцией environment/saltenv. У pillar есть собственный, отдельный top.sls в pillar_roots — файлы с одинаковым именем, но разные системы.

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

Highstate — это режим «вся конфигурация целиком»: его применяют при вводе нового сервера в строй, после изменения общих профилей и по расписанию (через scheduler или cron) для борьбы с дрейфом. Если вы катите точечное изменение одного сервиса, быстрее и безопаснее применить конкретный SLS через state.apply nginx, не трогая остальное. В top file держите структуру из ролей: маленький список универсальных состояний под '*' плюс ролевые блоки по grains или nodegroups. Таргетинг по кастомному grain role удобнее glob-паттернов имён: имена хостов меняются, роли — реже. Несколько окружений оправданы, когда SLS-код проходит стадии dev → prod; для небольшой инфраструктуры достаточно одного base.

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

Опаснее всего — «щедрые» цели: неточный glob вида web* может зацепить webmail, и сервер получит чужую конфигурацию; проверяйте охват заранее командой salt 'web*' test.ping и просматривайте state.show_top. Вторая ошибка — класть в top file логику: он должен оставаться тонкой картой назначений, а условия и вариативность жить в SLS и pillar. Третья — путать top file состояний с top file pillar и искать, «почему pillar не приехал», не в том файле. Ещё одна классика: миньон не подпал ни под одну цель — highstate завершится ошибкой «No Top file or master_tops data matches found»; это сигнал проверить ID миньона и цели, а не «сломанный Salt».

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

• Состояния (states)
• state.apply и state.sls
• Таргетинг миньонов
• Окружения и ветки
• Pillar top file