Я пытаюсь установить Модуль PuppetDB. Часть этого включает модуль для установки некоторых необходимых экземпляров Postgres, которые я тоже использую.
В основном мы используем heira для настройки ролей и установки различных свойств.
У меня есть конфигурация достаточно долго, чтобы, если я добавлю
roles:
- role::postgresql_puppetdb
Для файла hostnames hiera yaml он будет взят, и будет вытолкнут базовый экземпляр postgres.
Я застрял на установке определенных переменных postgresql.conf. Например я пробовал
roles:
- role::postgresql_puppetdb
- wal_level: hot_standby
Однако это происходит при последующем запуске агента.
Я надеюсь, что кто-то мог попытаться смоделировать конфигурации PuppetDB таким образом и указать, что я делаю неправильно.
Чтобы 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 нет способа поиска параметров типа, который работает только для параметров класса.
Так что либо вы параметризуете свой role::postgresql_puppetdb
class, чтобы вы могли передавать ему параметры класса, которые, в свою очередь, передаются в 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 } }
А потом в Хиере.
# /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) }
Затем в Хиере:
# /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. Очень полезно понять.