LINUX.ORG.RU

Puppet: в шкуре кукловода. Часть 1

 , ,


0

0

Начало цикла статей о системе управления конфигурацией Puppet. В первой статье рассказано что такое Puppet и как он работает. Так-же рассказано о возможных способах установки, проверки работоспособности и первоначальной настройки сервера и клиента.

В следующих статьях будут даны примеры конфигурирования, рекомендации по организации рецептов, а также описание утилит входящих в состав Puppet.

>>> Подробности



Проверено: maxcom ()

Почему не подтверждается? как показала жизнь, вешь нужная, куда более чем «новый список Top500» :)

fi ★★★ ()

мнение

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

zerot ()

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

Laz ★★★★ ()
Ответ на: мнение от zerot

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

Я уже наелся этих «скриптов по ssh», управлять всем этим не очень то просто, а передавать потом такое хозяйство преемнику и вовсе невозможно.

В Puppet`е четко определены стандарты описания ресурсов, дстаточно «просто» прочитать документацию к нему (она не такая большая в сравнении со всеми прелестями программирования на bash/perl)

A_Hariton ()
Ответ на: комментарий от Laz

2 Laz

Вы видимо не очень осведомлялись о Puppet, он как раз этим и занимается. Да и корни у него вроде как и bcfg ростут.

A_Hariton ()
Ответ на: мнение от zerot

>в случае большого количества UNIX машин не проще ли подготовить типовые скрипты для конфигурирования и легко отрабатывать их через ssh
То, что все машины работают под управлением юникса совсем не означает, что все машины одинаковые. Когда машин много, все они разношёрстные, а конфигурации разные, подобные утилиты становятся очень полезны.

Laz ★★★★ ()

puppet отличная весчь, давно пользуюсь

Somewho ★★ ()
Ответ на: комментарий от A_Hariton

>Вы видимо не очень осведомлялись о Puppet, он как раз этим и занимается. Да и корни у него вроде как и bcfg ростут.
Изначально я сравнивал cfengine и bcfg2, и после поверхностного ознакомления основное отличие, которое я отметил, было в том, что у cfengine описание императивное, а у bcfg2 - декларативное. В том смысле, что у cfengine в конфигах написано, что нужно сделать, _как_ получить какое-то состояние, а у bcfg2 описывается именно конечное состояние, _что_ нужно получить. Насколько я знаю, puppet - это переработанный cfengine, написанный на руби, поэтому его я особо разглядывать не стал, решил сразу взять bcfg2. Но, честно говоря, я не вникал во все тонкости работы cfengine и puppet, так что могу и ошибаться. Поэтому ждём следующих статей из серии :)

Laz ★★★★ ()
Ответ на: комментарий от Laz

Вообще на блоге есть еще одна заметка про Puppet, а точнее про книгу про него, правда на английском.

Следующие статьи будут где-то в начале следующий недели.

A_Hariton ()

Пробовал его использовать, но как-то не пошло. Сильно энтерпрайзнуто, документация - референс без простого от-и-до мануала, примитивный и слишком уж декларативный язык, ну то есть те же проблемы, которые были ( у меня ) с cfengine.. Chef понравился гораздо больше.

А еще, продолжаю использовать свою надстройку над capistrano, для общесистемных задач. Выглядит это как $scm servername[servergroup] taskname[taskgroup]. То есть есть описанные рецепты, и с локального компьютера или сервера все это рулится, вручную при необходимости, как оно в puppet или cfengine мне не надо.

Кто-нибудь использует именно сабжевый вариант, т.е. описание всех прав, программ и т.п. и применение изменений ( если есть ) раз в n минут? Для чего?? Неужели так часто меняются зависимости и такие базовые конфигурации? Разве не проще нажать в браузере/ввести команду «выполнить вот эту задачу(набор задач)»?

Я понимаю когда есть много серверов, и они постоянно добавляются, тогда конфиг с описанием необходимой конфигурации рулит, но вот постоянный мониторинг обновлений этой конфигурации в пассивном режиме?

volh ★★ ()
Ответ на: комментарий от A_Hariton

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


да нет, bash/perl/ssh дело вполне самодостаточное. Плюс не нужно изучать логику чужих надстроек

Я уже наелся этих «скриптов по ssh», управлять всем этим не очень то просто, а передавать потом такое хозяйство преемнику и вовсе невозможно.


если структурировано, прекрасно передаётся преемнику, знающему базовые технологии. Он ведь может придти со своими предпочтениями и просто заявить, что вот эта фигня не подлежит логическому пониманию. А вот сказать то же про базовые технологии нельзя

В Puppet`е четко определены стандарты описания ресурсов, дстаточно «просто» прочитать документацию к нему (она не такая большая в сравнении со всеми прелестями программирования на bash/perl)


читать про логику чужих надстроек, которые потом автор поменяет как захочет ? как раз в обсуждаемом случае лучше потратить время и силы (они не резиновые) на изучение базовых технологий, а надстройки реализовать свои максимально базовыми средствами ...

конечно, всё ИМХО

zerot ()
Ответ на: комментарий от volh

2 volh:

Весь текст видимо сводился к фразе «постоянный мониторинг обновлений этой конфигурации в пассивном режиме», никто не мешает вам увеличить интервал «мониторинга» с 30 минут до 24 часов.

От Chef отказался по причине ужасной документации, автор через два предложения срывается на какую-то другую тему и забывает о чем только что говорил, в итоге плукая по ссылкам я дошел до рекурсии. У меня два дня заняли попытки поставить его из репозитория Debian и я его не поставил. Поверьте мне, я старался :)

2 zerot:

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

Мне довелось поработать в довольно крупной компании, где правила в iptables вносились вызовом скрипта firewall.sh из rc.conf, а Apache со всеми модулями ставился из сорсов n-годичной давности, и это в CentOS`е.

A_Hariton ()

Единственный большой минус Puppet - это Ruby. Почему до сих пор никто не сделал «правильный» cfengine на Python.

BigAlex ★★★ ()
Ответ на: комментарий от A_Hariton

>Весь текст видимо сводился к фразе «постоянный мониторинг обновлений этой конфигурации в пассивном режиме»

Не сводился. Одна из основных причин, по которой мне больше нравится chef и даже собственный костыль - конфигурация на полноценном ЯП, сейчас многие так делают. «configuration file formats are so yesterday», you know. Еще бы xml в конфигах использовали, чесслово ( хотя xml хотя-бы можно обрабатывать чем угодно ).

никто не мешает вам увеличить интервал «мониторинга» с 30 минут до 24 часов.

Зачем? Зачем мне(и не только мне) вообще этот дурацкий поллинг? Конфигурация изменилась - протестировать, применить(транзакционно), вольно.

Не то чтобы «puppet ненужен пыщ-пыщ», просто интересно в каких случаях такие схемы эффективно используются.

volh ★★ ()
Ответ на: комментарий от A_Hariton

Потому что Python и Perl стоит везде, а Ruby еще нужно ставить. Ну и мне по личным соображениям куда лучше хачить код на Python/Perl/C, чем Ruby. Я сам пользую Puppet и пишу под него модули, дружу его с LDAP, но реально удивлен почему никто не сделает правильный cfengine на Python (хотя есть func, но это немного не то).

BigAlex ★★★ ()
Ответ на: комментарий от BigAlex

И всетаки минуса я не увидел :) Ruby+Puppet не занимают более 10 мб, поэтому ставить его не такая уж проблема, да и какая разница на чем написан софт если он хорошо работает.

A_Hariton ()
Ответ на: комментарий от A_Hariton

Ну вообще там где приходится ставить Ruby под что-то серьезное, то это всегда проблема, потому что всем рибороидам нужен как минимум Ruby Enterprise, а с ним не все так просто как с apt-get update && apt-get upgrade. Основная проблема, что конретно мне и тем кто со мной работает не удобно хачить модули на Ruby (там где этого простого декларативного язычка не хватает), ибо Ruby никогда не был и не будет инструментом системного администратора. Там где не хватает bash есть perl, там где perl не удобен есть python, прокачивать руби не собираюсь, потому что язычок в лучшем случае годится для веб-разработки и так по мелочи, опять же рельсы - всё, другим он нах не уперся.

BigAlex ★★★ ()
Ответ на: комментарий от BigAlex

Вообще с Ruby проблема по сути одна - для него до сих не сделали нормального интерпретатора.

BigAlex ★★★ ()
Ответ на: комментарий от BigAlex

Забавно, вы уже второй человек который утверждает что Ruby не пригоден для системных администраторов при этом не приводя никаких аргументов.

При этом я знаю других админов которые использовали Ruby изначально и не особо горят желанием соскочить на Python/Perl.

A_Hariton ()
Ответ на: комментарий от BigAlex

Не знаю что вы имеете ввиду под термином «нормальный интерпретатор», для задач администрирования нынешнего выше крыши.

A_Hariton ()

Для любителей Python связка Puppet и Capistrano заменяется на Bcfg2 и Fabric.

Puppet/Bcfg2 - для системных вещей, Capistrano/Fabric для императивного выкатывания аппликух.

cyberax ()
Ответ на: комментарий от BigAlex

>Почему до сих пор никто не сделал «правильный» cfengine на Python.
Посмотрите bcfg2.

Laz ★★★★ ()
Ответ на: комментарий от A_Hariton

Я имею ввиду убогую производительность, GC который бесполен чуть менее чем полностью, несовместимость между минорными релизами и т.д. Для задач админисрирования все хорошо, и bash.

Там где люди гоняют большие сайты на RoR у тебя будет стоять в системе как минимум два Ruby-интерпретатора: родной дистрибутивный и Ruby Enterprise или еще что, приключения начнутся именно там.

BigAlex ★★★ ()
Ответ на: комментарий от Laz

Спасибо, посмотрю. Но сразу говорю мне еще нужен LDAP - все хосты там.

BigAlex ★★★ ()
Ответ на: комментарий от BigAlex

Мдя, с Ruby EE действительно проблемы. Уже неделю ищу где бы взять реп с ни для CentOS :(

A_Hariton ()
Ответ на: комментарий от A_Hariton

Ну они хотя бы deb'ки собирают и на том спасибо, но реп конечно не хватает.

Но опять же, я думаю, если Ruby EE всем хорош, то почему он и не есть Ruby?

А то тут еще Rubinius есть. Мне как не рубероиду весь этот зоопарк совсем не по нраву.

BigAlex ★★★ ()
Ответ на: комментарий от BigAlex

Ruby всякие важны, Ruby всякие нужны. :)

Вообще говоря разнообразие интерпретаторов меня самого немного шокирует...

Кстати, если вам так повезло и у вас есть готовый пакет для RubyEE можно же создать собственный реп на SuSE Build Service, я сделал там реп для нестандартного софта и подключил к своим CentOSёным серверам, Debian тоже поддерживается.

A_Hariton ()
Ответ на: комментарий от BigAlex

Вообще говоря разнообразие интерпретаторов меня самого немного шокирует...

Кстати, если вам так повезло и у вас есть готовый пакет для RubyEE можно же создать собственный реп на SuSE Build Service, я держу там реп для нестандартного софта и подключил к своим CentOS`ным серверам, Debian тоже поддерживается.

A_Hariton ()
Ответ на: комментарий от BigAlex

>реально удивлен почему никто не сделает правильный cfengine на Python

правильный в чем и чем не утраивает сишная версия?

volh ★★ ()
Ответ на: комментарий от A_Hariton

>Мдя, с Ruby EE действительно проблемы. Уже неделю ищу где бы взять реп с ни для CentOS :(

а старый добрый https://packages.endpoint.com/ не подходит?

volh ★★ ()
Ответ на: комментарий от volh

А можно подробнее? И ссылочку правильную :)

Был бы очень благодарен.

A_Hariton ()
Ответ на: комментарий от BigAlex

>Мне как не рубероиду весь этот зоопарк совсем не по нраву.

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

Все лучше чем мёртвопёрл.

volh ★★ ()

Странная статья. Зачем нужен puppet, из нее совершенно непонятно. Фактически, просто сказано «а вот есть Puppet, он рулит».

tailgunner ★★★★★ ()
Ответ на: комментарий от volh

>> Мне как не рубероиду весь этот зоопарк совсем не по нраву.

В питоне зоопарк реализаций больше, кстати

Бгг. Кроме CPython практически ничего не используется (разве что Psyco, но это не реализация Python, а акселератор).

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

> Странная статья. Зачем нужен puppet, из нее совершенно непонятно. Фактически, просто сказано «а вот есть Puppet, он рулит».

Вообще задуман цикл, и эта статья скорее вводная чем всеобъемлющая, для большей информации можно почитать книгу: http://stproject.info/blog/?p=714

A_Hariton ()
Ответ на: комментарий от tailgunner

>Бгг. Кроме CPython практически ничего не используется

будто бы рубиниус где-то используется. да и с cpython ситуация похожа на mri - 2.5, 2.6, 3.x / 1.8.6, 1.8.7, 1.9.x.

(разве что Psyco, но это не реализация Python, а акселератор).

он до сих пор популярен? на 32bit из-за этого сидят чтоли? о_О

volh ★★ ()
Ответ на: комментарий от A_Hariton

>Бегло глянул в доку bcfg2 (http://trac.mcs.anl.gov/projects/bcfg2/wiki/WritingSpecification) и пришел к выводу что Puppet лучше хотя бы потому что ресурсы не описываются в формате XML. Как это вообще читать можно?
Вот с этим согласен, xml - полный ацтой. Но в остальном мне всё нравится. Тем не менее, жду продолжения статей про puppet :)

Laz ★★★★ ()

Скажите а чем puppet лучше cfengine3?

у cfengine например есть огромный плюсище - написан на сях и использует систему «обещаний». Чем может похвастаться puppet?

anonymous ()
Ответ на: комментарий от anonymous

Ув. ананимус просветите, а что есть «система обещаний» ?

A_Hariton ()
Ответ на: комментарий от anonymous

насколько я помню, cfengine сложно расширять.

аноним, может ты подскажешь, раз уж заикнулся. все эти promise theory, self-healing, блабла, это все конечно очень здорово, но какие практические ситуации, где оно может быть полезно? в контексте именно scm?

volh ★★ ()
Ответ на: комментарий от volh

В питоне нету никакого зоопарка. Есть legacy, есть Python 2.x (мейнстрим), есть Python 3.x (будущий мейнстрим). Там Гвидо все настолько правильно и последовательно делает, что даже я не могу ни к чему придраться.

У руби же есть несколько вендоров, которые выпускают свои собственные «бесподобные» сборки, каждый со своим плюшками. В отличии от питона они не являются экспериментальными, и вполне себе конкурируют с официальным интерпретатором.

BigAlex ★★★ ()

Надо будет заценить. То что на Ruby - это плюс.

iMp ★★★ ()
Ответ на: комментарий от A_Hariton

я так неудачно перевел promise theory - это чисто академическая разработка Марка Бержеса, которая стала основой для cfengine3. Грубо говоря это правила по которым происходит конфигурация. Вы указываете жедаемое конечное состояние системы, система стремится прийти к этому состояни. Для ознакомления предлагаю посмотреть - http://www.youtube.com/watch?v=4CCXs4Om5pY

ах да, в cfengine3 еще встроенная knowledge system которую очень удобно связывать с cmdb.

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.