Комментарии 23
А какую проблему он решает?
Прочитал статью, удивился некоторой путанице. Я не беру на себя смелость решать, что именно должно использоваться вами, другое дело, что факты поданы, гхм, своеобразно. Вот по порядку:
Во-первых, меня смутило, что в описании «что и почему» в пользу Salt указаны фичи, имеющие прямые аналоги у Ansible.
Во-вторых, если уж говорить о коммерческих решениях, то утверждение про якобы несуществующего клиента для Ansible оказывается на поверку весьма слабым: клиент очень даже существует и называется Ansible Tower .
В-третьих, Ansible тоже написан на Python.
В-четвёртых, совсем не был упомянут Ansible Galaxy — открытый свободный репозиторий ролей для Ansible, где очень часто можно найти необходимую роль, и она будет работать «из коробки», либо с минимальной подгонкой под ваш конкретный проект.
Ну и в-пятых — документацию к Salt, по ощущениям, действительно писала парочка — Шляпник и Мартовский Заяц, так что она явно проигрывает официальной документации Ansible.
P.S. Стаж использования Ansible — больше 2-х лет.
Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?
Мы сейчас задумываемся о внедрении системы управления окружением, но больше смотрим в сторону Chef.
Chef кажется довольно продвинутым и гибким решением.
Chef — на Ruby: https://github.com/chef/chef
Поэтому я и написал:
Помимо того, что он тоже не «на питоне» были еще какие-то аргументы?
Насчет Puppet хотябы был аргумент:
входной порог для старта работы с продуктом был достаточно высоким из-за сложной логики описания сценариев развертывания окружения.
а про Chef ничего не сказано.
Выбор SCM подобен выбору редактора. У каждой компании свои потребности.
Рекомендуем попробовать несколько вариантов и выбрать “свой”, который будет покрывать ваши хотелки.
В момент выбора решения, прежде всего я руководствуюсь требованиями, но обращаю внимание на восприятие продукта — нравится\не нравится, которое сновано на эмоциях, т.к. дальше с этим работать, развивать и поддерживать.
Chef и CFEngine не стал смотреть, причина — язык и вышеупомянутое ощущение — «не того».
Выбор был между Ansible и Salt. Остановились на том что устраивало по функционалу и понравилось :)
Мне было с Salt'ом проще, т.к. до этого поработал с Ansible.
В Ansible действительно не pull- а push-топология. Не клиенты «тянут» конфигурацию с мастера, а мастер «проталкивает» её на клиенты. Но это само по себе не плохо — это просто одна из двух топологий, у которых есть свои достоинства, недостатки и область применения. Что Saltstack может так и так — отлично.
Предполагаю, что вам было необходимо или просто более эффективно использовать топологию с мастером и клиентами. Расскажите, для каких именно задач? (Ничуть не сарказм, искренне интересуюсь).
[Ansible] Не подошел из-за отсутствия клиента — пробовали его до выхода второй версии
Клиент, о котором вы говорите, это ansible-pull?
ansible-pull очень простой, по сути это git pull && ansible-playbook local.yml
. Насколько я понимаю, у salt minion возможностей гораздо больше.
Кстати, ссылка на топик-анонс в конце наверняка неправильная, т.к. в том посте такая же ссылка на вот этот топик: https://habrahabr.ru/company/pt/blog/310584/
Инструменты DevOps: Чем хорош SaltStack, и какие задачи с его помощью можно решить