Зачем нужен Puppet/Ansible, если есть git по крону и bash?

Просто в головах погромистов не укладывается, как это программа в одну строку)

Эти все штуки написаны для работы виндовс-админами в условиях гетерогенных сетей. Чтобы все одинаково по кнопке, и не особо вникая. И сразу на 1000 серверов. И процесс использования таких штук уже сложился. И многим проще быть в струе чем использовать какое-то старьё или что-то, что есть не везде и не всегда.

Перепись админов локалхоста.

Вот это все будете тоже костылять через bash+git+cron? https://docs.ansible.com/ansible/latest/modules/list_of_all_modules.html

Всё! Этого достаточно! Вся программа в одном русским языком предложении.

Нет.

Может я что-то недоПОНИмаю...

Да.

https://docs.ansible.com/ansible/latest/modules/iptables_module.html#iptables...

такого рода модули напоминают мне шаблонизаторы на PHP вида %username%, в каком-то смысле их достаточно, скажем, чтобы я прямо сейчас %username% превратил в MadMax, для динамического контента в статичном сообщении, так сказать. это да, ок.

нооо, я скажу вам такую мысль, что больше чем умеет сам язык программирования в своём шаблонизаторе ты не реализуешь, тобишь, ощутимая часть этих модулей спокойно заменяется одним единственным рутшеллом на bash. зачем заново изобретать велосипед, заново описывать целиком все параметры iptables, если попросту можно дать доступ к консоли и уже там проводить махинации с iptables напрямую? и так — большая часть этих полезных, но откровенно говоря не нужных модулей.

далее, модули типа jabber и irc которые позволяют отправлять сообщения, так же полезны, но и они существуют в виде уже готовых консольных утилит, в т.ч. и на pure bash. и снова возвращаемся к тому, что даём доступ к консоли и пускай админ сам делает в ней что хочет, отправляет сообщения sendmail'ом или куда ему там надо.

в первую очередь необходимо предоставить всю мощь консоли пользователю.

а вот реально полезным модулями я бы назвал всякие Azure, Cloud'ы и прочее, общение с которыми происходит через API и вот тут действительно у админа нет времени на изучение кухни изнутри у всех этих сервисов. это да.

https://habr.com/post/343644/#comment_10722198

И многим проще быть в струе

Не «в струе», а «под струёй».

в первую очередь необходимо предоставить всю мощь консоли пользователю.

На всех сотнях серверов, угу.

такого рода модули напоминают мне шаблонизаторы на PHP вида %username%

Ты бы сказал сразу, что ты PHP-шник.

Чего же ради создавать все эти > Конфигурация описывается на специальном декларативном предметно-ориентированном языке.

Допустим, я хочу что-то типа «когда изменился конфиг в /etc/nginx/site-enabled, сказать демону nginx перечитать конфигурацию». И чтобы было идемпотентно и работало на redhat и debian, на sysVinit и systemd. Как бы вы реализовали такую задачу на баше?

Дык этот ваш ансимбл такой же набор костылей и подпорок, просто они спрятаны чуть ниже. Просто это готовая хрень заточенная на массовые изменения конфигов. Применяются самые наивные, простые и тупые способы, вплоть до брутфорса. Народу просто так проще - крутить всё вокруг одной новой софтины. То, что до ансимбла было вагон старых, даже коммерческих решений, с демонами, c распределенной архитектурой, и тп. никто не помнит, у народа память коротка. Применяется обычно не самое эффективное решение, а самое известное.

Плюсом ансимбла является то, что он обычно работает. Самое главное не заглядывать под капот. И очень популярен у виндовых админов, вынужденных поддерживать гетерогенную сеть. Поэтому достаточно отдать плейбук и они смогут всё сделать как тебе надо, а если по ssh и объяснять, то так всё всегда будешь делать сам.

Что вы привязались к ансиблу. Это обвязка к питону, запускающаяся через ссш. С учетом что питон идёт дефолтом в рхеле и дебе, минимум оверлоада. Ругайте папеты—чефы , эти монстры на руби, да ещё с какими то серверами, вот где треш -)

кто твой говнокод то поддерживать потом будет после тебя? В ансибл много кто может, а вот твои башики разгребать..а если у тебя прод больше чем из одной машины, то это ж вообще ад будет.
А вообще, если у тебя такие вопросы возникают, то у тебя нет проблем и тебе ансибл никакой не нужен.

Да я не ругаю. Софтина как софтина. Я просто не понимаю чего у молодых админов такой жесткий стояк на неё. Я считаю это не слишком заслуженным хайпом.

Что же касается папета и прочего - там вроде цели были немного другие - там прямое окучивание недоэнтерпрайзной ЦА с возможностью отхватить некоторый энтерпрайзный профит. В принципе понятно и внушает уважение. Плюс местами архитектура даже есть. Знавал людей которые занимались виртуалководством на папете дабы вообще не вникать что там и как. Окучили их хорошо, да. Но с таких взять совсем не грех, не хочешь думать - плати, очень логично и правильно. В другом окружении оно особо смысла не имеет.

Ансимбл однако в этом плане таки может быть полезен девелоперу в ситуации, когда «почему вчера не задеплоил?» и можно переложить ответственность. Остальные (Puppet/Chef) требуют некоторой инфраструктуры и определенного образа мыслей. Иначе они просто не интегрируются в процесс.

Зачем нужен Puppet/Ansible, если есть NixOS и NixOps?

Так правильно.

Допустим, я хочу что-то типа «когда изменился конфиг в /etc/nginx/site-enabled, сказать демону nginx перечитать конфигурацию». И чтобы было идемпотентно и работало на redhat и debian, на sysVinit и systemd.

Ну я бы для начала снес редхат...

Зачем нужен Puppet/Ansible, если есть git по крону и bash?

Я тебе даже больше скажу, очень часто в папет и ансибл файлах полно портянок на баше

Штоб было интырпрайзненько.

когда таких однострочников МНОГО начинается ЖОПА

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

Технически вы правы, только ансибл уже готов,сделан, протестирован и задокументирован. Для решения тех же проблем вы могли бы переизобрести ансибл/сальт/puppet/chef на bash. Но зачем?

Плюсом ансимбла является то, что он обычно работает. Самое главное не заглядывать под капот.

У него под капотом хоть нормальный ЯП, а не баш какой.

Зачем останавливаться на пол пути? Пишите сразу «господин начальник, прошу уволить меня по собственному желанию».

Я тебе даже больше скажу, очень часто в папет и ансибл файлах полно портянок на баше

К сожалению, порка на конюшне запрещена ТК РФ.

Как бы тебе сказать...

Может я что-то недоПОНИмаю...

Ты реально недо пони маешь. Вместо того, чтобы использовать готовый инструмент, заточенный под задачу, ты будешь городить костыли на чистом bash. Ну это как для экономии ресурса трактора обойтись безотказной лопатой

Чисто по приколу, как бы ты создал пользователя с заданным паролем и профилем? Или, например, внёс заданные изменения в конфиг ssh сервера

Кстати, сервер в числе прочего отслеживает статус клиентов. Буквально - когда кто последний раз запросил конфиг и успешно его применил

Ну вот тебе простая задачка:

вот есть у нас 8 одинаковых условных web-серверов, которые находятся за условными парой зарезервированных балансировщиков (haproxy или nginx или что-то еще, не суть важно). Понадобилось нам добавить еще пару web-серверов. Если мы используем ansible, то после установки серверов мы просто добавляем в инвентарь имена этих новых серверов, запускаем плейбук и идем пить чай. После распития чая мы обнаруживаем, что два новых сервера уже сконфигурированы точно так же как и восемь других, а балансировщики уже о них знают и даже направляют запросы.

Решая эту задачу на ансибле мы получим простой и понятный код, а на баше - лютые портянки с sed'ами и прочей нечитаемой мутью.

Логика такая:
1. Если тебе нужно просто обновить конфигурационный файлы - да, можно выкладывать в git и потом забирать, как ты сказал.
2. Предположим, что теперь тебе нужно не конфиг обновить, а, например, запустить апдейт пакета. Это запуск команды по какому-то триггеру. Пока всё ещё ничего сложного, но, заметим, это второй твой скрипт в библиотеке.
3. А теперь тебе нужно не просто скопировать файл на машину, а с каким-то изменением, которое уникально для каждой машины. Тоже скриптик или однострочник, но с одним исключением: его нельзя запускать дважды. То есть нужно проверить, а есть ли нужное изменение уже на машине, и, если нет - произвести его. И это уже третий скрипт в библиотеке.
4. А теперь у тебя таких скриптов под сотню, и на разных машинах нужно запускать различные комбинации скриптов.

Ansible позволяет:
1. Писать скрипты автоматизации конфигурации хостов для тех, кто не очень знаком с bash/python/регулярками/git/... и т. п.
2. Репозиторий-библиотеку «скриптов» + возможность формировать различные «подборки» для конкретной задачи / конкретного типа хоста - playbook (если не ошибаюсь), например, сконфигурить WEB-сервер с нуля.
3. Framework, который обеспечивает выполнение «скрипта» только в том случае, если изменение нужно. То есть гарантию того, что повторный запуск playbook'а ничего не поломает.
4. Легко применять конфигурацию на большом количестве машин.

Ну, то есть ты всё это можешь сделать на bash/python. Но тут у тебя есть готовый framework + из коробки библиотека типовых скриптов + единый механизм как это менеджить. Ну, и не забываем про тех, кто не силен в скриптах, но хочет чувствовать себя супер-админом.