Puppet: А умеет ли...?

1) Чтобы не Puppet master искал в сети машинки, коннектился по SSH и «заражал» их нужной конфигурацией, а чтобы сами машинки находили сервер Puppet и забирали с него конфигурацию.

Ты всё перепутал. puppet master не ходит на машины по ssh. Наоборот, агенты puppet подключаются на https://puppet_server:8140/ и запрашивают манифест

2) Чтобы можно было сказать Puppet Master'у: вот к тебе сейчас «придёт» машинка с идентификатором X (класс идентификатора Y)

/etc/puppet/manifests/site.pp 
import "classes/*"

import "nodes.pp"

/etc/puppet/manifests/nodes.pp 
[...]
node 'node1.domain', 'node2.domain' inherits 'app-network' {
        Xymon['domain-xymon'] {
                prefix  => 's-',
        }
        Zabbix["server-zabbix"]{ prefix => 's-' }

        include domain-hardware
        san-emc::hostagent{'domain-hostagent':
                user    => 'system',
                array_ips       => ['1.1.1.1','1.1.1.2'],
                require => Repository['domain-repo'],
        }
}

Не вполне удачно оформил. По примеру сложно понять

вот к тебе сейчас «придёт» машинка с идентификатором X (класс идентификатора Y), настрой её как на исполнение «роли Z»

В общем, агенты puppet авторизуются по сертификатам, которые выдаёт сервер puppet ( управление через puppetca на сервере. puppetca --list --all, puppetca --sign FQDN ). Сертификат привязан к FQDN

Т.е. в конфиге «идентификатор X» обозначается как «node 'FQDN'»

Про класс идентификатора не понял.

В качестве «роль Z» будет использоваться класс. Сначала определяешь класс с его ресурсами, затем просто подключаешь его к ноде

Ты всё перепутал

Не-а, ни разу :) Я говорю именно об autodiscovery и zero-configuration. Puppet умеет отыскивать машинки, заходить по ssh на них и забрасывать свою чудо-конфигурацию. А это собственно и есть настройки коннекта к серверу, плюс по-моему настройка согласования сертификатов. Вопрос только в том, на кой ляд он это делает, если можно собрать образ машинки с puppet-agent'ом, который по SRV-записи или с помощью bonjour/bootp-подобного протокола сам узнает, где находится сервер и попросит у него конфигурацию.
То есть вопрос в том, как клиенту получить конфигурацию, если он не знает где сервер, а сервер не знает ничего о клиенте.

После запуска puppet agent тычется на хост puppet. Если отключить проверку сертификатов и правильно настроить dns - он таки начнет что-то сразу даже с сервера выятягивать (default node, вестимо). Имена нод можно использовать с вилдкардами, а-ля

node '*-router'{
 include router
}

Сначала определяешь класс с его ресурсами, затем просто подключаешь его к ноде

Вот это статичное прибивание конфигурации гвоздями и плохо, на мой взгляд.
Гораздо удобнее делать так:
1) Запускаешь на master'е «ожидалку», которой говоришь: сейчас придёт IP=10.0.7.11 (или Hostname=newbie.doman.local), отдай ему манифест для шаблона/класса/роли «PostgreSQL-сервер»
2) Машинка 10.0.7.11 делает запрос в DNS SRV-записи, находит IP сервера-автоконфигуратора
3) Машинка идёт на заданный IP и получает «свой» манифест, после применения которого она будет знать, какую «роль» исполняет, так что в дальнейшем будет запрашивать шаблон для этой роли (включающий, вероятно, некие «общие» для множества ролей части - конфигурацию NTP и SNMP, например)
Всё. Гениально просто, да и сертификаты сюда вполне можно прикрутить.

http://docs.puppetlabs.com/guides/scaling_multiple_masters.html
Однако, не прошло и 10-ти лет, а они в 3-й версии уже ввели поддержку SRV-записей DNS как экспериментальную!

Puppet умеет отыскивать машинки, заходить по ssh на них и забрасывать свою чудо-конфигурацию

пример из документации в студию. Не слышал о таком.

все неверно. машинка не знает о своей роли. Она просто запрашивает «кто я? что мне делать? какого состояния достичь?» а мастер по ее хостнейму выдаёт ответ.

1) Запускаешь на master'е «ожидалку», которой говоришь: сейчас придёт IP=10.0.7.11 (или Hostname=newbie.doman.local), отдай ему манифест для шаблона/класса/роли

Насколько я знаю, так делает cfengine

В puppet это выглядит так:

• на новом хосте устаналиваешь клиента puppet
• на новом хосте puppet agent. Он обнаруживает что у него нет сертификата. Генерит новый ключ и засылает csr на puppet.$localdomain.
• на сервере puppet ты подписываешь новый сертификат и добавляешь ноду в манифест ( в моём случае - nodes.pp )
• на новом хосте ещё раз перезапускаешь puppet, он получает новый сертификат
• далее раз в полчаса ( по умолчанию ) puppet agent, авторизуясь своим сертификатом, ломится на puppet server и запрашивает манифест. Получив - применяет.

  2) Машинка 10.0.7.11 делает запрос в DNS SRV-записи, находит IP сервера-автоконфигуратора
  

  ЕМНИП, cobbler умеет разворачивать новые ВМ и автоматом подключать их к puppet. Я пока не использовал.

  Всё. Гениально просто, да и сертификаты сюда вполне можно прикрутить.
  

  И уязвимо. Пока на клиенте pupet нет сертификата, он не может определить, настоящий ли сервер принял соединение. При ручном подписывании сертификатов ты контролируешь процесс. Именно этим мне совершенно не понрафился cfengine - он подписывает сертфикаты автоматом

Судя по вот этому: http://www.codelord.net/2010/12/19/using-puppet-to-automatically-configure-ne... - ждать от Puppet нормального zero-configuration не стоит. По-моему даже старый-добрый BOOTP с его древним, как Г. мамонта, методом загрузки с образа, закачиваемого по TFTP, куда более адекватен. И никаких дурацких мешающих жить сущностей типа «встроенного Certificate Authority». Я считаю, что уже за один только этот дикий невообразимый хак с «самопальным» Certificate Authority разработчиков Puppet нужно было сразу закидывать тухлыми помидорами! И на фоне этого вбивание A-записи для по-детски наивного хостнейма «puppet» уже кажется невинной шалостью. Впрочем, поддержка SRV-записей в 3-й версии уже дайт надежду на лучшее. Вот только для того, чтобы агент запросил SRV-запись, ему всё равно нужно соотв. опцию выставить в true в puppet.conf'е.
Блин, и смешно, и грустно: все это говно хавают и ни один человек ведь не возмутился: what the fuck?
И ведь действительно, самым разумным со стороны всех этих чудо-строителей коммунизма было бы не лепить какие-то ruby-поделки, а сделать нормальное стандартизованное на уровне RFC расширение для BOOTP/DHCP, которое позволило бы конфигурировать не только сетевые параметры, но и всё что угодно - имея на входе только информацию о MAC-адресе клиента.

Насколько я знаю, так делает cfengine

Да ну, неужели хотя бы старый-добрый cfengine сделали не кривожопые велосипедостроители?! Пойду почитаю...

bootp & puppet совершенно разные задачи закрывают, не находите? И еще, прежде чем «кормить говном ЛОР», опишите, что такое zero конфигуратион в вашем понимании , для вашей задачи.

Генерит новый ключ и засылает csr на puppet.$localdomain.

на сервере puppet ты подписываешь новый сертификат и добавляешь ноду в манифест ( в моём случае - nodes.pp )

Здесь корень зла как раз:
1) Нужно держать в DNS похабного вида запись puppet IN A, которая противоречит здравому смыслу. Такое впечатление, что разработчики Puppet в принципе не ведают об autodiscovery/service announcing типа bonjour, а о существовании специальных сервисных записей в DNS узнали только вчера, и то почему-то их поддержка не является «умолчанием», а значит править puppet.conf каким-то черезжопным методом всё-таки придётся!
2) На сервере нужно либо автоподписывать все подряд (что в принципе логично, но немного противоречит «концепции безопасности» puppet'а), либо опять же - подписывать вручную.
Таким образом, мы неизбежно приходим к тому, что без каких-то предварительных хакерских изысков получить на вновь созданой виртуалке хоть какую-то конфигурацию - невозможно. Сравните с тем же DHCP, которому это как-то удаётся, да ещё и платформо-независимым образом! И это при том, что DHCP не требует установки сотни мегабайт каких-то руби-приблуд.

bootp & puppet совершенно разные задачи закрывают, не находите?

Не нахожу. Абсолютно одинаковые задачи они закрывают.
DHCP-сервер может «пушить» DCHP-клиенту любые параметры, лишь бы последний умел их применять тем или иным образом. И чем это принципиально отличается от Puppet? Только более развитым синтаксисом правил последнего?
Собственно, мне не нужен puppet как таковой, мне нужно, чтобы на новорожденной виртуалке по запросу, аналогичному DHCP, на ней конфигурировались не только ip/маршруты/dns/wins и т.д., но ещё и пушился некий набор правил, который эта виртуалка могла бы применить. Такое чудо возможно?

О том, что такое zero-configuration (2-е десятилетие 21-го века идёт, а мужики-то и не в курсе таких чудес):
http://en.wikipedia.org/wiki/Zero-configuration_networking

1) Нужно держать в DNS похабного вида запись puppet IN A,

Как вариант, можно добавлять её в /etc/hosts, чтобы исключить проблемы с DNS

Такое впечатление, что разработчики Puppet в принципе не ведают об autodiscovery/service announcing типа bonjour,

Какой нафиг auto discovery для серверов? Это и есть черезжопу и несовместимо с принципом KISS

2) На сервере нужно либо автоподписывать все подряд

Убивать...

но немного противоречит «концепции безопасности» puppet'а),

Немного? А если подумать головой? puppet/cfengine полностью контролирует конфигурацию сервера, а долбоклюи из cfengine кладут на безопасность. В отличие от puppet

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

Ещё раз : cobbler

Сравните с тем же DHCP, которому это как-то удаётся, да ещё и платформо-независимым образом!

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

http://www.linuxmanpages.com/man5/dhcp-options.5.php Раздел «STANDARD DHCP OPTIONS» очень внушает. И это только STANDARD. Опции могут быть и нестандартными, вопрос только в том, сможет ли их «применить» DHCP-клиент.

Какой нафиг auto discovery для серверов?

Поясните, что, собственно, есть такое ужасное в авто-дискавери сервисов применительно к серверам. А заодно - чем таким интересным различаются «сервера» и «не сервера»? У нас как-то был вычислительный кластер из кучки рабочих станций программистов, он очень важные задачи, между прочим, решал. Это вот у них сервера были или не сервера? А вот принтер, на который у нас все в офисе печатают и в него зашит обычный CUPS, - он сервер или нет? Обнаруживается он влёт по bonjour'у - значит, не сервер, наверное. Какая жалость, пойду что ли за топором, буду ломать эту проклятущую несекьюрную железку.

а долбоклюи из cfengine кладут на безопасность.

Выше я уже кидал ссылку, кину ещё раз http://www.codelord.net/2010/12/19/using-puppet-to-automatically-configure-ne.... Просто почитайте, как эту вашу «безопасность» лихо обходят для хакерски-залихватского решения, казалось бы, элементарной задачи.
Да, и почему в утилиту rm не зашита защита от хакерской угрозы? Я считаю, давно пора уже всех желающих пользоваться такой смертельно опасной вещью как rm (а вдруг там -rf / - вообще катастрофа!) принудительным образом аутентифицировать с использованием генерируемых утилитой rm сертификатов. Почему в rm нет встроенного Ceertificate Authority, как они могли это допустить?!

То есть если puppet будет как DHCP выдавать конфиг всем, кто может его принять, то я в твоей сети подключаюсь и беру конфигурацию со всеми секретами, паролями и прочим?

А если нет - то что сложного зайти в виртуалку, ввести пару команд, а на сервере подписать?

Вы когда на сервере подписываете, внимательно сверяете шестнадцатеричный код, который он там выдаёт, с тем, который на клиенте? Смысл «безопасности», обеспечиваемой puppet - в шифровании. Но если мне оно нафиг не сдалось, если нужно просто конфигурацию базовых сервисов передать, то от этого ведь функциональность zero configuration у puppet'а не появится. Хотя если обозвать один из хостов в сети puppet'ом... В любом случае это должна быть кастомная сборка с установкой puppet-агента.

а чтобы сами машинки находили сервер Puppet и забирали с него конфигурацию

Вполне стандартная вешь (cobbler, foreman). Я на cobbler решение собирал: pxe-шная установка c kickstart файлом, генерируемым через cobbler snippet'ы. Сделать snippet, который в postinstall скрипте прописывает puppet.conf с указанием master'а и вызывает puppet agent --test -w 0 просто. Гораздо проще, чем настроить все остальное. Еще нужно у cobbler'а 2.4 включить hook, который вызывает puppet ca sign по окончании установки.

Если все остальное настроено, можно обеспечить unattended взлет от начала загрузки по сети до полнофункционального состояния. (Реально unattended, без единого нажатия клавиши)

Чтобы можно было сказать Puppet Master'у: вот к тебе сейчас «придёт» машинка с идентификатором X (класс идентификатора Y), настрой её как на исполнение «роли Z». То есть, например: жди запроса от 10.0.7.11, настрой на роль «PostgreSQL-сервер»

Подходишь к puppet master'у и говоришь: будешь настраивать машинку с индификатором X, выдай-ка ему пропуск (puppet ca generate X). Потом относишь его на машину X и говорирь: будешь ходить туда, вверительная граммота вот.

Чтобы не Puppet master искал в сети машинки, коннектился по SSH и «заражал» их нужной конфигурацией

Это наверно кто-то скриптик на коленке сварганил.

«Мощно задвинул!» (С)
А вы могли бы это в виде статьи написать? Я думаю, вам очень многие скажут спасибо, тема-то злободневная для многих.
В любом случае большой респект за наводки!!

Посмотри в сторону ansible.

А, собственно, зачем оно надо? Если ты про zero-config, то это делается на уровне бута через tftp+NFS (соответственно, обновляем NFS, ребутим сервера). Если нет - можно просто написать скрипт, который сам всё ставит и настраивает, после чего wget этот_скрипт && запуск.

Помню когда пару лет назад внедрял puppet видел красивые ролики в которых разрабы демонстрировали свое решение для автоматизации сетапа и настройки серваков

Типа есть dashboard и DHCP сервак. Из морды можно было рулить пресетами инсталяционных образов и конечными настройками сервака. Ну типа выбираеш что хочу на сервак с маком 88.bb.44.ee.44.22 засетапить CentOS, назначить ему такието роли, установить такието пакеты и тд. в конце эта веб морда генерила конфиг для DHCP и Puppet-master-а, оставалось только врубить сервак и убедиться что бут пошел по сети. Допилили они это решение или нет - незнаю, с puppet уже давно не работал.

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