Комментарии 26
1. Например есть у нас в группе web два аккаунта — developer1 и developer2. И все работает. В какой-то момент developer1 уходит с этого проекта и нам нужно удалить все его ключи со всех серверов. Пупет это сможет?
2. Частность от первого варианта. developer1 во время работы добавил ключ своего ноутбука, ручками в authorized_keys. Что будет с ними?
2. Если параметр purge ssh keys = false, что правильнее оставлять по умолчанию, то все ключи добавленные вручную будут пропускаться при обновлении.
- Ни один девопс разработчика на продакшен не пустит.
- При увольнении девопса файл с ключами перегенерируется и распространяется на сервера.
- За "лезть ручками" в автоматически управляемое окружение надо бить по рукам — есть тестовая среда и стейджинг
— стандартная библиотека просто нищая
— модули, их много, ни одного рабочего
— миграция с пупет 3 на пупет 4 — это невозможно, проще засетапить по новой
— внутри руби
— последовательность исполнения надо указывать явно, есть целыз 3 способа это сделать
— нет возможности просто выполнить команду, тащите mcollective
— ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
— очень сложно выполнить на одном хосте код из отдельного бранча
— все пути прибиты гвоздями, нельзя положить файлик никуда кроме files
— не понятно куда пихать прослойки profiles/roles, то ли в модули (но это не модули), то ли в манифесты (но к хостам это тоже не относится напрямую), положить в отдельный каталог нельзя, все прибито гвоздями.
— и еще много чего
Да, действительно стандартная библиотека многого простого не умеет или же это простое нужно делать какими-то костылями. И помню, например, замену строки в файле и как это нелегко делалось…
Последовательность исполнения — это тот еще ад, особенно когда много кода понаписывали.
В конфингурациях master-client прекомпиляция почему-то делается на мастере и только на нем и это достаточно быстро приводит к проблемам масштабирования мастера.
Среди плюсов — это наверное то, что есть Фореман. Ну я не совсем о том, что он очень плох, я о том, что если есть выбор — то лучше попробовать Ансибл.
— ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
Для этого в puppet предусмотрены External Node Classifiers (ENC), например hiera (вот, например, статья на эту тему).
— стандартная библиотека просто нищая
Хотелось бы конкретный пример того, что нужно и чего нет в puppetlabs/stdlib?
— внутри руби
Наоборот, проблема в том, что нельзя напрямую использовать inline ruby, в отличие от Chef, например
— последовательность исполнения надо указывать явно
Да, внутри файла можно было бы добавить зависимость по умолчанию
— нет возможности просто выполнить команду, тащите mcollective
Ну это нормально для pull системы конфигурации
— очень сложно выполнить на одном хосте код из отдельного бранча
Гм… environments? Работает нормально, была пара багов, но их поправили
— ресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
Ну конечно ресурс с одним именем уникален — было бы странно иметь неоднозначную систему конфигурации
— не понятно куда пихать прослойки profiles/roles
Ну так для этого Foreman и создан — там очень гибкая система smart variables — позволяет задавать разные конфигурации в зависимости от множества факторов — имени хоста, домена, группы, региона и т.д.
Я думаю, что основная проблема в том, что для понимания построения масштабной системы управления конфигурациями на основе Puppet надо обладать серьезными знаниями — отличиями в push/pull системах конфигураций, понятие об external node classifier, compile master, cvs и прочая. Ansible конечно проще для начального освоения.
— руби — это ужас, читать чужой код невозможно, писать свой тяжело, в итоге если в модуле банальная бага, ее правка выливается в тонны потраченного времени
— если бы у бабушки были яйца…
— push система легко превращется в pull, наоборот нет. Зачем делать только pull?
— environments решают другую проблему, да даже таскать хост по разным env — это куча телодвижений
— это все приводит к боли, добавил роль, а там уже что-то есть и начинается, убрать из роли нельзя, так как у других сломается, оставить как есть тоже. Можно же не выдавать ошибку если ресурс определен дважды, но одинаково?
— а без форемана? Его для пупет4 так и не портировали. Как жить?
а inline_template, или вы не об этом? http://blog.abhijeetr.com/2012/11/execute-ruby-code-from-puppet.html
Chef позволяет использовать код напрямую, без извращений. Вот пример из документации:
if platform?('windows')
ruby_block 'copy libmysql.dll into ruby path' do
block do
require 'fileutils'
FileUtils.cp "#{node['mysql']['client']['lib_dir']}\\libmysql.dll",
node['mysql']['client']['ruby_dir']
end
not_if { File.exist?("#{node['mysql']['client']['ruby_dir']}\\libmysql.dll") }
end
end
Так как рекомендуют обновлять в пределах одной версии (10 -> 11 ->12), то решил не мучаться и поставить с нуля сразу 1.14 версию (руками перенес только группы), используя foreman-install
После установки, паппет агенты на хостах автоматом начали региться через фореман-прокси, тк использовался старый сертификат, отрабатывали тоже корректно, но через пару часов апач+мод_пассенджер переставал отвечать по достижении лимита сессий в очереди.
Что только не пробовал, увеличивал все лимиты, убирал их совсем, тюнил апач — ничего не помогало, через час passenger (причем последняя версия 5.1.2, где все-все исправили) перестает работать,(паппет агент на амазоновских хостах вообще отваливался по Net::Timeout)
На дебиан 7 фореман любой версии работает без проблем с дефолтными настройками, мистика просто.
Небольшой комментарий по поводу ntp серверов. Для России удобно использовать 0.ru.pool.ntp.org, 1.ru.pool.ntp.org, 2.ru.pool.ntp.org...
@tgz, "паппет ужасен", в чистом его виде — согласен. С использованием встроенной hiera, все описание на YAML достаточно просто и элегантно.
Из текущего в небольшой конторе:
- Puppet 4.9.4 на Debian 8
- 2 окружения (environments): corporate & production
> ls -l /etc/puppetlabs/code/environments/corporate/hieradata/nodes/ | wc -l— 60 (и физ. сервера и виртуалки)- в проде хостов по-меньше
- общее кол-во модулей — 61
- кол-во модулей от 3их разработчиков (т.е. не от Puppetlabs) — 36
При использовании hiera, ruby манифест сокращается от 1 до 6 строчек:
/etc/puppetlabs/code/environments/corporate/manifests/site.pp
(устаревший вариант, но еще работающий)
hiera_include('classes')либо
include lookup('classes', { 'merge' => 'unique' })или такой, в зависимости от того какое слитие данных необходимо:
lookup({ 'name' => 'classes',
'merge' => {
'strategy' => 'deep',
'merge_hash_arrays' => true,
},
})Иерархия описывается на уровне системного hiera конфига; задатается как угодно; нам хватает вот этого:
hierarchy:
- name: "Nodes"
path: "nodes/%{::trusted.certname}.yaml"
- name: "Roles"
path: "roles/%{::role}.yaml"
- name: "Vurtual"
path: "virtual_%{::is_virtual}.yaml"
- name: "OS"
path: "os_%{::operatingsystem}.yaml"
- name: "Environment"
path: "env_%{environment}.yaml"
- name: "Common Defaults"
path: "common.yaml"Последовательность вызова задается в hiera очередностью описания классов, например:
---
classes:
- apt
- sudo
- nslcd
- packageресурс уникален, в итоге если каждый хост немного отличается от остальных — это лапша из if
совсем нет, есть knockout_prefix'ы; есть использование alias'ов и переменных, например:
> hieradata/node/devvm01.yaml
dev_username: "username"
> hieradata/role/dev_vm.yaml
sudo::configs:
"%{alias('dev_username')}":
'content' : "%{alias('dev_username')} ALL=(ALL:ALL) APTGET, APACHECTL....все пути прибиты гвоздями, нельзя положить файлик никуда кроме files
смотрите в /etc/puppetlabs/puppet/fileserver.conf и /etc/puppetlabs/puppetserver/conf.d/auth.conf. По сути, Puppet Server — это web сервер, который можно настроить как угодно:
# access via puppet:///my_mount_point/
[my_mount_point]
path /etc/puppetlabs/my_mount_point
allow *не понятно куда пихать прослойки profiles/roles
окружения (environments), когда недостаточно:
> cat /etc/puppetlabs/facter/facts.d/role.json
{
"role": "dev_vm"
}Плюс подобных подролей может быть сколько угодно. В hiera они просто будут как переменные и легко отслеживаются (см выше).
push система легко превращется в pull, наоборот нет. Зачем делать только pull
хм, нежеланием вешать Puppet Agent на порт, и связанным с этим геммороем в виде дыр, настройкой firewall'а, проброской NAT'а и прочими радостями...
К чему я это все, Puppet очень гибкая система, если есть желание с этим разбираться. Зато когда разберешься, то все летает.
Другой вопрос, что документация у них оставляет желать лучшего.
- Как вы будете переиспользовать handler какой-то роли из другого плейбука, при условии что саму роль исполнять не надо? Если сделать include в handlers -то оно не будет реагировать на notify в версии 2,2(написано в доках)- тут только финт ушами в виде include файла с описанием handler как таски или делать отдельную роль со всеми нужными handler(что, как мне кажется, через пятую точку). По аналогии с папетом- в модуле можно сделать отдельный клас для рестарта и дергать только его(без дублирования описания ресусра)
- Как сказать через ansible что вот такой сервис при изменении конфига должен быть перезапущен и должен всегда быть запущен в системе? Тут только отдельный handler на перезапуск и таска на старт(иначе когда кто-то ручками остановит сервис и никаких изменений в конфиге не было- сервис так и не запустится). На папаете это будет один ресурс, который можно «обновлять» из других
Вообще такое чувство что ansible все еще сырой, в 2.2 завезли баг в yum модуле- при использовании state=latest — не ообновлялся пакет, который стоит в списке от yum checkupdate первым. Вместо того, чтобы получать список пакетов через rpmconf (как им еще ранее советовали)- опять написали кучу регулярок для парсинга yum checkupdate.
Очень двойственное чувство от ansible, если бы не отсуствие выделенного сервера- оно бы «не взлетело».
2. register и when? state: started? (в пупете тож не за раз всё опишется)
Пупет я не люблю больше ансибла :) Но на текущей работе нет salt, зато есть и foreman, и ansible, и puppet :(
2) Вот тут вообще не понял причем здесь и зачем «register и when? state: started? » даже если рассматривать вариант с таской на запуск и handler на рестарт оно не надо. Почему в папете «не за раз» опишется? ресурс запускающий сервис и рестартующий ровно один, остальные его обновляют(аналог notify).
И эти примеры только-то — на что недавно наступил…
Полностью согласен по всем пунктам, Puppet хорош при грамотной настройке.
Установка и настройка Puppet + Foreman на Ubuntu 14.04 (пошаговое руководство)