hiera_include equivalente para tipos de recursos

Question

Estou usando o tipo integrado yumrepo . Eu posso obter uma integração básica para trabalhar hiera

  yumrepo { hiera('yumrepo::name') :
    metadata_expire => hiera('yumrepo::metadata_expire'),
    descr           => hiera('yumrepo::descr'),
    gpgcheck        => hiera('yumrepo::gpgcheck'),
    http_caching    => hiera('yumrepo::http_caching'),
    baseurl         => hiera('yumrepo::baseurl'),
    enabled         => hiera('yumrepo::enabled'),
  }

Se eu tentar remover essa definição e optar por hiera_include('classes') , aqui está o que eu tenho no backend yaml correspondente

classes:
 - "yumrepo"

yumrepo::metadata_expire: 0
yumrepo::descr: "custom repository"
yumrepo::gpgcheck: 0
yumrepo::http_caching: none
yumrepo::baseurl: "http://myserver/custom-repo/$basearch"
yumrepo::enabled: 1

Eu recebo este erro em um agente

Error 400 on SERVER: Could not find class yumrepo

Eu acho que você não pode fugir de algum tipo de declaração de nó mínimo w / hiera e tipos de recursos? Talvez hiera_hash seja o caminho a seguir?

Eu dei uma chance, mas isso produz um erro de sintaxe

  yumrepo { 'hnav-development':
    hiera_hash('yumrepo')
  }

    

Answer 1

Acabei usando create_resources . Essencialmente, ele fornece a capacidade de mapear tipos definidos para nós com hiera, da mesma maneira que hiera_include faz com classes prontas para uso.

Com essa configuração, posso declarar qualquer número de tipos de recursos file em qualquer nível da hierarquia, além de a configuração estar toda em fontes de dados hiera.

/etc/hiera.yaml

:hierarchy:
  - defaults
  - "%{environment}"

/var/lib/hiera/defaults.yaml

classes:
  - hiera_file_wrapper
hiera_file:
    hiera-two:
       path: /home/quickshiftin/hiera-two
       ensure: file
       content: 'Hiera two' 

/var/lib/hiera/production.yaml

hiera_file:
    hiera-baby:
       path: /home/quickshiftin/hiera-baby
       ensure: file
       content: 'Hiera baby!

modules / hiera_file_wrapper / manifestes / init.pp

class hiera_file_wrapper()
{
    create_resources(file, hiera_hash('hiera_file'))
}

manifestes / site.pp

hiera_include('classes')

    

Answer 2

Como yumrepo é um tipo de recurso, não uma classe, isso não funcionará.

Eu diria colocar uma classe no named yumrepo_myreponame e declarar o recurso yumrepo . Você pode colocar parâmetros de classe no Hiera para isso, se você precisar também, e passá-los para a declaração de recursos.

Por exemplo, eu tenho um módulo para ativar o EPEL em um servidor, que pode ser colocado em sua matriz Hiera classes para ativá-lo. Todo o seu conteúdo é:

class epel_yumrepo {
  yumrepo { "epel":
    descr          => 'Extra Packages for Enterprise Linux 6 - $basearch',
    enabled        => 1,
    gpgcheck       => 1,
    gpgkey         => 'http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6',
    mirrorlist     => 'https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch',
    failovermethod => "priority",
  }
}

    

Answer 3

Vamos supor que você tivesse um repositório yum chamado hnav e precisasse que ele tivesse uma URL diferente com base na versão do sistema operacional que você está usando, 5 ou 6.

Você configurou sua hierarquia em /etc/puppet/hiera.yaml como

:hierarchy:
- "%{::operatingsystemmajrelease}"
- common

Para que o hiera primeiro procure um arquivo yaml com o nome da versão do sistema operacional, 5.yaml ou 6.yaml . Se não encontrar um valor lá, ele aparecerá em common.yaml .

Você escreveu uma classe parametrizada para que o hiera pudesse fornecer a URL automaticamente.

módulos / hnav / manifests.init.pp

class hnav ( $url ) {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => $url
  }
}

Se por algum motivo você não gostou de classes parametrizadas, você poderia ter escrito acima como

class hnav {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => hiera('hnav::url')
  }
}

Então você configurou as classes que você queria que fossem aplicadas em todos os seus nós

common.yaml

classes:
  - hnav

E você define os valores para o URL

5.yaml

hnav::url: http://example.com.yum/5/

6.yaml

hnav::url: http://example.com.yum/6/

Este é um exemplo realmente artificial, mas talvez ajude você a entender onde o hiera é usado.

    

Answer 4

Eu construí uma funcionalidade hiera_manifest no meu trabalho. Essencialmente, permite que você chame módulos, classes e parâmetros e defina todos os tipos via hiera yaml.

Eu apenas coloco no Github para compartilhar: link

Isso tem pequenas vantagens em que os parâmetros também são colocados no momento da chamada do módulo, classe ou tipo.

Uma coisa a notar é a diferença em algumas sintaxes para definições de recursos ao usar metaparameters. Além disso, ao solucionar problemas, os erros persistem no manifesto às vezes e você não recebe uma mensagem de erro adequada para o módulo que gera o erro.