Почему этот вопрос снова актуален в 2026
Когда вы админите десятки (или сотни) серверов, «просто выполнить набор команд по SSH» быстро превращается в боль: версии пакетов «поплыли», настройки расходятся между окружениями, кто-то «подкрутил на проде», а через неделю никто не помнит, что именно. В 2026 году это не стало менее актуальным — наоборот, инфраструктуры стали более гибридными: часть в виртуальных машинах, часть в контейнерах, часть в managed-сервисах, и всё чаще требуется воспроизводимость и аудит изменений.
Отсюда два взаимосвязанных тренда:
- configuration management — необходимость держать состояние систем предсказуемым, повторяемым и проверяемым;
- GitOps — Git как «источник правды» и автоматическое применение изменений по событию (коммит/мердж), а не вручную.
Дальше разберём Ansible vs SaltStack, а также Puppet vs Chef не в стиле «кто лучше вообще», а с практичной оптикой: какая модель подходит под ваш процесс, что с идемпотентностью, как жить с секретами и как решать задачу дрейфа конфигурации.
GitOps и конфиг-менеджмент: где проходит граница
GitOps часто путают с IaC и конфиг-менеджментом. Упростим:
- GitOps — операционная модель: Git как «источник правды», ревью и политики, автоматический запуск применения, наблюдаемость и откаты через историю коммитов.
- Configuration management (Ansible, Salt, Puppet, Chef) — инструменты, которые приводят узлы к нужному состоянию: пакеты, сервисы, файлы, пользователи, firewall, параметры ОС и т.д.
Связка выглядит так: Git хранит «желаемое состояние» (playbook/state/manifest/recipe), CI проверяет изменения (линтеры, тесты), а затем runner или агент применяет конфигурацию на серверах. Подходы сильно отличаются по философии: где-то изменение «толкается» снаружи (push), где-то узлы «подтягивают» конфигурацию сами (pull), где-то модель ближе к непрерывной конвергенции состояния.
Push vs Pull в контексте GitOps
GitOps в классическом виде тяготеет к pull-модели: агент на целевой системе периодически забирает состояние (или получает сигнал) и применяет. Это снижает требования к inbound-доступу и упрощает сегментацию (серверы не нужно «открывать» для внешних оркестраторов).
Но на практике многие команды успешно живут и с push-моделью, если доступы и аудит выстроены: отдельные bastion/runner, ограниченные ключи, журналы выполнения, а также понятная политика «кто и когда может применить изменения».
Критерии сравнения: что реально важно для продакшена
Чтобы сравнение не было вкусовщиной, фиксируем критерии, по которым обычно выбирают стек в 2026:
- Agentless vs agent: нужен ли агент на узле, как устроены коммуникация и доступы.
- Идемпотентность: насколько безопасно повторять применение и как инструмент ведёт себя при частичных сбоях.
- Drift detection: как обнаружить изменения вне Git и как возвращать систему к желаемому состоянию.
- Secret management: шифрование, ротация, раздача секретов, контроль утечек в логах и артефактах.
- Масштабирование и скорость: параллелизм, event-driven, управление сотнями и тысячами узлов.
- Порог входа и поддерживаемость: читаемость DSL, экосистема модулей/ролей, тестирование, дебаг.
- Операционная модель: насколько удобно жить в GitOps-процессе (политики, ревью, окружения, промоут, откат).
Короткий «портрет» каждого инструмента
Ansible в 2026
Ansible остаётся самым популярным «входом» в конфиг-менеджмент: SSH, YAML, минимум инфраструктуры вокруг. Сильная сторона — agentless-модель: вы можете стартовать с одного control-node и ключей, а дальше развивать практики (роли, коллекции, тесты, AWX/Automation Controller или CI-runner).
Компромисс: без дополнительных компонентов Ansible хуже подходит для постоянной конвергенции состояния и нативного drift detection — он «выполнил и ушёл». В GitOps это закрывают расписанием прогонов, режимами проверки, отчётами и внешними контролями.
SaltStack в 2026
Salt исторически силён там, где нужна скорость, параллелизм и управление «флотом» машин. Его модель чаще agent-based (minion), хотя есть и режимы без агента. Salt ценят за гибкую архитектуру: удалённое выполнение, event bus, реакторы, оркестрация — и за то, что он часто воспринимается как платформа оперативного управления инфраструктурой, а не только «про конфиги».
В GitOps Salt нередко используют как исполнительный слой: Git хранит states/pillar, а minion/master (или masterless) периодически приводит систему к состоянию. Это естественно ложится на контроль дрейфа через регулярное применение и отчётность.
Puppet в 2026
Puppet — представитель декларативного конфиг-менеджмента с фокусом на конвергенцию: агент периодически запрашивает каталог и приводит узел к желаемому состоянию. Это даёт сильную основу для борьбы с дрейфом: если кто-то «поправил руками», агент вернёт обратно (или зафиксирует расхождение).
Цена — инфраструктурная сложность и необходимость дисциплины: CA/сертификаты, окружения, жизненный цикл модулей, совместимость версий. Зато в больших парках серверов Puppet часто силён именно как «система удержания состояния».
Chef в 2026
Chef ближе к подходу «инфраструктура как код» в смысле программируемости: рецепты на Ruby дают свободу, но требуют более высокой квалификации и дисциплины. Chef может быть агентным, с регулярными запусками, и хорошо живёт в enterprise-процессах, где важны политики, роли, окружения, cookbook-экосистема и аудит.
В сравнении Puppet и Chef выбор часто сводится к вопросу: нужен ли вам более строгий декларативный DSL (Puppet) или вы хотите максимальную программируемость (Chef) ценой сложности.
Ansible vs SaltStack: где разница ощущается «руками»
Agentless vs agent
Ansible по умолчанию agentless: SSH (для Linux/Unix), WinRM/SSH (для Windows). Это упрощает старт и снижает постоянный «операционный шум» от агентов. Но доступ по SSH должен быть организован безопасно, а параллельные изменения — контролироваться (например, блокировками в пайплайне и ограничением числа одновременных прогонов).
SaltStack чаще раскрывается в agent-модели: minion постоянно на узле и принимает задания. Это удобнее для крупных инфраструктур и для сценариев «быстро выполнить на многих», но добавляет слой, который нужно обновлять, мониторить и защищать.
Идемпотентность и предсказуемость повторных прогонов
И Ansible, и Salt могут быть идемпотентными, но «ощущение идемпотентности» зависит от вашего стиля. Если вы часто используете shell-команды, вы сами отвечаете за идемпотентность (проверки, условия, корректные сравнения). Чем больше вы опираетесь на декларативные модули (пакеты, сервисы, шаблоны, пользователи), тем проще обеспечить предсказуемость.
Практическое правило: если в репозитории конфигурации больше 20–30% «shell-команд», любая система управления конфигурацией постепенно превращается в «набор скриптов», и проблемы повторяемости становятся вопросом времени.
Drift detection
В Ansible дрейф чаще ловят косвенно: регулярными прогонами в режиме проверки, отчётами о diff, алертами на изменения файлов или пакетов, и обязательным повторным применением по расписанию. В Salt регулярное применение states (или реакторы) может быть более «нативным» способом удержания состояния, особенно в agent-модели.
Если у вас частые «ручные правки» в проде (а они будут, даже если вы их запрещаете), Salt и в целом агентные системы проще превращают это в управляемый процесс: дрейф либо автоматически исправляется, либо становится видимым через отчёты.
Puppet vs Chef: выбор между декларативностью и программируемостью
Декларативная модель и конвергенция
Puppet обычно воспринимается как более «жёсткая» система: вы описываете желаемое состояние, а агент регулярно приводит узел к нему. Это повышает стабильность и делает контроль дрейфа частью жизненного цикла.
Chef даёт больше гибкости за счёт Ruby: легко писать сложные условия, вычислять параметры, строить нетривиальные зависимости. Но чем больше логики, тем выше риск непредсказуемости при повторных прогонах, если команда не выработала стандарты (тесты, линтеры, code review).
Порог входа и поддержка командой
В 2026 году стоимость владения часто важнее «красоты архитектуры». Если у вас команда вебмастеров или админов, которым нужен быстрый результат и понятные изменения в Git, то Ansible обычно выигрывает по времени внедрения. Puppet и Chef чаще оправданы, когда:
- узлов много и они долго живут;
- нужен постоянный контроль дрейфа;
- есть требования к централизованной политике и аудиту;
- есть ресурсы на поддержку серверной части и процессов вокруг.
Secret management: общие принципы и типичные ошибки
Независимо от выбора инструмента, секреты — это место, где GitOps ломается чаще всего. Типовые ошибки всё те же:
- секреты попадают в Git «временно»;
- секреты уходят в логи (особенно при verbose-режимах);
- один и тот же секрет используется годами без ротации;
- секреты хранятся в переменных окружения без ограничений на чтение;
- нет разделения по окружениям (dev/stage/prod).
Рабочая стратегия: держать секреты вне репозитория в зашифрованном виде или в специализированном хранилище, а в Git хранить только ссылки, манифесты и шаблоны доступа. Если вам нужна практическая схема для GitOps с шифрованием секретов, посмотрите материал: как хранить и доставлять секреты в GitOps без утечек.
На уровне конфиг-менеджмента важно, чтобы секреты:
- не печатались в stdout (используйте режимы «no log», маскирование, отдельные каналы выдачи);
- передавались на узлы по защищённому каналу и с минимальным временем жизни;
- имели понятную модель ротации и отзыва;
- были разделены по принципу наименьших привилегий.
Если вы внедряете управление сертификатами в автоматизацию (включая продление и замену), удобнее сразу заложить понятный жизненный цикл: выпуск, деплой, проверка и ротация. Для этого часто проще централизованно использовать коммерческие SSL-сертификаты и выдавать их в пайплайн по ролям и окружениям.
Как это выглядит в GitOps-пайплайне: практический шаблон
Независимо от того, Ansible это или Puppet, общий «скелет» зрелого процесса похож:
- Git как источник правды: код конфигурации, окружения, параметры.
- Проверки: линтеры, валидация синтаксиса, тесты ролей или модулей, проверка на утечки секретов.
- Промоут по окружениям: изменения проходят dev → stage → prod через merge или теги.
- Применение: либо push-runner, либо pull-агенты по расписанию или по событию.
- Наблюдаемость: отчёты по изменениям, алерты по дрейфу и ошибкам, журнал действий.
- Откат: через revert в Git и повторное применение, плюс (по возможности) атомарные деплои конфигов.
Ключевой момент GitOps: не «какой инструмент», а насколько последовательно вы заставляете изменения проходить через Git и воспроизводимые пайплайны.
Мини-шаблон репозитория (универсально)
Чтобы не смешивать окружения и уменьшить риск случайных изменений, старайтесь держать структуру «код отдельно, данные отдельно» и вводить понятные точки входа (inventory/environments). Примерная идея на уровне каталогов:
repo/
environments/
dev/
stage/
prod/
roles-or-modules/
ci/
docs/Даже если конкретная реализация будет другой, принцип один: из Git должно быть видно, что именно меняется, где границы окружений и как это будет применяться.
Таблица: быстрые ориентиры выбора
- Ansible: быстрый старт, понятный YAML, agentless, отлично для небольших и средних парков и задач «привести сервер к состоянию». Drift detection нужно проектировать процессом (регулярные прогоны, проверки, отчёты).
- SaltStack: сильнее в большом масштабе, быстрые массовые операции, event-driven подход, удобно для смешанных сценариев «конфиги + оперативное управление». Часто воспринимается как «платформа управления флотом».
- Puppet: сильная конвергенция и удержание состояния, контроль дрейфа через агентные прогоны, подходит для инфраструктур, где узлы живут долго и важен постоянный контроль.
- Chef: высокая гибкость и программируемость, но выше порог входа и требования к инженерной культуре (тестирование, стандарты, ревью).
Что выбрать в 2026: практичные сценарии
1) До 30–50 серверов, команда небольшая
Чаще всего выигрывает Ansible: вы быстрее придёте к результату и начнёте фиксировать инфраструктуру в Git. Главное — не скатываться в «shell-driven автоматизацию» и с самого начала продумать модель секретов.
2) Сотни серверов, нужна скорость и реактивность
SaltStack обычно чувствует себя уверенно: параллельность, событийная модель, гибкая оркестрация. Особенно полезно, если вам нужно не только «сконвергировать», но и выполнять оперативные действия по флоту.
3) Долгоживущие хосты и строгий контроль дрейфа
Puppet (и в целом агентная декларативная модель) часто удобнее, потому что «состояние удерживается» регулярными прогонами. Это проще объясняется аудиторам и внутренним политикам.
4) Сложные бизнес-правила конфигурации и развитая инженерная культура
Chef может быть оправдан, если вам нужна программируемость и вы готовы инвестировать в стандарты разработки cookbooks, тестирование и поддержку инфраструктуры.
Чек-лист перед внедрением (независимо от выбора)
- Определите модель: push или pull, кто имеет право применять изменения.
- Зафиксируйте базовые инварианты: пользователи, SSH, синхронизация времени, обновления, логирование, бэкапы конфигов.
- Опишите политику ручных изменений: запрещаем, разрешаем с фиксацией в Git, или допускаем только через emergency-процесс.
- Сразу заложите drift detection: расписание прогонов, режим проверки, отчётность.
- Секреты: отдельная стратегия, отдельный жизненный цикл, обязательное сканирование репозиториев.
- Тестируйте изменения до прода: хотя бы на одном стенде, лучше — на однотипном «канареечном» узле.
Итог
В 2026 году выбор между Ansible, SaltStack, Puppet и Chef — это не столько спор «что моднее», сколько выбор операционной модели: agentless vs agent, степень непрерывной конвергенции, требования к контролю дрейфа, и зрелость процессов вокруг GitOps. Если вы строите GitOps, то главный критерий успеха — дисциплина: всё меняется через Git, всё применимо повторно, всё наблюдаемо и откатываемо.
Для проектов, где важны предсказуемость и изоляция, часто имеет смысл держать окружения на отдельных серверах или отдельных пулах, а не «всё на одном». Если вы подбираете площадку под такую модель, проще всего стартовать с VDS для dev/stage и выделенных prod-узлов, а дальше уже наращивать процессы и автоматизацию.
