Мне интересно, каковы лучшие практики для переопределения переменных в марионетке. Я бы хотел, чтобы все мои узлы (которые расположены в разных местах, некоторые из них qa, некоторые живые) были с одинаковыми классами. Теперь у меня примерно так:
class base_linux {
<...> # something which requires $env and $relayhost variables
}
class linux_live {
$relayhost="1.1.1.1"
$env = "prod"
include base_linux
}
class linux_qa {
$relayhost="2.2.2.2" # override relayhost
include base_linux
}
class linux_trunk {
$env = "trunk" # override env
inlude linux_qa
}
node "trunk01" {
include linux_trunk
include <something else>
}
node "trunk02" {
$relayhost = "3.3.3.3" # override relayhost
include linux_trunk
include <something else>
}
node "prod01" {
include linux_prod
}
Итак, я хотел бы иметь некоторые значения по умолчанию в base_linux, которые можно переопределить с помощью linux_qa / linux_live, которые можно переопределить в классах более высокого уровня и определении узла.
Конечно, это не работает (и не ожидается). Он также не работает с наследованием классов. Возможно, я смогу архивировать, используя глобальные переменные области видимости, но мне это не кажется хорошей идеей.
Как лучше всего решить эту проблему?
Лучшая практика зависит от количества узлов / систем, которыми вы управляете. Моделирование данных в марионеточных манифестах достаточно, если вы можете отслеживать данные (я видел, как это делалось с тысячами систем, однако это становится сложной задачей, если у вас есть большое количество переменных и глубокое наследование, особенно если вы начинаете ссылаться на такие области, как как $ value = $ some_class :: some_var). Если у вас сложная инфраструктура, имеет смысл рассмотреть возможность отделения данных от марионеточных манифестов с помощью extlookup, heira или классификатора внешних узлов (ENC).
То, как вы сделали это в манифестах марионетки, - это использование динамической области видимости и наследования узлов, а динамическая область видимости устарела в Puppet 2.7. Если это переписать в extlookup, это будет просто:
# configured globally
# linux_qa is more likely linux_%{env}
$extlookup_precedence = ["%{fqdn}", "linux_trunk", "linux_qa", "common"]
# in the appropriate class
$relayhost = extlookup("relayhost")
Кажется, я нашел хороший способ сделать это: вместо определения переменных в классах лучше создавать шаблоны узлов только для переменных. Итак, я получил что-то вроде следующего:
node basenode {
}
node linux_prod inherits basenode {
$relayhost="1.1.1.1"
$env = "prod"
}
node linux_qa inherits basenode {
$relayhost="2.2.2.2"
}
node linux_trunk inherits linux_qa {
$env = "trunk"
}
class base_linux {
# no valuables defined here
<...>
}
node trunk01 inherits linux_trunk {
$relayhost = "3.3.3.3" # I can override here for single node
include base_linux
}
Мое собственное предложение - не помещать переменные в классы - только если этому классу нужно что-то переопределить.
Поместите свои переменные в site.pp (или какой-нибудь импортированный файл - я называю свой globals.pp), поместите правила, чтобы различать, какие значения они должны там иметь - выбирайте вместо переопределения. Затем вы можете выполнять индивидуальные переопределения для узлов или классов по своему усмотрению.