SaltStack vs Ansible

Содержит частичное переизложение отрывков из поста https://habr.com/ru/post/549874/

В большинстве случаев, работая с распределенными системами мы хотим выполнять операции в определенном порядке.
Например поставить некие системные пакеты и запустить сервис на хосте А, дождаться пока сервис станет доступен и только потом запустить сервис на хосте Б, который зависит от сервиса на хосте А.
Это и называется оркестрацией.

Ansible

Оркестрация это очень мощный инструмент и Ansible весьма хорошо ее поддерживает.
По умолчанию Ansible запускает каждую задачу последовательно (на одном или множестве хостов), ждет ее выполнения и только потом приступает к следующей.

Это очень медленно, но позволяет Ansible работать с данными полученными в реальном времени.
Например:
- Запустить Mysql,
- Загрузить в него некие данные,
- Сделать в него запрос и сохранить ответ как переменную,
- Использовать значение этой переменной в последующих задачах

В любой момент времени, Ansible можно сказать выполнить определенную операцию на другом хосте, даже если изначально этот хост не входил в список хостов для выполнения.
Так же, Ansible поддерживает идемпотентность - свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом.

Эти три возможности (модификация данных по ходу выполнения программы, делегирование исполнения и идемпотентность) позволяют создавать очень сложные оркестрации, способные покрыть множество сценариев.

Главный минус - это все происходит очень медленно из-за необходимости постоянной синхронизации выполнения с Ansible контролером и из-за изначально медленного протокола коммуникации.

SaltStack

SaltStack так же позволяет запускать определённую логику на определенных хостах, но как только выполнение было начато, вы уже никак не можете на него повлиять.

Главная причина - асинхронный подход и просчитывание графа выполнения до выполнения.
Ansible может поменять ход исполнения посреди логики, более того он в принципе не в курсе, что будет дальше чем то, что он делает прямо сейчас.

SaltStack просчитывает все наперед что позволяет работать быстрее, но теряет в гибкости.
Зато оператор может получить граф исполнения до исполнения и сверится с тем что это именно то, что он бы ожидал.

SaltStack пытается исправить это неудобство и предлагает решение которое называется slots.
Slots позволит получать некую информацию и принимать по ней решение прямо перед выполнением логики. Это все еще далеко от гибкости Ansible, но это первый шаг.

По словам одного из экспертов, ему удалось заставить salt работать на 10к+ машин.
Для этого пришлось переключиться на salt-ssh. Использование мастеров-миньонов было бесконечной болью с крэшами как мастеров так и миньонов. Заставить это работать надежно не удалось. С другой стороны salt-ssh с грехом пополам тянул всю инфрастуктуру.

Imperative vs Declarative

Ansible утверждает что он декларативный инструмент для управления конфигурацией.
Это лишь наполовину правда. В Ansible множество 100% декларативных модулей, но в нем так же огромное количество императивных модулей, например как uri.

Такие механизмы как register, when, changed_when, failed_when в Ansible поддерживают эти идею и позволяют делать идемпотентность и условную деларативность через императивные инструменты.
Отчасти это очень мощный и гибкий инструментарий позволяющий делать плюс-минус все что угодно без навыков програмирования.

Минусы этого подхода перевешивают плюсы в долгом забеге.
Так же Ansible не гарантирует что все его модули идемпотентны и предлагает те же самые инструменты что бы обойти эту проблему.
Это ведет к ухудшению читаемости и поддержки логики.

SaltStack явно разграничивает императивные и декларативные модули.

Execution modules: императивны и не идемпотентны. Они написаны на процедурном языке и содержат плоское описание действий.
State modules: декларативны и идемпотентны. Они приводят систему в определенное состояние описывая финальный результат.
Технология и последовательность действий для достижения результата не изложена, как а Terraform.

В SaltStack почти невозможно сделать цепочку модулей исполнения что бы они притворились идемпотентными и декларативными.
Вместо этого предлагает писать свои модули состояния.

Аргументы в пользу Salt

  1. Возможность удаленного выполнения, инициируемого со стороны клиента, при обращении от клиента к серверу – двухстронний обмен. Это дает нам ключевую возможность - не организовывать прямой доступ от сервера автоматизации до клиента через клиентские роутеры.
  2. В отличии от Ansible, который работает исключительно через SSH и инциацией только от центрального сервера, Salt использует самое быстрое и эффективное что было на рынке для транспорта - ZeroMQ. Позже инженеры из Linkedin добавили возможность работы через raw tcp.
  3. Скорость работы SaltStack была изначальной целью заложенной в дизайн приложения. Идея заключается в том что Salt Master общается с Salt Minions(далее Мастер и Миньены) через publish/subscribe модель, где мастер публикует задачу, а миньены принимают ее и асинхронно выполняют.
  4. Масштабируемость - Saltstack имеет конфигурацию из нескольких мастеров. Если один мастер по каким-то причинам не работает, подключаются другие мастера агентами списка. Это помогает Saltstack работать непрерывно.
  5. Saltstack поддерживается в Github, а Ansible - в Red Hat. Т.о. этот проект на данный момент меньше подвержен санкционным рискам.
  6. У Saltstack есть клиентский API Python для пользователей, использующих программное обеспечение с открытым исходным кодом. Для корпоративных пользователей предлагается REST API. Кроме того, REST API предлагается в ограниченной версии для пользователей с открытым исходным кодом, а у Ansible этого нет.
  7. Saltstack лучше интегрируется с облачными провайдерами.
  8. Скорость больше по сравнению с Ansible, так как он работает с шиной обмена сообщениями, и информация передается оперативно.
  9. Saltstack прост в установке и не занимает много ресурсов. Часть вычислительной нагрузки возлагается на клиентский ПК.
  10. SaltStack может легко подключаться к другим системам, чтобы получать любые данные, необходимые для настройки.
  11. Функциональность reactors и engines позволяют делать очень интересные решения вроде реакции на события на вашей системе или построения своего сервиса поверх SaltStack.
  12. C Salt у вас либо есть подключение либо нет, и если оно есть то все будет работать. Открыть надо два порта в одну сторону. Работает за натами и прочим.

Аргументы в пользу Ansible

Условно, ansible способен прорваться на любой хост.
У каждого сервера свой номер порта, и IP’шник, который плавает?
Без проблем, динамическое инвентори твой друг.

Транспортный уровень ансибла медленный, но работает надежно.
Есть ssh и питон - ансибл работает. Есть ssh - ансибл работает, но не так удобно.
Ни одна система управления даже близко не подошла к этому уровню универсальности.

Выводы

Главное преимущество Ansible на сегодня это предельная простота и гибкость оркестрации. Этот инструмент хорошо подойдет командам с небольшим количеством обслуживаемых хостов (до сотни) и/или для команд без сильной инженерной экспертизы.
Ansible как никто другой приблизился к идее о no-code configuration management.

Но как-только вы вырастаете из этой простоты - Ansible становится сильно сложнее и менее удобным, чем вы бы ожидали.

Отладка становится мучением, время выкаток увеличивается экспоненциально и вы начинаете регулярно наступать на различные мины вроде того что any_erros_fatal не остановится на падении первого элемента в цикле, а доведет его до конца прежде чем вернуть ошибку и тп.
И большая часть примеров логики в интернете будет полна “Программирования на Ansible” которую вам придется поддерживать.

Спустя несколько лет использования SaltStack я пришел к выводу что Ansible это инструмент, а SaltStack это фреймворк.
Вам придется погрузиться чуть глубже, но есть что-то невероятно прекрасное в замене 10 тасков на bash. на один хорошо написаный модуль состояния.