Lookup Hiera baseado no padrão

Question

Estou tentando entender como posso fazer a transição de algo que estou fazendo no meu arquivo site.pp para uma estrutura que posso usar no hiera. Não está claro para mim lendo os docs de fantoches, exatamente como os dados hiera são avaliados e quando se encaixam na imagem. Eu atualizei recentemente do fantoche 2.7.x para 3.3.x. Isso inclui o hiera como parte do pacote padrão, então eu queria finalmente usar isso já que ele deveria facilitar minha leitura.

Estou usando para dar suporte a vários sistemas de organizações externas. Isso inclui a configuração de sistemas exclusivos para cada organização. No topo do meu site.pp eu tenho uma estrutura como abaixo. O que eu uso para definir fatos para cada organização com base em uma expressão regular que corresponde ao fato clientcert que são configurados e emitidos de forma que eles identifiquem de forma confiável cada organização.

# match organization
case $::clientcert {

  /.*example1.org/ :
      { $snmp_ro_community='...'
        $snmp_location='Example Org 1' 
        ... }
  /.*example2.org/ :
      { $snmp_ro_community='...'
        $snmp_location='Example Org 2' 
        ... }
  /.*example3.org/ :
      { $snmp_ro_community='...'
        $snmp_location='Example Org 3' 
        ... }
  /.*example4.org/ :
      { $snmp_ro_community='...'
        $snmp_location='Example Org 4' 
        ... }
}

Eu navegando pelos exemplos Não vejo nenhuma maneira de fazer qualquer tipo de correspondência de padrões no meu arquivo hiera.yaml. Eu suspeito que devo estar perdendo algo óbvio embora.

Eu não quero depender de um fato personalizado para isso. Eu prefiro ficar com o certificado do cliente, pois tenho certeza que isso irá identificar corretamente a organização e o sistema e foi confirmado usando criptografia strong. Eu não quero dar os valores de uma organização para outra organização.

    

Answer 1

Você pode configurar a hierarquia de arquivos YAML para isso. Vamos começar com hiera.yaml :

---
:hierarchy:
    - "host/%{fqdn}"
    - "domain/%{domain}"
    - "env/%{::environment}"
    - "ops/%{operatingsystem}"
    - "os/%{osfamily}"
    - common
:backends:
    - yaml
:yaml:
    :datadir: /etc/puppet/data

Para a estrutura de pastas, você pode usar qualquer fato que possa ver na saída de facter -y . por exemplo. você pode ter arquivos de configuração hiera para cada arquitetura de CPU. Então você adicionaria linha

- "arch/%{::architecture}"

e hiera pareceria dizer em arch/amd64.yaml

Para depurar hiera, você pode descarregar seus fatos atuais:

   $ facter -y > myhost.yaml

E procure alguma variável:

   $ hiera -y myhost.yml snmp_location --debug

Hiera vai passar por todas as regras e tentar encontrar a variável:

DEBUG: Mon Nov 11 11:00:23 +0100 2013: Hiera YAML backend starting
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking up snmp_location in YAML backend
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking for data source host/myhost.example.com
...
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Looking for data source ops/Ubuntu
DEBUG: Mon Nov 11 11:00:23 +0100 2013: Cannot find datafile /etc/puppet/data/ops/Ubuntu.yaml, skipping

Para corresponder $::clientcert , pode ser uma boa ideia extrair o domínio principal para um fato separado e, em seguida, apenas ter arquivos yaml para cert/example1.org.yaml , que conteria algo assim:

---
snmp_location: 'Example Org 1'

É bom saber que, mesmo que você tenha um módulo que não contenha nenhuma chamada de função hiera, você poderá configurar facilmente os valores dos parâmetros:

class snmp (
  $location = 'foo',
) { 
# ...
}

algumas configurações hiera:

---
snmp::location: 'Example Org 1'

    

Answer 2

Eu estava procurando a mesma coisa por um motivo semelhante. e descobriram que o hiera foi escrito em github jjulien / hiera-regex . Como um exemplo do próprio arquivo readme do projeto:  você precisa configurar um novo back-end que lide com o agrupamento como em:

/etc/puppet/hiera.yaml:

:backends:
  - regex
  - yaml
:yaml:
  :datadir: /var/lib/hiera
:regex:
  :datadir: /var/lib/hiera
:hierarchy:
  - "fqdn/%{::fqdn}"
  - common

/var/lib/hiera/fqdn/fqdn.regex:

---
 - '^mailin-trusted.example.org$':
     postfix::smtp_relay: 'mailout-dmz.example.org'
 - '^mailout.*':
     postfix::smtp_relay: 'smtp.mailgun.org'
 - '^mailin.*':
     postfix::smtp_relay: 'localhost'

no entanto, vejo várias mensagens de usuários fantoches e o vídeo puppetlabs está alertando contra o uso do hiera para classificação, especialmente agora com o lançamento do PE 3.7 com o gerenciador de nó.