Para que o Puppet pesquise parâmetros de classe no Hiera (o que ele faz por padrão desde a 3.0.0), esses parâmetros precisam ser especificados como pares de valor-chave simples, não tipos de dados complexos.
É assim que você especificaria o parâmetro datadir
da classe postgresql::server
no módulo puppetlabs-postgresql
para apontar para um diretório de dados alternativo para o 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
No entanto, acho que não é isso que você precisa no seu caso. Você deseja especificar os parâmetros de configuração do Postgres, para os quais você precisa usar o tipo postgresql::server::config_entry
defined. Não há atualmente nenhuma maneira de procurar parâmetros de tipo no Hiera, que só funciona para parâmetros de classe.
Portanto, você parametriza sua classe role::postgresql_puppetdb
para poder passar parâmetros de classe a ela, que por sua vez são alimentados em declarações postgresql::server::config_entry
, ou use a função create_resources()
junto com hiera_array()
ou hiera_hash()
para procure as configurações do Postgres que você deseja aplicar.
Um exemplo para a primeira abordagem:
class role::postgresql_puppetdb ( wal_level => 'minimal' ... ) { class { 'postgresql': ... } class { 'puppetdb': ... } postgresql::server::config_entry { 'wal_level': value => $role::postgresql_puppetdb::wal_level } }
E depois em Hiera.
# /etc/puppet/hieradata/foo.example.com.yaml --- role::postgresql_puppetdb::wal_level: hot_standby
Isso é obviamente um pouco inflexível, já que você precisa expor todos os parâmetros ajustáveis e configurações que a classe postgresql
fornece através da sua classe role::postgresql_puppetdb
também. É claro que isso pode ser suficiente para você, se você sabe que precisa expor apenas alguns ajustes como este.
Um exemplo para a segunda abordagem:
class role::postgresql_puppetdb { class { 'postgresql': ... } class { 'puppetdb': ... } $postgres_config_entries = hiera_hash('postgres_configs', {}) create_resources('postgresql::server::config_entry', $postgres_config_entries) }
Então em 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
E assim por diante. Isso é mais flexível e permite que você defina parâmetros arbitrários do Postgres em cada nível de hierarquia desejado. Nesse caso, é claro, o Hiera só será consultado para essas configurações quando a classe role::postgresql_puppetdb
estiver incluída, mas nada impede que você coloque o combo hiera_hash-create_resources em outras funções, possivelmente role::postgresql
.
Espero que isso tenha sido compreensível e coerente o suficiente para seguir. O acima, claro, não foi testado como publicado, mas usamos essa mesma estratégia (create_resources, hiera_hash) para gerenciar contas locais e do sistema, repos, sudoers, instâncias do Tomcat e outras. Vou revisitar a questão amanhã quando estiver menos cansado.
Mas dê uma olhada nessa excelente pergunta sobre Puppet-Ask: link
Ele percorre uma configuração semelhante com base no HAproxy. Muito útil para entender.