Comments 21
Хиера — это жалка попытка сделать папет хоть сколько нибудь удобным и похожим на ansible, где все это из коробки. Ну и расскажите лучше про боль миграции с 3 на 4, что бы никто и когда не вздумал использовать это днище в реальных проектах.
Простите, но говорить про миграции между версиями, сравнивая с ансиблом, где совместимость в модулях часто теряется даже при изменении минорной версии…
Это мелочи по сравнению с тем что вас ждет в папете.
В ansible 99% апгрейдов все же проходит без проблем. А когда они есть, время на их решение редко превышает 30 минут. В папете переехать с 3 на 4 — это переписать все и сразу. DSL и так не отличается строгостью, а с двумя версиями это все превращается в бесконечный фарш. Модули в папете даже которые идут в поставке очень низкого качества. В ansible же опять же почти всегда все работает из коробки.
В ansible 99% апгрейдов все же проходит без проблем. А когда они есть, время на их решение редко превышает 30 минут. В папете переехать с 3 на 4 — это переписать все и сразу. DSL и так не отличается строгостью, а с двумя версиями это все превращается в бесконечный фарш. Модули в папете даже которые идут в поставке очень низкого качества. В ansible же опять же почти всегда все работает из коробки.
Ансибл хорош для маленькой команды и небольшого количества серверов. Когда серверов сотни и тысячи, а команда — десятки человек, все несколько иначе. Использовал и паппет (помнится, еще второй, а потом третий), и ансибл — разные масштабы, разные подходы. И если паппет в маленьком окружении будет так же эффективен, то ансибл в масштабах большого проекта уже нет.
Я уже не говорю о зависимостях ансибла от версии питона, зависимостях и самом лютом цирке в виде ансибла под windows, когда поведение модуля различается чуть ли не в десятке разных минорных версий ага.
Я уже не говорю о зависимостях ансибла от версии питона, зависимостях и самом лютом цирке в виде ансибла под windows, когда поведение модуля различается чуть ли не в десятке разных минорных версий ага.
Вы сравниваете системы с абсолютно разным подходом.
В одних случаях хорош паппет, в других ансибл. И говорить что одно есть жалкое подобие другого по меньшей мере некорректно.
Я бы сказал, что обе системы не лишены недостатков, но и серебряной пули тоже нет.
А можете выложить весь /etc/puppet?
Что вы имеете ввиду?
С настройками сервера и структурой коталогов на уровень выше для большей наглядности. Куда это ложить? Просто в каталог code? Где-то дополнительно надо что-то настраивать? Пользуюсь puppet без hiera, структура просто описана в site.pp — модули, ноды, манифесты. Читая статьи про хиеру чувствую себя безнадежно отставшим, хочу попробовать.)
Это очень частный случай получится, если весь наш паппет выложить)))
Может есть смысл просто рассказать чуть подоробнее про настройку взаимодействия хиеры и паппета, но мне кажется такие статьи тут уже были.
У нас похожая система, puppet + git + r10k + hiera + hiera-file, последние позволяют вынести все секреты из кодовой базы puppet и проводит ревью кода без «секретности».
Отказ от собственных велосипедов и переход на upstream модуля одно из лучших решений (по опыту). НО… удаленные модули работают, пока работают.
Перестают работать в самый не подходящий момент.
Напоролись на это. Сейчас все модули коммитятся локально и обновляются периодически после тестовой прогонкой новых версий.
Вопрос в массы… Подскажите рабочий вариант сдружить r10k с gerrit reviews для возможности дальнейший puppet apply --environment=gerrit_review_42 (сейчас приходится пушить ветки на git для r10k).
P.S. настоятельно рекомендую github.com/github/octocatalog-diff (сразу видно что и где зацепит изменение прямо в ревью перед сабмитом).
Отказ от собственных велосипедов и переход на upstream модуля одно из лучших решений (по опыту). НО… удаленные модули работают, пока работают.
Перестают работать в самый не подходящий момент.
Напоролись на это. Сейчас все модули коммитятся локально и обновляются периодически после тестовой прогонкой новых версий.
Вопрос в массы… Подскажите рабочий вариант сдружить r10k с gerrit reviews для возможности дальнейший puppet apply --environment=gerrit_review_42 (сейчас приходится пушить ветки на git для r10k).
P.S. настоятельно рекомендую github.com/github/octocatalog-diff (сразу видно что и где зацепит изменение прямо в ревью перед сабмитом).
Спасибо за инфу, про hiera-file почитаю, как и про octocatalog-diff.
У нас проблема с модулями решается тем, что в Puppetfile для всех удаленных модулях мы указываем требуемую версию модуля. Это несколько нивелирует мои высокопарные фразы про то, что удаленные модули круто использовать, потому что они обновляются, но такова жизнь) Просто если что-то сломалось (обновили ОС на сервере), можно удобно глянуть в проект модуля и понять, был ли пофикшен какой-то баг. И если да, обновить версию модуля (проверив перед этим все конечно).
У нас проблема с модулями решается тем, что в Puppetfile для всех удаленных модулях мы указываем требуемую версию модуля. Это несколько нивелирует мои высокопарные фразы про то, что удаленные модули круто использовать, потому что они обновляются, но такова жизнь) Просто если что-то сломалось (обновили ОС на сервере), можно удобно глянуть в проект модуля и понять, был ли пофикшен какой-то баг. И если да, обновить версию модуля (проверив перед этим все конечно).
>… в Puppetfile для всех удаленных модулях мы указываем требуемую версию модуля…
Проблема не в версии, а в недоступности удаленного ресурса на момент восстановления локально утерянной ноды. Вся инфраструктура у нас покрыта «disaster recovery plan». Все узлы восстанавливаются каждую ночь в автоматическом режиме в тестовом окружении (по одному инстансу каждого типа). В этом случае все внешние зависимости являются точкой потенциального отказа, что происходит как минимум раз в квартал по разным причинам. Слава богу у нас нету роскомпозора с блокиратором, но github/puppet-lab бывают недоступны, последний раз из-за DDOS. Ну и habr.com/post/280039 никто не отменял.
Проблема не в версии, а в недоступности удаленного ресурса на момент восстановления локально утерянной ноды. Вся инфраструктура у нас покрыта «disaster recovery plan». Все узлы восстанавливаются каждую ночь в автоматическом режиме в тестовом окружении (по одному инстансу каждого типа). В этом случае все внешние зависимости являются точкой потенциального отказа, что происходит как минимум раз в квартал по разным причинам. Слава богу у нас нету роскомпозора с блокиратором, но github/puppet-lab бывают недоступны, последний раз из-за DDOS. Ну и habr.com/post/280039 никто не отменял.
Я писала костыль на Python, перегенерирующий PuppetFile с репозиториев удалённых и локальных, на только локальные (в которые предварительно синкает код)
Звучит как оверкил, но я не знаю вашу религию.
У нас модули появляются/удаляются в среднем раз в две недели (причем это среднее с учетом рефакторингов и месячного затишья). Так как задействование нового модуля это коммит, то предшествующий коммит является импортом модуля и выполняется в ручном режиме (с указанием URL откуда модуль пришел, версии, commit id, ...). В этом коммите мы удаляем ненужные _нам_ запчасти (примеры, demo, тесты...). Это позволяет легко в дальнейшем обновлять модуля (так как есть все детали откуда он пришел и как менялся нами, если требовал фиксов, костылей) и также делает общий размер puppet envorinment меньше процентов на 50% что ускоряет r10k. Многие puppet модули содержат очень много ненужного в ежедневном использовании «мусора».
Побочным моментом тут является core review для нового модуля, которое хотя-бы поверхностно, позволяет понять что же мы там подключаем и пару раз завернуло некоторые модули. Один был слишком страшный и опасный внутри, во втором случае вопрос решался и без модуля.
Так же периодически проводятся апдейты закоммиченных модулей, octocatalog-diff показывает будут ли изменения после апдейта модуля, если не булет — все легко и просто, если будут — нужно смотреть что же там поменяется.
У нас модули появляются/удаляются в среднем раз в две недели (причем это среднее с учетом рефакторингов и месячного затишья). Так как задействование нового модуля это коммит, то предшествующий коммит является импортом модуля и выполняется в ручном режиме (с указанием URL откуда модуль пришел, версии, commit id, ...). В этом коммите мы удаляем ненужные _нам_ запчасти (примеры, demo, тесты...). Это позволяет легко в дальнейшем обновлять модуля (так как есть все детали откуда он пришел и как менялся нами, если требовал фиксов, костылей) и также делает общий размер puppet envorinment меньше процентов на 50% что ускоряет r10k. Многие puppet модули содержат очень много ненужного в ежедневном использовании «мусора».
Побочным моментом тут является core review для нового модуля, которое хотя-бы поверхностно, позволяет понять что же мы там подключаем и пару раз завернуло некоторые модули. Один был слишком страшный и опасный внутри, во втором случае вопрос решался и без модуля.
Так же периодически проводятся апдейты закоммиченных модулей, octocatalog-diff показывает будут ли изменения после апдейта модуля, если не булет — все легко и просто, если будут — нужно смотреть что же там поменяется.
Как вы решаете вопрос с последовательностью выполнения инструкций в манифестах?
require например? ->, before, notify, subscribe. Но вообще стоит смотреть конкретный случай.
Можно использовать коллекторы ресурсов , или, как сказал выше tamaki, require, before, after и т.д.
Но с коллекторами надо быть аккуратным, благодаря ним можно попасть в dependency loop.
Даже в картинке выше указана данная проблема в шуточной форме: пакеты приехали раньше репозиториев. Но, на мой взгляд, это не прям уж критично. Ну попытается пакет поставиться до накатки репозитория, один run зафейлится, в следующий все ок будет. При фейле паппет же не прекращает работу, а продолжает применять оставшуюся часть каталога.
Мы не используем паппет в виде демона, а запускаем его по крону. Грубо говоря, реальные ошибки по неправильным последовательностям применения ресурсов может быть только при первоначальном сетапе сервера и последующего первого запуска паппета. Сервера деплоятся автоматически, паппет на них первый раз запускается тоже «сам». В течение 20 минут он гарантированно разрулит все фейлы и применит-таки конфигурацию, запустившись пару раз по крону.
Но с коллекторами надо быть аккуратным, благодаря ним можно попасть в dependency loop.
Даже в картинке выше указана данная проблема в шуточной форме: пакеты приехали раньше репозиториев. Но, на мой взгляд, это не прям уж критично. Ну попытается пакет поставиться до накатки репозитория, один run зафейлится, в следующий все ок будет. При фейле паппет же не прекращает работу, а продолжает применять оставшуюся часть каталога.
Мы не используем паппет в виде демона, а запускаем его по крону. Грубо говоря, реальные ошибки по неправильным последовательностям применения ресурсов может быть только при первоначальном сетапе сервера и последующего первого запуска паппета. Сервера деплоятся автоматически, паппет на них первый раз запускается тоже «сам». В течение 20 минут он гарантированно разрулит все фейлы и применит-таки конфигурацию, запустившись пару раз по крону.
А каким образом факты team, project, tier, role — попадают на сервер? Используете кастомные факты? Если да, то на основе каких данных вы формируете указанные вами факты?
Мне очень интересно узнать, так как я тоже формирую кастомные факты group, subgroup на основе hostname. Например если имя сервера php10-1.example.com, то group = php, subgroup = 10.
Мне очень интересно узнать, так как я тоже формирую кастомные факты group, subgroup на основе hostname. Например если имя сервера php10-1.example.com, то group = php, subgroup = 10.
Кастомные файлы можно создавать как при сетапе сервера (мы используем Maas), так и руками.
Да, мы используем кастомные факты. В папку /opt/puppetlabs/facter/facts.d/ кладутся файлы типа /opt/puppetlabs/facter/facts.d/team.txt с содержимым:
Кроме того, факты можно задать непосредственно через запуск паппет агента:
Тогда агент при прогоне сам создаст нужный файл факта и применит соотвествующую конфигурацию.
Данные факты мы выставляем не на основе fqdn, как вы, а в соответствии с:
— какой команде делаем сервер?
— что это за проект? (если есть)
— какая роль у сервера? (если есть)
— какой стейджинг? (если нужно и есть)
Ну то есть мы это узнаем у заказчиков серверов, либо делаем новую иерархию, если до этого подобное не описывалось.
Да, мы используем кастомные факты. В папку /opt/puppetlabs/facter/facts.d/ кладутся файлы типа /opt/puppetlabs/facter/facts.d/team.txt с содержимым:
team=adminКроме того, факты можно задать непосредственно через запуск паппет агента:
FACTER_team=admin puppet agent -tТогда агент при прогоне сам создаст нужный файл факта и применит соотвествующую конфигурацию.
Данные факты мы выставляем не на основе fqdn, как вы, а в соответствии с:
— какой команде делаем сервер?
— что это за проект? (если есть)
— какая роль у сервера? (если есть)
— какой стейджинг? (если нужно и есть)
Ну то есть мы это узнаем у заказчиков серверов, либо делаем новую иерархию, если до этого подобное не описывалось.
Sign up to leave a comment.
Puppet+Hiera. Выжимаем максимум