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) заметно больше.

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

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

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

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