Как избежать повторения себя в объявлениях классов для кукольных узлов?

Question

В принципе, я считаю себя делать то же самое объявление долгое время учащемуся каждый раз:

node 'gluster3redis097.myservice.com' { 
    class { 'redis' : 
     class {'invoke' : } 
     class {'users' : } 
     class {'redis' : 

     package_ensure  => '3.0.5', 

     #extra_config_file => '/etc/redis.d/redis-gluster3-master.conf', 
     daemonize    => 'yes', 
     pid_file    => '/var/run/redis.pid', 
     log_level    => 'notice', 
     log_file    => '/var/log/redis/redis.log', 
     #save_db_to_disk  => false, 
     workdir    => './', 
     bind     => $::ipaddress, 
     slaveof     => "${$gluster3redis_master_ips[37]}:6379", 
     slave_serve_stale_data => true, 
     # 2015.12.01 nathan Do not allow inadvertent writes to the slave 
     slave_read_only  => true, 
     repl-diskless-sync-delay => '5', 
     repl-ping-slave-period => '10', 
... and so on ... 
... and so forth ... 

Предположим, для этого кластера, каждый ПЯТЫЙ узел имеет отдельный мастер.

Итак, угадайте, какая часть изменяется?

slaveof     => "${$gluster3redis_master_ips[37]}:6379", 

Там должен быть лучший способ.
- Покахонтас (1995) 1

Согласно https://docs.puppetlabs.com/puppet/latest/reference/lang_node_definitions.html#multiple-names, это плохая идея использовать кукольный inherits ключевое слово.

Плюс, к моему ужасу, в https://docs.puppetlabs.com/puppet/latest/reference/lang_node_definitions.html#aside-best-practices, они описывают следующие рекомендации:

Помимо: Best Practices

Хотя узел заявление может содержать практически любой код кукольного, мы рекомендуем что вы используете их только для установки переменных и объявления классов. Избегайте использования объявлений ресурсов, коллекционеров, условных операторов, цепочки отношений и функций в них; все они принадлежат классам или определенным типам. Это упростит переход между определениями узлов и ENC. 2

Могу я определить нестандартный тип?

Я прочитал How to pass node specific information to class in puppet?, но я не уверен, что он спрашивает то же, что и я, и хотя я совершенно готов узнать, как определить типы, я не знаком с ними достаточно, чтобы решить, идти по этому маршруту.

Как я могу избегать повторения себя с каждым определением определения кукольного узла, как это для этого кластера Redis?

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

ОБНОВЛЕНИЕ: Применение общей конфигурации с использованием Hiera с помощью файла common.yaml для этого набора сред, похоже, сработало. Далее я расскажу об этом в ответ, если Дэн Боулинг не будет его добровольно участвовать.

Answer 1

Вот более вымываются ответ на комментарий я изначально размещены:

Каждый раз, когда вы оказываетесь повторно объявить параметры как параметры класса, Hiera должны быть рассмотрены. Из документов:

Hiera - это инструмент поиска ключей/значений для данных конфигурации, созданный для того, чтобы сделать Puppet лучше, и позволяет вам устанавливать специфичные для узла данные, не повторяя себя.

Ваш первый шаг - идентифицировать иерархию, поскольку Hiera будет использовать эту иерархию для поиска соответствующего значения запрошенного ключа. В вашем примере нужна простая иерархия. Вот пример hiera.yaml конфигурационный файл:

:backends: 
    - yaml 

:hierarchy: 
    - "node/%{::hostname}" 
    - "common" 

:yaml: 
    :datadir: '/your/hiera/data/directory' 

:merge_behavior: deeper  

О выше конфигурации:

1. Hiera будет выглядеть в /your/hiera/data/directory/node/nodehostname.yaml для значения первого. Здесь вы можете определить конфигурации для каждого хоста.
2. Для всех остальных значений, Hiera вернется к значению по умолчанию common.yaml в /your/hiera/data/directory/node/common.yaml

Итак, ваш common.yaml может выглядеть следующим образом:

redis::package_ensure: '3.0.5' 
redis::pid_file: '/var/run/redis.pid' 

И вы будете иметь узел {1,2} с это /your/hiera/data/directory/node/node{1,2}.yaml:

redis::slaveof: 'your redis master value' 

и узел {3,4} будет иметь этот /your/hiera/data/directory/node/node{3,4}.yaml:

redis::slaveof: 'your other redis master value' 

:merge_behavior: deeper в hiera.yaml полезно, если вы хотите объединить настройки на различных уровнях иерархии или объединить сложные хэшей в отдельные значения. Для получения дополнительной информации см. Hiera Lookup Types.