Здесь довольно тяжело сделать обьективное сравнение. Т.к. каждый инструмент предназначен для решения своих задачь и сравнение "в лоб" неизбежно обречено на провал. Также, тема весьма обширная, и для обьективного сравнения очень неплохо бы одинаково хорошо знать все используемые инструменты, что в жизни почти недостижимо.
Считаю, что в первую очередь нужно определиться с целями, что и для чего мы делаем, а дальше выбирать инструменты, наиболее эффективно отвечающие достижению поставленных целей.
Если рассматривать configuration management с методом push over ssh, то здесь на текущий момент дефакто два лидера — Ansible и Saltstack.
Причем первенство с большим отрывом держит Ansible. У него вся документация, примеры и сценарии применения заточены под Push метод.
Фундаментальное отличие на мой взгляд одно. SaltStack использует Jinja и для шаблонов и для логики стейтов. Это значит что Jinja выполняется перед самим state. (Saltstack изначально ориентирован на Master-Slave режим работы, поэтому такое поведение рационально).
Эта особенность является одновременно и сильной и слабой стороной SaltStack.
Сильной, т.к. позволяет строить продвинутую логику.
Например, в цикле обработать несколько state и на их основе сгенерировать данные для другого state.
Допустим, у каждой роли есть свои настройки firewall. Jinja при запуске видит все эти роли и собирает итоговые переменные для роли фаервола. В результате получается довольно красиво и элегантно. Но, плата за сиё — избыточная сложность и, зачастую, меньшая прозрачность.
В ansible концептуально другой подход. "Только одни переменные, только в одном месте" ( variable-precedence-where-should-i-put-a-variable ).
Есть, конечно, хаки в духе hash_behaviour=merge, но они не рекомендуются к использованию.
С ansible проще начать. Больше сообщество и, как следствие, больше написанных ролей, которые можно повторно использовать.
Он лучше подходит для небольших энвайроментов. Мне очень нравится последовательное выполнение таска в сочетании с register.
Благодаря этому довольно просто реализуются развертывания в различных Cloud providers а также выкатавания апдейтов ПО: guide_rolling_upgrade.
Да и вообще это как старый добрый shell на стероидах.
Субьективно, нишевая область применения SaltStack это, всё таки, Master-Slave режим работы. А Salt-ssh — просто удобное дополнение к последнему, которое можно использовать и само по себе. Возможность же быстро переключаться между режимами работы — это тоже, однозначно, сильная сторона SaltStack.
Вообщем, на мой взгляд сильные и слабые стороны не существуют сами по себе в отрыве от контекста, решаемых задачь и поставленных целей. Это очень важно учитывать при выборе системы управления конфигурациями.
Здесь довольно тяжело сделать обьективное сравнение. Т.к. каждый инструмент предназначен для решения своих задачь и сравнение "в лоб" неизбежно обречено на провал. Также, тема весьма обширная, и для обьективного сравнения очень неплохо бы одинаково хорошо знать все используемые инструменты, что в жизни почти недостижимо.
Считаю, что в первую очередь нужно определиться с целями, что и для чего мы делаем, а дальше выбирать инструменты, наиболее эффективно отвечающие достижению поставленных целей.
Если рассматривать configuration management с методом push over ssh, то здесь на текущий момент дефакто два лидера — Ansible и Saltstack.
Причем первенство с большим отрывом держит Ansible. У него вся документация, примеры и сценарии применения заточены под Push метод.
Фундаментальное отличие на мой взгляд одно. SaltStack использует Jinja и для шаблонов и для логики стейтов. Это значит что Jinja выполняется перед самим state. (Saltstack изначально ориентирован на Master-Slave режим работы, поэтому такое поведение рационально).
Эта особенность является одновременно и сильной и слабой стороной SaltStack.
Сильной, т.к. позволяет строить продвинутую логику.
Например, в цикле обработать несколько state и на их основе сгенерировать данные для другого state.
Допустим, у каждой роли есть свои настройки firewall. Jinja при запуске видит все эти роли и собирает итоговые переменные для роли фаервола. В результате получается довольно красиво и элегантно. Но, плата за сиё — избыточная сложность и, зачастую, меньшая прозрачность.
В ansible концептуально другой подход. "Только одни переменные, только в одном месте" ( variable-precedence-where-should-i-put-a-variable ).
Есть, конечно, хаки в духе hash_behaviour=merge, но они не рекомендуются к использованию.
С ansible проще начать. Больше сообщество и, как следствие, больше написанных ролей, которые можно повторно использовать.
Он лучше подходит для небольших энвайроментов. Мне очень нравится последовательное выполнение таска в сочетании с register.
Благодаря этому довольно просто реализуются развертывания в различных Cloud providers а также выкатавания апдейтов ПО: guide_rolling_upgrade.
Да и вообще это как старый добрый shell на стероидах.
Субьективно, нишевая область применения SaltStack это, всё таки, Master-Slave режим работы. А Salt-ssh — просто удобное дополнение к последнему, которое можно использовать и само по себе. Возможность же быстро переключаться между режимами работы — это тоже, однозначно, сильная сторона SaltStack.
Интересная, хоть и слегка устаревшая статья на эту тему: Moving away from Puppet: SaltStack or Ansible?
Вообщем, на мой взгляд сильные и слабые стороны не существуют сами по себе в отрыве от контекста, решаемых задачь и поставленных целей. Это очень важно учитывать при выборе системы управления конфигурациями.