Системы централизованного контроля - что сейчас в моде?

шеф еще есть

как пишется? линк в студию!

http://en.wikipedia.org/wiki/Chef_(software)

Может пригодится: http://rexify.org/

на хабре salt хвалили, но я что-то пока не проникся

http://docs.saltstack.com/

Проникся, понравилось. Плагины писать просто и не нужно на все тачки тащить интерпретатор Ruby.

Пробовал pupet, сейчас хочу попробовать ansible. Общего у них нет ничего: puppet - это средства поддержания в актуальном состоянии, ansible - прошареный dsh.

Соответственно папет рулит если у тебя скажем 500 серверов в кластере, ansible - пока нигде особо не рулит ибо слишком молодой ещё.

Если выберешь папет, то будь готов к следущему:

• ruby, нет даже так RUBYYYYY!!!!!, будь оно не ладно.
• ssh на продакшен ты должен забыть. Навсегда. Все должно идти через папет, иначе будет боль, много боли.
• эту систему, похоже писали программисты ибо она очень крута и вылезана, но очень сложна для восприятия.

ssh на продакшен ты должен забыть. Навсегда. Все должно идти через папет, иначе будет боль, много боли.

я могу догадаться примерно, о чем может идти речь, но приведи, пожалуйста, примеры.

http://docs.saltstack.com/

Дочитал до

Easy enough to get running in minutes

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

Паппет устраивал во всех случаях жизни.

я остановился на ansible. во-первых питон и милые сердцу шаблоны, работая с джангой набил руку.
во-вторых товарищ, который пробовал паппет, сказал про ansible так: «Поставь ansible и о%уей от простоты!» (модеры, плз, я процитировал, не трите!) могу сказать следующее: он рулит. все, что мне нужно делать - он умеет. ставит софт, генерит конфиги с шаблонов, обновляет софт, выполняет команды, система нотификаций и обработчиков - читаешь, и хоть понимаешь о чем это. запилил ansible до состояния «поставить нужный софт и сгенерить нужный конфиг на группу серверов» за часов 5 вдумчивого чтения манов. а паппет - муть.

Боль в несогласованности. Если кто-то влез и руками что сделал, а ты потом написал что-то в папете в расчете на чистую систему...

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

а ты дальше почитай все же.

хреново масштабируется,

ты хоть слады что ль посмотри и в сторону ZeroMQ глянь.

при необходимости сделать что-то нестандартное портит админу жизнь

плагины на питоне пишутся очень быстро, очень быстро. Я через салт сделал плагин управляющий запуском контейнеров на ноде за 3-5 минут.

веб-интерфейс.

оно там есть? мне не нужно.

на ansible надо еще посмотреть.

Три основных системы контроля: cfengine3, puppet3, chef11.

Первый на сях, остальные два на ruby.

cfengine - конечно, в десятки раз отличается по ресурсам, его можно ставить в маленькие vds. разрабатывают его давно и он стабилен. самым большим его минусом являет дибильная концепция, придуманная лет десять назад какими-то теоретиками, а не админами. учиться настраивать его сложно, в том числе и из-за дибильного языка инструкций.

puppet - наиболее распространенная и самая простая в освоении. изначально делалась для администрирования, потому довольно практична. к сожалению, тоже пострадала от черезмерно концептуальнах девелоперов: например, нет встроенное возможности проверить «есть файл/нету файла». в остальном хороший компромисс между первой и последней.

chef - типичная пионерская поделка, создатели которой руководствовались следующими соображениями: на чем пионеры могут писать? Конечно же на ruby! И инструкции сделаем на ruby! Пусть остальные учат! Компилятор, гемзы, аутомейк - все это должно стоять в продакшн, чтобы запустить наш мегаклиент. Жирный клиент, жирная серверная часть. Но мы, пионеры, попробовали сделать на этом комерческий сервис и поняли, что все такое тормозное, что переписали ядро системы на erlang. Что, вы не знаете, как мигрировать с прошлой версии? Мы еще не придумали. Зато нас юзает facebook (отличиная презентация на сайте chef, в разделе, кто нас юзает). в этой презентации, кстати, видно, что в новой версии нагрузка упала в два раз, что говорит о качеств начального кода. В последней версии мы откзалась от использования пакетного менеджера вообще и теперь вы скачиваете с нашего сайта скрипт, который мы гордо называем «омнибус-пакетом» и он затягивает в /opt кучу скомпиленного софта: ruby, nginx, postgres, erlang ... все это само конфигурируется! т.е. сколько памяти найдем - все займем. и пофигу, если это виртуальный контейнер. мы, пионеры, самые умные!

zloelamo, см. пост выше. слава богу, что ее писали программисты. я тебя уверяю, бывает, гораздо, гораздо хуже:)

Я много думал про папет последний год. Пробовал, ковырял, но понял, что меня многое не устраивает. Если разложить по полочкам операции, то выходит, что в большинстве случаев достаточно либо сделать svn up и restart/reload, либо вызывать стандартную утилитку типа useradd userdel.

А вот шаблонирование, разворот из разных источников (тот же ldap или crm), нужно делать не на конфигугироемом узле, а на специально выделеной сущности. Тогда и бед не будет с производительностью и установкой.

Насколько я понимаю ansible прекрасный костяк для реализации этой парадигмы.

Ежу понятно, что я не в mail.ru работаю и серверов у меня не 100500, а порядка сотни виртуалок.

А вот шаблонирование

Впрочем в папете так и сделано, но результирующую конфигурацию нормально видно только на конфигурируемом узле, а по мне лучше бы она была в svn в готовом виде.

ansible шикарен. я всего сутки с ним знаком а уже тащусь ))

я не претендую на знатока, но: довелось попробовать >10 разных систем (в т.ч. проприетарных и не считая двух-трех самописных), в продакшене, на тысячах серверов. так вот. про чеф, паппет и тем более цфэнджин забудте сразу, если делаете новый деплоймент. я понимаю, что cm трэнд только сейчас до многих предприятий докатился, но это уже прошлый, и даже позапрошлый день. это как апач среди веб-серверов - вроде и работает, но причин выбрать его для нового внедрения практически нет. лучше берите салт или ансибл, что вам больше нравится. ни одно из проприетарных или вендор-локин решений посоветовать не могу - и даже вовсе не по религиозным причинам, а по чисто техническим.

ну раз вы тут все в один голос говорите про этот ansible, то почему бы его и не попробовать на тесте.) тем более питон. но мое имхо, что в продакшн лучше внедрять то, по чему уже книжки на амазоне продаются, а на офсайте лежат pdf и success story.

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

угу. это до первой сложной конфигурации, когда он перестанет делать то, чего ты ждешь, и ты начнешь его ненавидеть:)))

будет многабукаф. может как-нибуть в блог напишу.

Не люблю саксесс стори, как было написано в той знаменитой сатье про php «достаточно умные люди могут осилить все что угодно». Я предпочитаю читать статьи наполненые болью и отчаиньем, во-первых, из садистких побуждений, а во-вторых, чтоб грабли посмотреть.

Ну это, думаю справедливое замечание - если надо организовать шареный хостинг, или кластер под крупный сайт, то папет будет оптимальным выбором, поскольку, по большому счету ты именно результат работы папета и будешь продавать.

Но если, как у меня, имеется заопарк, в котором повторяется не более 50% конфигураций, то более простой инструмент будет более удобным.