LINUX.ORG.RU
ФорумAdmin

puppet

 


0

2

всем привет

хочу описать модуль и в ноде «решать» какие части этого модуля будут «работать»:

class myclass {
  service {...}
  file { ... content=>template(blabla.erb), ... }
  package { ... }
}

class myclass::feature1 {
  $myVar = [ 'add this line', 'and second' ]
}

class myclass::feature2 {
  $myVar = [ 'this feature enabled' ]
}

# этих featureX может быть сколько угодно, и хорошо бы чтобы их потом легко можно было добавлять

А в описании хоста могут включаться разные части этого модуля

node "mynode" {
...
  include myclass::feature1
  include myclass::feature2
  include myclass
...
}

blabla.erb выглядит так:

...
<% if @myVar %><% @myVar.each do |var| -%><%= var %>
<% end -%><% end %>
...

такое не работает, потому что переменная myVar описанная в myclass::feature является локальной и не видна в области генерации templat'a =(

подскажите пожалуйста как правильно сделать такое?

спасибо

★★★

Никак, puppet такое не умеет.

Но если очень хочется, можно взять concat модуль и формировать файл фрагментами.

ival ★★
()
Ответ на: комментарий от ival

Никак, puppet такое не умеет

Мне кажется, я видел что-то подобное. Вроде бы в example42, но сейчас не могу найти

router ★★★★★
()

Всё написанное ниже придумано только что и скорее напоминает грязный хак. Я не могу обещать, что ЭТО можно применять в продакшн ;)

modules/myclass/manifests/feature1.pp

class myclass::feature1 {
        $myVar = [ "feature 1 ", "test 1" ]
}
modules/myclass/manifests/init.pp
class myclass {

        if defined( myclass::feature1 ) {
                $myVarF1 = $myclass::feature1::myVar
        } else {
                $myVarF1 = []
        }
        if defined( myclass::feature2 ) {
                $myVarF2 = $myclass::feature2::myVar
        } else {
                $myVarF2 = []
        }
        # Чёрная магия
        # http://www.crobak.org/2011/02/two-puppet-tricks-combining-arrays-and-local-tests/
        # ( мелким шрифтом ) Как и любая чёрная магия, негативно влияет на карму
        $myVar = split(inline_template("<%= ( myVarF1 + myVarF2).join(',') %>"),',')

        # тут использование полученного $myVar
}

router ★★★★★
()
Ответ на: комментарий от router

А вообще мне почему-то кажется, что тут можно применить виртуальные ресурсы. Наверное потому, что я до сих пор не знаю, как их применять :)

Или даже экспортируемые ресурсы, но о них я и думать боюсь

router ★★★★★
()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

Мне кажется, я видел что-то подобное. Вроде бы в example42, но сейчас не могу найти

1) Некоторый задачи не надо решать.

2) Некоторый задачи решаются выкидыванием puppet'а

Смотрел я когда-то на example42. Эти два правила точно про них.

IMHO puppet лучше использовать как средство централизованного раскидывания конфигов.

Писать модули наподобии библиотек-обверток, предоставляющих достаточно полный интерфес к оборачиваемым программам, неоправданно затратно. Правильный подход — писать модули для достаточно целостных конфигураций. Причем рассчитывать, что

1) модули некогда не будут использоваться вне конкретной инфраструктуры/компании

2) Модули пишутся админом прямой правкой конфигов (через предоставление шаблонов)

3) Наружу модуля в качестве параметров вытаскиваются восновном то, что отличает стенд от продакшена. Все остальное безжалостно hardкодится.

Сам я в качестве базиса использую этот самый concat, puppetlabs-stdlib и немножко мелких самописных костылей.

ival ★★
()
Ответ на: комментарий от ival

2) Некоторый задачи решаются выкидыванием puppet'а

Спорно. Это говорит лишь о том, что человек не умеет правильно использовать системы централизованного управления, распределяя изменения только на нужный scope узлов сети.

Если ты администриуешь сеть сервером/ВМ, система централизованного управления должна быть установлена на всех. Аксиома. Если на отдельном узле разработчики занимаются неожиданными вещами или идёт тестирование, то там лишь нужно вмешиваться по минимуму. Может быть, даже вообще отключить все правила. Но не удалять агента puppet/cfengine/chef/hpsa и т.д.

Смотрел я когда-то на example42. Эти два правила точно про них.

Мне тоже не нравится результат. Точнее то, что я его не понимаю полностью. Но при этом видно что парни отлично знают язык puppet'а и у них можно найти полезные идеи

Писать модули наподобии библиотек-обверток, предоставляющих достаточно полный интерфес к оборачиваемым программам, неоправданно затратно.

Рассматривать нужно конкретный случай. Сколько времени займёт разработка, и сколько времени/денег поможет съкономить.

3) Наружу модуля в качестве параметров вытаскиваются восновном то, что отличает стенд от продакшена. Все остальное безжалостно hardкодится.

Ты предлагаешь писать немаштабируемые костыли, которые сложно поддерживать. Я предпочитаю писать модули, которые можно взять и перенести в другую инфраструктуру без изменений кода. При работе в аутсорсинге это экономило огромное количество времени и нервов.

З.Ы. я не настаиваю что предложенный мной вариант решения достаточно удачен. Раз приходится искать способ обмануть синтаксис puppet, это значит что что-то сделано неправильно. Но иногда и неоптимальное решение может быть полезным. Опять же, всё упирается в целесообразность, как ты и сказал

router ★★★★★
()
Ответ на: комментарий от router

З.Ы. у меня в фортунках:

Прежде чем начинать серьёзное и трудное дело, очень полезно провести секретный индейский ритуал нахуа.

Он заключается в том, что индеец со всей серьёзностью спрашивает себя: «Является ли данное занятие выражением глубинных устремлений моего сердца? Буду ли я счастлив, когда буду делать задуманное? Испытаю ли я счастье, когда выполню всё, что задумал?»

Практикуйте нахуа, и трудных и серьёзных дел в вашей жизни станет гораздо меньше. В особо тяжёлых случаях рекомендуется использовать бубен.

-- Индейский ритуал НАХУА

router ★★★★★
()
Ответ на: комментарий от router

Спорно. Это говорит лишь о том, что человек не умеет правильно использовать системы централизованного управления, распределяя изменения только на нужный scope узлов сети.

Имеется ввиду не отказ от централизованного администрирования, а подбор других инструментов. Другой пример на тему: написание сборщика мусора для C++ решается выкидыванием С++.

Если ты администриуешь сеть сервером/ВМ, система централизованного управления должна быть установлена на всех. Аксиома.

Это безусловно так.

Если на отдельном узле разработчики занимаются неожиданными вещами или идёт тестирование, то там лишь нужно вмешиваться по минимуму. Может быть, даже вообще отключить все правила. Но не удалять агента puppet/cfengine/chef/hpsa и т.д.

Ну это понятно. Как разрабатывать это личное дело каждого. Вопрос в том, как потом переносить результаты в production.

Рабочий подход: написать класс, в параметры которого вынесено то, что отличает стенд от боевого применения (адреса сервисов, shared buffers для postgres и т.д). При разворачивание в манифест ноды цепляется этот класс с нужными параметрами. Если нужно что-то поменять: правится модуль, разворачивается на стенд, тестируется, переносится в production. Сами манифесты нодов меняются редко.

Я предпочитаю писать модули, которые можно взять и перенести в другую инфраструктуру без изменений кода. При работе в аутсорсинге это экономило огромное количество времени и нервов.

Или склонировать кусочик своей. Ну не верю я, что на puppet можно писать универсальные модули.

ival ★★
()
Последнее исправление: ival (всего исправлений: 1)

Выкинь puppet, возьми ansible и не страдай.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.