System administration
Puppet
Comments 40
+1
Отличный инструмент, использую в продакшне уже больше года, сначала была проблема с нехваткой модулей, но сейчас почти все нужное уже написано. Из плюсов могу отметить легкость написания своих модулей, и легкость продвижения их в апстрим. Я сам написал парочку модулей, и один чужой модуль патчил — все изменения приняли в апстрим очень быстро. Ну и декларативность описания всего позволяет читать хорошо написанные плейбуки как английский текст — это супер.
+1
Сейчас стоим на пороге внедрения системы управления конфигурациями, и выбираем инструмент.
Глянул на ansible в гитхабе — 767 репозиториев, а про puppet — за 10 тысяч.
Подскажите на это стоит обратить внимание? Или в ansible важно другое?
Просто разница в количестве кода колоссальна.
+1
Я как-то не особо понял что значат репозитории на гитхабе для системы управления конфигурациями. Вы имеете ввиду что мало людей используют? Или что негде посмотреть как используют? Ну у ansible есть отличная документация. А используют ansible такие компании как evernote.
К тому же ansible заметно выигрывает у puppet за счет простоты написания и читания конфигов. Это очень важно.
0
Количество репозиториев на гитхабе обозначает большое количество разных написанных модулей для системы.
Я про это.
Вы же не будете расписывать настройку LAMP каждый раз сами, а один раз выложите модуль на гитхаб и будете им пользоваться.
0
Эм. Настройка ламп делается через роль LAMP, которая включает в себя роли:

разворачивание сервера в амазоне
установка и конфигурирование через template — apache
тоже для mysql
тоже для php

Суть в том, что вместо использования готовых модулей намного легче написать свою роль, используя модули ansible. К тому же так можно сделать отличную подгонку под свою же инфраструктуру.
Например, я, в зависимости от того какая виртуализация, какая роль у сервера, что на нем стоит выставлял разные конфиги у collectd просто редактируя template и передаваемые при инклуде роли переменные.
0
Я в свое время перешел с Chef на Ansible именно из-за простоты написания/чтения задач, и декларативности. Если у вас не стоит задач управления динамично меняющейся средой, навроде облака серверов — Ansible позволяет решать задачи заметно проще. Ну и agentless работа по ssh это тоже очень круто.
0
К сожалению (или к счатью), наша среда крайне динамична и гетерогенна.
0
Тогда посоветую Chef, он создавался именно для этого, учтя все недостатки puppet. В Chef есть и заморозка версий, и databags, и environments, и главное — сервер знает все о своих нодах, т.е. можно строить конфиг с использованием этих знаний. В Ansible тоже есть знание о нодах в playbook, но конечно этого будет мало для серьезной динамики.
0
Ну вообще-то не так. ansible умеет инклудить в свой же inventory, может работать с списком хостов в группе, может прописывать дополнительные переменные для отдельных хостов. Я собственно, кроме заморозки, которая решается исключением хоста из группы и включением его в другую группу, ничего особого и не вижу.
Хотя с гетерогенностью в ansible все действительно не особо гладко.
+1
Да я знаю, что может. Но в Chef это сделано удобнее, ну и если в Chef не использовать чужие cookbook, которые в основном жуткий императивный говнокод, то можно добиться хороших результатов по читаемости и понятности, сравнимых с Ansible. Для каждой задачи надо выбирать наиболее подходящий инструмент. До определенного уровня задачу проще решать с помощью Ansible, после — с помощью Chef.
0
Полностью соласен. Но по вопросу мне показалось что как раз готовые кукбуки и будут использоваться.
А самописные кукбуки на чефе очень крутые, но никто их не пишет, так как это достаточно сложно. Потому ansible и лучше :)
0
То есть я хочу сказать что лучше тот инструмент, который в принципе может немного меньше, но менее запутанный. И лучше он потому что им будут пользоваться и писать. В то время как чеф очень часто состоит из нескольких стандартных кукбуков апача, nginx, mysql и все.
0
Тут зависит от инфраструктуры, для жесткой — удобней декларативный инструмент, я вот когда первый раз документацию по puppet читал чуть мозг не сломал, но это может только у меня так.
-4
Обратите внимание на CF-Engine. К моему глубокому сожалению, это на текущий момент единственный вменяемый инструмент управления конфигурациями. Ни Puppet, ни Chef, ни Ansible, к ещё более глубокому сожалению, не приспособлены для задач серьёзнее, чем «склонировать очередной LAMP» и «git clone this there».
0
Опишите в чем преиущество? Насколько сложно в нем решать типовые задачи? А нетиповые?
Идеальный вариант ответа — отдельный топик :)
0
Преимущества ровно два: отсутствие зависимостей и pull вместо push.
0
В режиме pull умеют работать все вышеперичисленные. Или вы что то другое в виду имели?
0
Кстати, я cfengine смотрел, но не увидел в нем ничего особенного. Ansible, как и шеф, как и паппет умеет все — включая выполнение баша и команд с регистрацией exit статуса и дальнейшими действиями по ситуации.
0
Наверное нужно всё же определиться какую именно проблему мы пытаемся решить. Если нам нужно полностью автоматическое конфигурирование сервера, при чём так, чтобы последнее действие сделанное живым человеком было «вынуть загрузочную флешку» — вариантов без CFEngine нет совсем, а с ним это превращается в нетривиальную задачу. Если же нужно создавать виртуалки на амазоне для очередного социального облачного стартапа, то можно обойтись и скриптом на баше.

Хочу отдельно отметить, я не осуждаю ничей выбор. Реальность такова, что где-то задача с трудом решается только одним средством (и это очень, очень печально), а где-то задача решается чем угодно.
+1
Я, конечно, не знаю, что какая у вас задача решается. Но у меня в полностью автоматическом режиме с голой ОС разворачивается довольно сложный проект с riak, redis, postgresql, rabbitmq, haproxy и nginx. И все это автоматом собирается в кластер. И задача эта решена без особых мучений с использованием только Ansible. И более того — я больше года работал с Chef, и точно знаю, что с его помощью подобная задача решается ничуть не сложнее, просто чуть более трудоемко. Так что я сомневаюсь, что CFengine в чем-то превосходит chef, ansible или puppet. Напишите статью, покажите его супер-возможности, а мы сравним.
0
Задача простая: есть сервер без ничего вообще, загрузочная флешка и условная обезьяна, которая умеет засунуть сервер в стойку, засунуть флешку в разъём и нажать на кнопку «Вкл». Нужно получить сервер, роль которого уже предопределена где-то в глобальной базе всех серверов. С учётом аспектов безопасности.
0
можно обойтись и без обезьяны:
В рамках одной сети это решается нетинсталом.
Если это не одна сеть — можно посмотреть на vagrant, например.

Если нужна обезьяна, то можно посмотреть в сторону preseed файлов, например.

В любом случае, если бы подобную задачу поставили мне я бы смотрел в сторону netinstall и назначения роли по имени сервера.

0
Без обезьяны невозможно. Сервер сам по себе в стойке не материализуется. Без preseed тоже невозможно. Сети очень разные. Разные континенты, города, датацентры, по всему миру. Netinstall не работает.

Про Vagrant хотелось бы послушать подробнее. Каким образом это поделие способно засетапить железку. Мне действительно очень интересно, возможно я что-то пропустил и не догоняю теперь.
0
Главная проблема всё та же: внешние зависимости. Лично меня ещё не устраивает RedHat-ориентированность, но тут уж на вкус и цвет товарищей нет. Выбирая между Cobbler и Ansible, выбор однозначно в пользу скрипта на баше Ansiblе.
0
Если бы CFEngine управлял ещё и людьми, счастье было бы очень близко. Но нет.
0
Спасибо.
Не в курсе, насколько он хорошо работает с FreeBSD (установка пакетов, управление пользователями — всё имеет несколько специфичный для линуксовых програм вид)?
0
C freeBSD он работает очень так себе. Собственно я в свое время ограничился заведением пользователей и установкой программ через pkg_add -r — там где он работал. Но вообще — все не очень хорошо, но можно самому написать модули и поделиться с сообществом. Все будут только благодарны.
-1
Жаль. Хотелось найти какое-то уже более-менее работающее решение.
0
Спасибо, очень приятная статья. Как раз руки дошли до ansible.

У меня вопрос, никак не могу набрести на кошерное решение, как получать значения хостов и плейбуки динамически с VCS? В принципе нет проблемы сделать скрипт, который пуллит изменения из репы и потом запускает выполнение плейбука, но пахнет не кошерно :)
0
А кто-нить пробовал в playbook воткнуть что-то на подобии:
ps ax|grep bin/post|grep -v grep|awk '{print $NF}' | awk -F '/' '{print $5}'

? Как использовать пайпы в комманда в playbook?
0
Попробуйте всю команду взять в кавычки:
command: bash -c "ps ax|grep bin/post|grep -v grep|awk '{print $NF}' | awk -F '/' '{print $5}'"

Если не поможет, то засунуть в файл и дергать файл из playbook'а.

З.Ы. вряд ли Ваш вопрос еще актуален :)
+1
Ну, в общем, да, такое нормально передаётся. Но всё равно это надо вызывать специальным модулем shell, а не подпоркой.
Only those users with full accounts are able to leave comments.  , please.