Labutin
@Labutin
Web-разработчик

Как правильно использовать Puppet?

Присматриваемся к Puppet.
Возник такой вопрос.
Скажем, все настроено. С помощью Puppet все машины сконфигурированы.
Настало время что-то поменять в конфигах. НО это нужно сначала протестировать.
Сразу вопрос - где? В отдельной копии боевой инфраструктуре? Да, это идеальный вариант.
Но, например, копии инфраструктуры нет.
И, например, у меня есть парк однотипных нод из 10 штук. Я хочу протестить измененный конфиг nginx на одной из этих нод.
И вот тут у меня вопросы :)
Я меняют конфиг. Puppet ведь должен заметить, что конфиг отличается от эталонного и его мне перезальет? Или нет?
Или мне на этой ноде нужно остановить puppet agent, поиграть с конфигом. Внести эти же изменения на puppet master'е и он разольется всем остальным? Так? Или все совсем по-другому?

Заодно задам более простой вопрос. В введении написано, что puppet agent раз в 30 минут ходит к мастеру с вопросом, не поменялись ли настройки и если что, их у себя меняет. Это значит, что ноды могут в разное время применить новые настройки. Наверняка же можно сделать так, чтобы новые настройки того же nginx на всех нодах применились одновременно? Если это есть в доках, то просто скажите мне "читай мануал, там это есть" :)
  • Вопрос задан
  • 3278 просмотров
Пригласить эксперта
Ответы на вопрос 5
Я рекомендовал бы вам добавить к вашему папету еще hiera, про нее была статья habrahabr.ru/post/242657
Она позволить вам более гибко управлять вашими серверами.
В вашем случае вам нужно будет ли создать 1 yaml файл для конкретной ноды и переписать локацию нового конфига.
Ответ написан
ptchol
@ptchol
Linux system administrator
С "оркестрейшеном" у puppet все плохо.
Был puppet-kick, но его выпилили, теперь есть mcollective, который позволит вам дернуть агента на всех нодах и применить конфигурацию. Но имхо это из пушки по воробьям.
Мы по прежнему по старинке, через pssh дергаем на нужной группе нод 'puppet agent -t'.
Применить конфиг на отдельном сервере, из коробки я думаю врядли получится. Нужно придумать что то свое :).
Ну или конечно же, Вы всегда можете нагородить
if $::fqdn in $testing_nginx_servers {
    $config = new_config
  else {
    $config = stable_config
  }
  ::nginx::vhost { 'server.com' :
    template      => $config
    server_name   => "${::fqdn} ${title}",
    document_root => '/var/www/server.com',
    ssl_keys      => 'server.com'
  }

А где нить в site.pp объявить
$testing_nginx_servers = [ 'web-1.server.com', 'web-2.server.com' ]


В конце концов вы можете раскатывать конфиг, но не релоадить nginx :).

На тему ansible vs puppet. Субъективно, ansible, массовый раннер скриптов :). К тому же на состояние полугодовалой давности довольно тормозной.

Puppet подразумевает, что накатка изменений, не влияет критично на Ваше окружение, и может происходить в фоне. Тоесть для ряда пакетов Вы написали 'ensure => latest', и не паритесь, обновляется оно сам по себе когда нада +\- 30 минут и всё. Внесли изменения в конфигу, проверили на одном серваке, и уверенны что через полчаса это будет везде. Сейчас скажу глупость, но о "схеме" его работы можно сказать что он "согласован в конечном счете", и этот "конечный счет" определяется получасовым таймаутом обновления (как в DNS :) )

Может быть уже неактуально, но вот здесь человек сравнивал ansible \ salt в качестве альтернатив для переезда.

Если привлекает YAML в puppet есть hiera, для экспорта ресурсов с нод, есть puppetdb (к примеру что бы при добавлении backend серверов, их адреса попали в необходимый upstream у nginx, без прямого прописывания их в конфиге).

Если напрягает что нету всяких "циклов", то это решается во первых при помощи define, или в свежем синтаксисе есть each / slise / reduce / filter, который позволяет удобно работать с со всякими списками параметров, плюс очень много чего полезного реализовано в stdlib.

Puppet декларативен, и если вы не хотите мирится с отсутствием возможностей перезаписать переменную / параметры ресурса / класса, то Вам будет сложно с ним, иначе не вижу ничего плохого в этом выборе.
Ответ написан
xenozauros
@xenozauros
Админю, пишу на питоне, вот это вот все...
Для этого в паппете есть окружения.

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

При использовании r10k - это очень удобно делать прямо ветками в гите - создаете новую ветку, деплоите ее как отдельный environment, потом мерж.
Ответ написан
Комментировать
opium
@opium
Просто люблю качественно работать
В конфиге паппета примените новый конфиг только для однной ноды а не для всех, там же можно прописывать конкретные ноды.
В целом рекомендую вам переходить на ansible он пободрее и поинтереснее
Ответ написан
Labutin
@Labutin Автор вопроса
Web-разработчик
Мы в состоянии, когда еще не внедрили puppet. Но вроде читали сравнения в том числе и с ansible. Может не то читали? :) Можете привести доводы в ползу ansible? Не хотелось бы потом пожалеть о выборе puppet.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы