У меня есть марионеточный модуль для установки нескольких ПУ Gigaspaces. У каждого из них есть несколько переменных, которые нужно поместить в шаблоны файлов конфигурации. Мы также используем несколько разных сред, поэтому эти переменные повторяются несколько раз, чтобы содержать значения для каждой среды.
Мой вопрос: где лучше всего хранить эти переменные? Свой собственный класс, импортируемый мной внешний .pp или что-то еще?
Я большой поклонник использования классификатор внешнего узла для установки variable=value на верхнем уровне. Таким образом, вы можете использовать реальное хранилище данных и логику программирования, чтобы определить, какими должны быть значения для данного узла, вместо того, чтобы складывать кучу условных выражений на языке марионеток в беспорядочную variables.pp тип файла. Наследование и область видимости - это две большие области в Puppet, которые работают не так, как ожидают многие, и действительно имеют свои собственные предостережения и проблемы, даже если вы знаете, чего ожидать; без внешних узлов вам понадобится один или оба.
Принцип работы классификатора внешнего узла заключается в том, что вы настраиваете puppet.conf своего Puppetmaster для его запуска:
[master]
node_terminus = exec
external_nodes = /path/to/my/classifier.rb
Мастер выполняет его каждый раз, когда клиент подключается с помощью аргумента командной строки имени сертификата подключающегося клиента. Ваш код делает все, что вам нужно, и возвращает YAML со списком classes: который должен быть включен для узла и список parameters: которые устанавливаются как переменные верхнего уровня для использования в манифестах и шаблонах.
В каталоге ext / исходного дистрибутива есть несколько примеров классификаторов. Это отличный способ решить проблему «Разумные настройки по умолчанию, плюс переопределения там, где они нужны».
Многое из того, о чем вы спрашиваете, сводится к соглашению, а не к строгим языковым требованиям ... Язык достаточно гибкий, чтобы делать что-то разными способами.
Если все серверы настроены одинаково, должно быть нормально иметь один класс «gigaspace» с переменными, установленными наверху.
Если ваши потребности более сложны, чем отдельный класс сервера, я бы создал модуль «gigaspace» с общим классом, содержащим переменные, унаследованные классами, которым требуются переменные. В gigaspace / manifest будет "init.pp", содержащий "class gigaspace {...}", а затем" common.pp ", содержащий"class gigaspace::common {...}". Затем в любом классе, которому мне нужен был доступ к этим переменным, я бы унаследовал от общего класса, например"class gigaspace::master inherits gigaspace::common { ... }".
Если вы не унаследованы от другого класса, будет сложно добраться до переменных в другом классе, особенно внутри шаблона. Однако с прямым включением вы можете получить доступ только для чтения, указав полное имя.
Обычно я даю две рекомендации по этому поводу. Один из них - использовать внешний классификатор узлов, как предложил Эрик Соренсон. Другой - использовать extlookup. Extlookup прост в использовании и в комплекте с марионеткой начиная с версии 2.6.1. Я был доволен этим.
У вас может быть манифест variables.pp внутри вашего модуля, который вызывается другими вашими модулями. Это самое обычное, что я видел. Что касается переменных среды, я хотел бы взглянуть на некоторые факты и посмотреть, сможете ли вы их использовать. Если вы можете опубликовать пример своего модуля, я смогу дать более подробную информацию.