В 2026 году спор «Ansible vs SaltStack vs Puppet» чаще всего упирается не в «кто мощнее», а в эксплуатационную модель: как описывается желаемое состояние (state), как обеспечивается идемпотентность (idempotency), где живет инвентарь (inventory) и насколько критичны скорость реакции, аудит и автономность узлов.
Все три инструмента решают одну задачу — configuration management, но с разными компромиссами. Ansible обычно берут за быстрый старт и push/agentless-подход; Salt — за скорость массовых операций и событийность; Puppet — за зрелую декларативную модель, регулярную конвергенцию и удобный контур контроля дрейфа.
Ниже — сравнение «с позиции продакшена»: что будет болеть через год, где чаще ломается идемпотентность, как не утонуть в переменных, и как выбрать инструмент, который команда реально будет поддерживать.
Коротко о подходах: как оно работает
Полезно разложить системы по нескольким осям: agentless vs агент, push vs pull, модель данных (inventory), модель описания состояния (state) и механизм применения/конвергенции.
Ansible: push, agentless, playbooks
Ansible в типовом сценарии работает по push-модели: управляющая машина подключается по SSH/WinRM, выполняет задачи и завершает сессию. Это и есть практический смысл agentless: на целевых узлах не требуется постоянно работающий агент.
Состояние описывается playbook’ами (YAML) и обычно выглядит как смесь декларативного и императивного подхода: «пакет установлен», «файл лежит», «сервис перезапустить при изменении». На практике Ansible отлично подходит для пошаговых развертываний, bootstrap, миграций и повторяемых «пакетных» операций.
Salt: быстрые агенты и событийная шина
Salt исторически силен в управлении большим количеством узлов за счет агентной модели (minion) и транспорта, рассчитанного на массовые fan-out операции. В классике это «master → minions», быстрые команды на больших группах и удобная событийность.
Состояние описывается через SLS (Salt State) декларативно. Применение может идти по требованию, по расписанию или как реакция на событие. Если вам важны реактивные сценарии «появился инстанс — сразу накатить базу», Salt часто оказывается удобнее.
Puppet: декларативная модель и регулярная конвергенция
Puppet построен вокруг декларативного описания желаемого состояния и регулярного приведения узла к нему. Агент периодически применяет каталог (catalog), полученный от сервера, и отправляет отчеты. Это полезно там, где важны контроль дрейфа, аудит изменений и предсказуемость.
Puppet часто ощущается «тяжелее на входе», но дает строгую модель ресурсов и зависимостей и хорошо живет в больших организациях, где стандарты важнее скорости «сделать прямо сейчас».
Agentless vs агенты: где реальная разница в эксплуатации
Слово agentless звучит как абсолютное благо, но в эксплуатации важно не название, а то, кто и как инициирует изменения, и как узлы возвращаются в эталонное состояние после ручных вмешательств или сбоев.
Что дает agentless (Ansible)
Меньше компонентов на хосте: обычно достаточно SSH и минимального рантайма (например, Python в зависимости от модулей).
Проще согласования с безопасниками: меньше постоянно работающих демонов и «лишних» сервисов.
Удобно для разовых и пакетных задач: инциденты, миграции, массовые правки, первичная настройка.
Какие минусы у agentless
Масштабирование упирается в управляющий контур: параллелизм, задержки SSH, лимиты подключения, очереди, сбор фактов.
«Самоисцеление» не включено по умолчанию: чтобы узлы регулярно сходились к нужному состоянию, вам нужно планирование прогонов (CI, расписание, pull-режим).
Конвергенция зависит от доступности управляющей стороны: если запускать «по случаю», дрейф будет накапливаться.
Плюсы агентной модели (Salt/Puppet)
Регулярная конвергенция: узел сам приводит себя к нужному состоянию по расписанию.
Лучшая масштабируемость по числу узлов: вычисления и применение распределены, меньше нагрузки на один «пушер».
Событийность и оркестрация: особенно заметно у Salt на больших группах.
Минусы агентной модели
Агент нужно сопровождать: обновлять, мониторить, разбирать несовместимости, поддерживать жизненный цикл.
Нужно проектировать сеть и доступы: PKI/ключи, ACL, сегментация, порты, доверие к управляющему контуру.
Выше порог входа: особенно в маленьких командах, где «всё держится на одном человеке».
Практический критерий: если вы хотите, чтобы конфигурация «сама возвращалась в норму» после любых ручных правок и сбоев, агентная конвергенция дает заметный выигрыш. Если же у вас больше задач развертывания, миграций и пакетных действий, и критична простота — agentless чаще удобнее.
Если вам нужно совместить «push-плейбуки» с регулярной конвергенцией, посмотрите на подход Ansible pull через systemd timers: удобно для базовой конфигурации и регулярных прогонов. Подробный разбор — в статье Ansible pull и systemd timers для конвергенции.
Inventory: где живет правда о ваших серверах
Inventory — это не просто список IP. Это «источник истины»: какие хосты существуют, какие у них роли, окружения, группы, параметры, кому они принадлежат и как их безопасно нацеливать на изменения.
Ansible: статический и динамический inventory
В Ansible инвентарь бывает статическим (INI/YAML) или динамическим (плагины/скрипты под облако, CMDB, Terraform state). На практике при росте инфраструктуры почти всегда побеждает динамика, но вместе с ней растет риск «переменного спагетти»: одно и то же значение определено в пяти местах, а истинный приоритет понимают только авторы.
Отдельный эксплуатационный момент — facts. Они удобны, но могут замедлять прогоны и создавать скрытые зависимости (например, разные факты на разных дистрибутивах приводят к разным веткам логики).
Salt: таргетинг, grains и pillar
Сильная сторона Salt — таргетинг: нацеливание на узлы по разным признакам. Роль «инвентаря» часто распределяется между grains (факты о системе) и pillar (данные/параметры/секреты, влияющие на state). В больших парках это удобно, но требует дисциплины по структуре pillar и окружениям.
Puppet: facts и классификация
Puppet традиционно опирается на facts и классификацию узлов (классы, роли/профили, правила назначения). Это хорошо ложится на стандартизированную архитектуру: по фактам определяется роль, по роли — набор ресурсов и параметров.
State и idempotency: почему «второй прогон» должен быть скучным
Идеальная картина в CM такая: вы описали state, запустили применение — система сделала минимум изменений, а повторный запуск ничего не меняет. Это и есть практическая идемпотентность: «повторить безопасно» и без «шума».
Где обычно ломается идемпотентность
Шаблоны без стабильной сортировки: файл «меняется каждый раз» и дергает перезапуски сервисов.
Команды через shell без проверок: скрипт всегда что-то делает, даже если уже сделано.
Случайные значения: генерация ключей/паролей при каждом запуске, таймстемпы в конфигах.
Внешние зависимости без фиксации: «последняя версия пакета», плавающие репозитории, нестабильные API.
Ansible: дисциплина важнее магии
У Ansible много идемпотентных модулей, но главный источник проблем — привычка «сделать через shell». Если нужен действительно «скучный второй прогон», старайтесь использовать специализированные модули, а для команд — явно задавать условия изменения (handlers, changed_when, предварительные проверки).
Salt: декларативные state’ы, но сложная оркестрация
Salt state’ы обычно хорошо поддерживают декларативность. Сложность чаще появляется на уровне оркестрации и событий: когда «события запускают события», важно держать архитектуру прозрачной и наблюдаемой, иначе дебаг превращается в поиск первопричины по цепочке триггеров.
Puppet: сильная модель ресурсов и зависимостей
Puppet традиционно силен в идемпотентности благодаря модели ресурсов. Но порядок и зависимости все равно нужно продумывать там, где это критично (сначала пакет, потом конфиг, потом сервис). Чем больше переиспользования модулей, тем важнее стандарты ролей/профилей и единые правила параметризации.
Мини-чек: как быстро поймать «шумные изменения»
Практика, которая помогает для любого инструмента: на staging прогоняйте применение два раза подряд и сравнивайте результаты. Второй прогон должен быть максимально пустым. Если нет — разбирайте, что именно меняется, и почему.
# пример логики проверки (идея, не универсальная команда)
# 1) прогон
# 2) повторный прогон
# 3) анализ: что помечается как changed и почемуСкорость и масштаб: что будет на 50, 500 и 5000 узлах
На десятках серверов «взлетит» почти всё, если есть дисциплина. Отличия проявляются на сотнях и тысячах, а также при усложнении сети и требований к аудиту.
Ansible
Чаще всего упирается в параллелизм управляющей стороны и стоимость подключений. Масштабирование обычно решают настройками параллельности, разбиением прогонов по окружениям, кэшированием фактов и уменьшением лишних шагов (например, не собирать facts там, где они не нужны). Архитектурно это все равно push.
Salt
Сильная сторона — скорость доставки команд на множество minion’ов и событийная модель. Для массовых операций и быстрых изменений на больших группах Salt часто ощущается «живее». Цена — сопровождение master/minion и более плотная работа с безопасностью и сегментацией.
Puppet
Puppet раскрывается в регулярной конвергенции и управляемости. На больших парках важны: производительность сервера (компиляция catalog), распределение нагрузки, хранение отчетов, четкая модель ролей. Если процесс эксплуатации построен вокруг требования «узел обязан соответствовать стандарту постоянно», Puppet — естественный кандидат.
Порог входа и сопровождение: что будет через год
Выбор инструмента — это выбор долговременной операционной модели. Спросите себя: кто будет поддерживать репозиторий CM, кто будет разбирать инциденты, кто будет проводить ревью изменений и кто сможет безопасно развивать систему.
Ansible: быстрый старт, риск YAML-хаоса
Playbook’и легко начать писать, но через год часто всплывают дублирование задач, разный стиль переменных, отсутствие ролей/коллекций и слабая тестируемость. Если заранее принять стандарты (структура ролей, линтеры, тесты, CI на прогон), Ansible остается управляемым и удобным.
Если хотите строить LEMP-стек через IaC и не превращать CM в «набор ручных плейбуков», полезно сопоставить Terraform и Ansible по зонам ответственности: Terraform + Ansible для LEMP: практическая схема.
Salt: мощно, но требует инженерной культуры
Salt удобен, когда команда готова мыслить состояниями и событиями. Нужны соглашения по pillar, окружениям, правилам оформления state’ов и тому, как проверяется влияние изменений.
Puppet: высокая цена входа, но стабильность в долгую
Puppet просит дисциплины на старте: структура модулей, разделение данных, роли/профили. Если команда готова к этому, через год обычно получаете более устойчивый контроль стандартов, меньше «ручных правок» и понятный контур аудита.
Типовые сценарии: что выбрать «по задаче»
1) Один проект, до 20–50 серверов, нужен быстрый результат
Часто выигрывает Ansible: проще старт и внедрение в команду, удобно для bootstrap и деплоя. Ключевой фактор успеха — договориться о структуре репозитория и правилах идемпотентности с первого дня.
2) Много однотипных узлов, нужна скорость массовых операций и реакция на события
Здесь Salt обычно выглядит сильнее: быстрые fan-out операции, гибкий таргетинг и событийность.
3) Нужен постоянный контроль дрейфа, стандарты и аудит
Puppet — один из самых прямых вариантов, особенно если вы хотите регулярную конвергенцию и отчеты как часть ежедневной эксплуатации.
4) Смешанная инфраструктура и «зоопарк» технологий
В «зоопарке» побеждает архитектура, а не название инструмента. Нередко используют комбинацию: например, Ansible для оркестрации/деплоя, а Puppet или Salt — для постоянного поддержания базового состояния. Важно заранее определить границы ответственности, иначе получите конфликтующие изменения.
Чек-лист выбора в 2026: вопросы, которые экономят месяцы
Вам нужен push или регулярная конвергенция? То есть вы запускаете изменения централизованно или узлы должны сами сходиться к состоянию по расписанию.
Где ваш источник истины для inventory? Статика, облако, Terraform, CMDB. Допустим ли один источник или будет несколько.
Как вы контролируете идемпотентность? Меньше shell, больше декларативных ресурсов, понятные условия изменений, тесты.
Как вы тестируете изменения? Staging, CI, smoke-checks, понятный план отката.
Кто сопровождает систему? Сколько людей реально понимают модель данных/состояний и способны дебажить.
Как вы храните секреты? Разделение dev/stage/prod, ротации, минимизация утечек, принцип наименьших привилегий.
Практическая рекомендация: как принять решение без религиозных войн
Самый надежный путь — короткий пилот на вашей инфраструктуре. Возьмите один типовой сервис (например, Nginx + приложение + unit для systemd + базовые настройки логирования) и проверьте один и тот же набор критериев: читаемость описания state, скорость прогона, поведение при повторном запуске (idempotency), удобство работы с инвентарем, диагностика ошибок и удобство внесения изменений через ревью.
Если нужен универсальный «первый CM» и вы не хотите строить агентный контур — чаще всего практичнее Ansible. Если критичны скорость и событийность на большом числе узлов — присмотритесь к Salt. Если нужен строгий контроль состояния, регулярная конвергенция и аудит — Puppet будет ближе к вашей модели эксплуатации.
Хороший выбор — тот, который команда сможет поддерживать, тестировать и безопасно развивать. Инструмент, который «идеален на бумаге», но не принят процессами, быстро превращается в набор ручных исключений.
Мини-глоссарий
Configuration management — управление конфигурациями и желаемым состоянием серверов через код и автоматизацию.
Idempotency — свойство применения изменений «без сюрпризов»: повторный запуск не ломает систему и не вносит лишних изменений.
Agentless — модель, где на управляемых узлах не требуется постоянный агент (часто достаточно SSH).
Inventory — список узлов и их параметров/групп/переменных, с которыми работает CM.
State — описание желаемого состояния (пакеты, файлы, сервисы, параметры), к которому система приводит узлы.
