Конфигурирование puppetdb модуль в использовании Марионетки Hiera

Чтобы Puppet мог искать параметры класса в Hiera (что он делает по умолчанию, начиная с 3.0.0), эти параметры должны быть указаны как простые пары ключ-значение, а не как сложные типы данных.

Это как указать параметр datadir класса postgresql :: server в модуле puppetlabs-postgresql , чтобы указать на альтернативный каталог данных для Postgres:

# /etc/puppet/hieradata/foo.example.com.yaml
---
# Puppet automatically looks here for parameters when applying the class postgresql::server
postgresql::server::datadir: /srv/postgres/main

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

Итак, вы либо параметризуете свою роль: postgresql_puppetdb , чтобы вы могли передавать ему параметры класса, которые, в свою очередь, передаются в объявления postgresql :: server :: config_entry , или вы используете функцию create_resources () вместе с помощью hiera_array () или hiera_hash () , чтобы найти настройки конфигурации Postgres, которые вы хотите применить.

Пример для первого подхода:

class role::postgresql_puppetdb (
  wal_level => 'minimal'
  ...
) {

  class { 'postgresql':
     ...
  }

  class { 'puppetdb':
     ...
  }

  postgresql::server::config_entry { 'wal_level':
    value => $role::postgresql_puppetdb::wal_level
  }
}

И затем в Hiera.

# /etc/puppet/hieradata/foo.example.com.yaml
---
role::postgresql_puppetdb::wal_level: hot_standby

Это, очевидно, немного негибко, так как вам необходимо предоставить доступ к каждому настраиваемому параметру и настройке конфигурации, которые предоставляет класс postgresql через ваш класс role :: postgresql_puppetdb . Конечно, этого может быть достаточно для вас, если вы знаете, что вам нужно открыть только несколько таких настроек.

Пример второго подхода:

class role::postgresql_puppetdb {

  class { 'postgresql':
     ...
  }

  class { 'puppetdb':
     ...
  }

  $postgres_config_entries = hiera_hash('postgres_configs', {})

  create_resources('postgresql::server::config_entry', $postgres_config_entries)

}

Затем в Hiera:

# /etc/puppet/hieradata/foo.example.com.yaml
---
postgres_configs:
  wal_level:
    value: hot_standby
  authentication_timeout:
    value: 120s
  krb_server_keyfile:
    value: /var/lib/postgresql/postgresql.keytab

И так далее. Это более гибко и позволяет вам устанавливать произвольные параметры Postgres на каждом уровне иерархии, который вы хотите. В этом случае, конечно, с Hiera будут обращаться к этим параметрам конфигурации только тогда, когда включен класс role :: postgresql_puppetdb , но ничто не мешает вам поместить эту комбинацию hiera_hash-create_resources в другие роли, возможно, в role :: postgresql .

Надеюсь, это было понятно и достаточно логично, чтобы следовать. Вышеупомянутое, конечно, не проверено, как и опубликованное, но мы используем именно эту стратегию (create_resources, hiera_hash) для управления локальными и системными учетными записями, репозиториями, правилами sudoers, экземплярами Tomcat и другими. Вернусь к этому вопросу завтра, когда буду меньше уставать.

Но посмотрите на этот отличный вопрос на Puppet-Ask: https: //ask.puppetlabs. com / question / 1655 / an-end-to-end-roleprofile-example-using-hiera /

Он проходит через аналогичную настройку на основе HAproxy. Очень полезно понять.