Комментарии 11
hierra — сделай ansible из puppet!

если серьёзно, то для хранения данных hierra очень даже, а вот логику всё таки привычней хранить в манифестах с множественным наследованием. хотя может быть я просто до этого ещё не дорос.
Посмотрите вот эту презентацию с Puppet Conf 2014, там все очень хорошо описано. Хиера должна служить не только местом хранения данных, но и полностью описывать логику вашей инфраструктуры. Я вот добился в своей инфраструктуре того, что манифесты больше не меняю, только добавляю модули/классы и новые данные в Хиеру. Получается довольно просто и масштабируемо. Об этом я хочу написать в следующей статье, эта больше обучающая.
Спасибо за статью, стоит упомянуть возможность использования различных backendов, в том числе gpg для хранения паролей и другой чувствительной информации (ждем следующих статей:).

Также лично я не до конца понимаю зачем переносить в hier'у фактически всю конфигурацию, когда в манифесте остается грустная ссылка на него — зачем? Манифесты на то и были созданы, чтобы описывать конфигурацию, в то время как hiera была создана для хранения данных.

В вашем примере Вы переносите 2 абсолютно независимых ресурса vhost в hiera практически без изменений, не до конца понимаю зачем? В то же время, пример в презентации (кстати с PuppetCamp в Стокгольме) с адресом ntp сервера, который меняется в зависимости от среды, и прочих параметров — считаю очень ярким. Также в этой презентации я как-то с удовольствием почерпнул принцип профилей и ролей, сейчас с большим успехом использую их, таким образом спасаясь от дупликации и spaghetti-code.

Наверняка я чего-то недопонимаю, расскажите пожалуйста поподробнее о том «как было раньше» и «как стало после внедрения hiera, в качестве системы хранения конфигов».

Еще раз спасибо!

Да, вы правы, простое копирование информации из манифестов в Хиеру не приносит много пользы в больших инфраструктурах. Цель данной статьи была показать на что вообще способна Хиера. Использование профилей и серверных ролей — это уже тема следующей статьи.
Как стало? Стало вообще просто. Хиера стала хранилищем трех вещей: сервер, группа серверов и роль. Вся нагрузка легла на модули и классы. В манифесте практически пусто, в Хиере — ненамного больше. Классов стало гораздо больше, как и гибкости. В целом стало все намного проще и сразу ясно, где что лежит.
Не сказано главного — автолукап переменных.

Например, есть класс
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-файлами, который на этапе компиляции будет скачиваться:

# 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 и тд и тп.
ну ок, можно просто добавить в каждый кубкук:
if node.fqdn ~= /^rack-(\d+)-(\d+).+$/
  Chef::Mixin::DeepMerge.merge(GetDataBag("$1-$2.bla-bla"), node.attributes)
end
Спасибо за статью.
Теперь понял нафига оно используется.
С весны поднял Foreman и разбираюсь с ним. Мне он больше нравится — web+provisioning+группы+отчёты. Понятно, что hiera это типа Unixway, но вот представил, что это нужно постоянно текстовые файлики лопатить. Не факт ещё, что задуманная инфраструктура будет сходиться с реальной.
Не не не, лучше фореман.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.