Comments 26
Из всего многообразия scm, puppet нравится больше всего. Жаль что ансибл проще (в одной такой статье можно весь ансибл описать) и везде где я работал, выгоднее использовать именно ансибл.
Я вам таки больше скажу — у этих инструментов немного разная область применения, поэтому можно использовать и то, и другое. Мы используем puppet для поддержания конфигурации серверов в нужном состоянии, а ansible используем для разовых заданий (например, поднимаем кластера Ceph именно с помощью ansible).
ansible-playbook .... --check --limit=host
Как мы пишем паппет-код: инструментальная обвязка, документация, тестирование, CI/CD
Это конечно интересно (многие проголосовали за это), но это уже все есть :)
А вот как Вы «подружили несколько папет-серверов» с этого места поподробнее!!!
Очень уж хочется узнать как это возможно.
Т.к. хотим «съехать» с папета4 на папет6 и если такое возможно (особенно бесшовно) — не держите в себе! Рецепт в студию (с)
В нашем случае ситуация достаточно тяжёлая, потому что написано много кода посредственного качества под третий паппет, а в новый (изначально пятый, но к моменту запуска уже шестой) паппет мы хотели не просто перенести старые манифесты, а применять подходы Infrastructure as Code и писать качественный код, покрывая его тестами. Между третьим и шестым паппетом большая разница: как минимум, отличаются парсеры (https://puppet.com/docs/puppet/3.8/experiments_future.html), разные версии hiera (hiera 1 в третьем паппете и hiera 5 в шестом), поэтому мы потихоньку переписываем старые манифесты с нуля и переводим сервера со старого паппета на новый поштучно (ну, или скорее по группам).
Кроме огромного объёма манифестов, которые нам нужно переписать, встала ещё одна проблема: для бэкапов мы используем экспортируемые ресурсы, а для работы экспортируемых ресурсов нужна одна общая PuppetDB. Разные версии паппета совместимы с разными версиями PuppetDB, обратной совместимости нет (во всяком случае, не при такой разнице версий, как у нас), поэтому мы написали прокси для старого паппета, который реализует интерфейс старой PuppetDB и кладёт данные в новую PuppetDB. Ну и плюс были небольшие приседания с сертификатами для того, чтобы в одну и ту же PuppetDB ходили несколько новых паппетсерверов (засада кроется в двусторонней проверке TLS-сертификатов, каждый паппетсервер хочет, чтобы у PuppetDB был сертификат, выпущенный этим же паппетсервером).
Третий момент — сетевая конфигурация, которая хранится в Hiera и должна быть одинакова для сервера вне зависимости от того, под какой версией паппета этот сервер. Здесь просто — вынесли эту Hiera в отдельный репозиторий и подключаем его ко всем паппетсерверам.
В вашем случае проблем, скорее всего, будет меньше: если я правильно понимаю, то парсер четвёртой и шестой версии паппета если и отличается, то не так сильно, во всяком случае, лямбды туда уже завезли, да и окружения используются по умолчанию.
Раз у вас настроен CI/CD — попробуйте залить существующий код под шестой паппет, прогоните тесты, поймёте масштаб бедствий. Если тесты не покажут проблем, то переключайте агенты под новый паппет, прогоняйте в режиме noop, смотрите, бомбанёт что-нибудь или нет.
theforeman.org/plugins/katello
Если хотя бы один из модулей под вашим управлением — поменяйте название конфликтующего ресурса, добавьте туда название модулей, например (см. мой пример с разными провайдерами для пакета).
Про отслеживание зависимостей — так как в терминологии паппета нет понятия "подмодуль", тут нужно уточнить, речь идёт об отдельных модулях-зависимостях (тогда надо смотреть в metadata.json/Puppetfile/Modulefile), или о ресурсах внутри одного модуля, от которых зависят другие ресурсы внутри этого модуля (вообще паппет показывает, в каком именно месте используется необъявленный ресурс)?
Если я правильно понимаю, то ошибка именно из-за дублирования ресурса user { 'deploy': } в старом и новом модуле. Решается эта проблема так:
Есть и другие способы достигнуть идемпотентности при добавлении ресурсов, а именно использование функцийdefinedиensure_resources...
Хотел чисто технический вопрос уточнить. Мне нужно содержимое папки с паппет сервера перекинуть в папку на клиенте. Буду благодарен за помощь.
Мб это не бест практис?
class copy_certs {
file {
'/home/name/certs':
ensure => directory,
recurse => true,
mode => '0644',
owner => 'root',
group => 'root',
source => '/etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certs',
}
}
Пробовал добавить в source
source => 'file:///etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certs',
Ошибка всегда одинаковая.
Error: /Stage[main]/Copy_certs/File[/home/name/certs]: Could not evaluate: Could not retrieve information from environment ubuntu_vdi_test source(s) file:///etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certs
А про это я как раз расписал в описании ресурса типа file: https://habr.com/ru/company/avito/blog/507346/#file, конкретно в параметре source.
Если указывать схему file:, то исходные файлы будут браться с той ноды, на которой запускается паппет-агент. Чтобы брать файлы с паппетсервера, нужно использовать схему puppet:, и использовать правильные пути на самом паппетсервере.
Директория /etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/files/certs не прокатит — нужна поддиректория files внутри какого-нибудь модуля. Например, назовём модуль certs, путь на паппетсервере будет /etc/puppetlabs/code/environments/ubuntu_vdi_test/modules/certs/files/certs; чтобы брать файлы по этому пути — используйте source => 'puppet:///modules/certs/certs' (при условии, что окружение ноды — ubuntu_vdi_test).
Введение в Puppet