Salt vs Ansible / Puppet / Chef

Salt, Ansible, Puppet и Chef решают задачу приведения серверов к описанному состоянию, но отличаются по трём аспектам: модель связи (агент против agentless), направление доставки (push против pull) и язык описания (YAML против DSL/Ruby). Важно выбрать комбинацию осей, соответствующую масштабу, скорости реакции и опыту команды. Salt занимает позицию «агентный push с постоянным соединением», обеспечивая быстрый отклик на большом парке и событийную автоматизацию, которой нет у других.

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

Ansible работает в режиме agentless, подключаясь по SSH при каждом запуске плейбука. Состояния описываются на YAML, что снижает порог входа, но замедляет работу: обход тысяч хостов по SSH занимает много времени, и между запусками плейбука инструмент «не видит» инфраструктуру. Puppet и Chef используют pull-модель: агент на хосте периодически опрашивает сервер и сходится к описанному состоянию. Конфигурация на собственном DSL (Puppet) или Ruby (Chef) обеспечивает устойчивую сходимость, но реакция ограничена интервалом опроса, а массовое действие требует дополнительных усилий.

Salt использует push через постоянное ZeroMQ-соединение: миньоны уже подключены к мастеру, поэтому команда уходит на весь парк за секунды. Состояния описываются на YAML + Jinja, как в Ansible, но сверху есть шина событий: beacons сообщают о происходящем на миньонах, reactor запускает автоматическую реакцию. Salt также поддерживает agentless-режим (salt-ssh), покрывая нишу Ansible, но с меньшим комфортом.

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

Выбирайте Salt, когда парк измеряется сотнями-тысячами машин и важны секунды отклика, либо когда нужна событийная автоматизация (самовосстановление, авторегистрация новых узлов). Ansible выигрывает на старте и в гетерогенных задачах «оркестрация + деплой» при небольшом или среднем парке: нет агентов — нет инфраструктуры, которую надо сопровождать. Puppet/Chef оправданы там, где уже есть многолетняя кодовая база на их DSL и команда с экспертизой — мигрировать ради миграции невыгодно. Честный компромисс Salt: платой за скорость будет агент и мастер, которые нужно ставить, обновлять и мониторить, плюс кривая обучения круче ансибловской — понятий (grains, pillar, reactor, requisites) заметно больше.

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

Типовая ошибка — сравнивать инструменты по синтаксису, игнорируя операционную модель: agentless-Ansible на 5000 хостов упирается в скорость SSH-обхода, и появляются самодельные обвязки, которые Salt даёт из коробки. Обратная ошибка — тащить Salt на 20 серверов ради «правильной архитектуры» и получить мастер, ключи и агентов там, где хватило бы одного плейбука. Третья — смешивать инструменты без границ ответственности: Ansible и Salt, управляющие одними и теми же файлами, будут молча перезаписывать друг друга. И не забывайте, что «инструмент X быстрее» из чужого бенчмарка ничего не значит без вашего профиля: количества хостов, частоты запусков и требований к времени реакции.

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

• Что такое Salt
• Архитектура master–minion
• Событийная модель
• salt-ssh (agentless)
• Роадмап Ansible