Комментарии 11
hierra — сделай ansible из puppet!
если серьёзно, то для хранения данных hierra очень даже, а вот логику всё таки привычней хранить в манифестах с множественным наследованием. хотя может быть я просто до этого ещё не дорос.
если серьёзно, то для хранения данных hierra очень даже, а вот логику всё таки привычней хранить в манифестах с множественным наследованием. хотя может быть я просто до этого ещё не дорос.
Посмотрите вот эту презентацию с Puppet Conf 2014, там все очень хорошо описано. Хиера должна служить не только местом хранения данных, но и полностью описывать логику вашей инфраструктуры. Я вот добился в своей инфраструктуре того, что манифесты больше не меняю, только добавляю модули/классы и новые данные в Хиеру. Получается довольно просто и масштабируемо. Об этом я хочу написать в следующей статье, эта больше обучающая.
Спасибо за статью, стоит упомянуть возможность использования различных backendов, в том числе gpg для хранения паролей и другой чувствительной информации (ждем следующих статей:).
Также лично я не до конца понимаю зачем переносить в hier'у фактически всю конфигурацию, когда в манифесте остается грустная ссылка на него — зачем? Манифесты на то и были созданы, чтобы описывать конфигурацию, в то время как hiera была создана для хранения данных.
В вашем примере Вы переносите 2 абсолютно независимых ресурса vhost в hiera практически без изменений, не до конца понимаю зачем? В то же время, пример в презентации (кстати с PuppetCamp в Стокгольме) с адресом ntp сервера, который меняется в зависимости от среды, и прочих параметров — считаю очень ярким. Также в этой презентации я как-то с удовольствием почерпнул принцип профилей и ролей, сейчас с большим успехом использую их, таким образом спасаясь от дупликации и spaghetti-code.
Наверняка я чего-то недопонимаю, расскажите пожалуйста поподробнее о том «как было раньше» и «как стало после внедрения hiera, в качестве системы хранения конфигов».
Еще раз спасибо!
Также лично я не до конца понимаю зачем переносить в hier'у фактически всю конфигурацию, когда в манифесте остается грустная ссылка на него — зачем? Манифесты на то и были созданы, чтобы описывать конфигурацию, в то время как hiera была создана для хранения данных.
В вашем примере Вы переносите 2 абсолютно независимых ресурса vhost в hiera практически без изменений, не до конца понимаю зачем? В то же время, пример в презентации (кстати с PuppetCamp в Стокгольме) с адресом ntp сервера, который меняется в зависимости от среды, и прочих параметров — считаю очень ярким. Также в этой презентации я как-то с удовольствием почерпнул принцип профилей и ролей, сейчас с большим успехом использую их, таким образом спасаясь от дупликации и spaghetti-code.
Наверняка я чего-то недопонимаю, расскажите пожалуйста поподробнее о том «как было раньше» и «как стало после внедрения hiera, в качестве системы хранения конфигов».
Еще раз спасибо!
Да, вы правы, простое копирование информации из манифестов в Хиеру не приносит много пользы в больших инфраструктурах. Цель данной статьи была показать на что вообще способна Хиера. Использование профилей и серверных ролей — это уже тема следующей статьи.
Как стало? Стало вообще просто. Хиера стала хранилищем трех вещей: сервер, группа серверов и роль. Вся нагрузка легла на модули и классы. В манифесте практически пусто, в Хиере — ненамного больше. Классов стало гораздо больше, как и гибкости. В целом стало все намного проще и сразу ясно, где что лежит.
Как стало? Стало вообще просто. Хиера стала хранилищем трех вещей: сервер, группа серверов и роль. Вся нагрузка легла на модули и классы. В манифесте практически пусто, в Хиере — ненамного больше. Классов стало гораздо больше, как и гибкости. В целом стало все намного проще и сразу ясно, где что лежит.
Не сказано главного — автолукап переменных.
Например, есть класс
Можно в hiera написать
И значение blabla подставится в параметр. Причём будет работать даже при неявном вызове
Например, есть класс
class main::child ( $mysvar ) {
...
}
node 'mynode.domain.com' {
include main::child
}
Можно в hiera написать
main::child::mysvar: blabla
И значение blabla подставится в параметр. Причём будет работать даже при неявном вызове
class main::child ( $mysvar ) {
...
}
class main::child1 {
include main::child
...
}
node 'mynode.domain.com' {
include main::child1
}
Чем-то напоминает attributes в Chef, для них тоже разного рода priority lookups (и совсем немного — напоминает data bags).
Реализовать что-то подобное можно и в chef, причем не менее гибко.
Для этого например можно заиметь кубкук с yaml-файлами, который на этапе компиляции будет скачиваться:
а потом в libraries через обычный YAML.load_file мержиться с аттрибутами ноды через Chef::Mixin::DeepMerge в зависимости от node.fqdn, node.chef_environment, cookbook_name и тд и тп.
Для этого например можно заиметь кубкук с yaml-файлами, который на этапе компиляции будет скачиваться:
# cookbook/hiera/recipes/default.rb
remote_directory '/etc/hiera' do
source 'yml'
recursive true
purge true
overwrite true
end.run_action(:create)
а потом в libraries через обычный YAML.load_file мержиться с аттрибутами ноды через Chef::Mixin::DeepMerge в зависимости от node.fqdn, node.chef_environment, cookbook_name и тд и тп.
Спасибо за статью.
Теперь понял нафига оно используется.
С весны поднял Foreman и разбираюсь с ним. Мне он больше нравится — web+provisioning+группы+отчёты. Понятно, что hiera это типа Unixway, но вот представил, что это нужно постоянно текстовые файлики лопатить. Не факт ещё, что задуманная инфраструктура будет сходиться с реальной.
Не не не, лучше фореман.
Теперь понял нафига оно используется.
С весны поднял Foreman и разбираюсь с ним. Мне он больше нравится — web+provisioning+группы+отчёты. Понятно, что hiera это типа Unixway, но вот представил, что это нужно постоянно текстовые файлики лопатить. Не факт ещё, что задуманная инфраструктура будет сходиться с реальной.
Не не не, лучше фореман.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Puppet. Часть 1: введение в Hiera