Назад | Перейти на главную страницу

Puppet: лучшие практики переопределения переменных

Мне интересно, каковы лучшие практики для переопределения переменных в марионетке. Я бы хотел, чтобы все мои узлы (которые расположены в разных местах, некоторые из них 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), поместите правила, чтобы различать, какие значения они должны там иметь - выбирайте вместо переопределения. Затем вы можете выполнять индивидуальные переопределения для узлов или классов по своему усмотрению.