Tratamento de exceções para módulos no Puppet

1

Eu tenho um módulo LDAP no Puppet que é usado por 100 servidores e edita cerca de 10 arquivos em todos os servidores, antes de executar o authconfig --updateall para ativar a nova configuração do LDAP.

A maioria (98) desses servidores precisa de um acesso padrão-1.conf como seu access.conf, mas 2 servidores precisam de acesso-2.conf. Isso faz parte de um grande módulo ldap, portanto, todos os 100 servidores precisam de 99% desse módulo do ldap, mas alguns servidores (mais no futuro com base em sua função) precisam de uma exceção para o access.conf.

[root @ puppetmaster modules] # cat /etc/puppet/hieradata/environment/prd/webserver-03.yaml     classes:       - servidor web       - webserver-apache-02

# Test variables
role: webserver
cluster: apache-02

Estou pensando em usar algo assim nos manifestos / init.pp:

$role = hiera('role');

if($role = 'webserver') {
    file { '/etc/security/access.conf':
            owner => 'root',
            group => 'root',
            mode => '644',
            content => template('ldap/access-2.conf'),
    }
else {
    file { '/etc/security/access.conf':
            owner => 'root',
            group => 'root',
            mode => '644',
            content => template('ldap/access-2.conf'),
    }
}

O princípio DRY (Don't Repeat Yourself) é importante para mim, prefiro não clonar um módulo inteiro. Haverá muitos casos no futuro em que eu desejarei usar funções para distribuir arquivos / configurações específicos com base na função do servidor, enquanto ainda compartilho um módulo com outros servidores.

O que você acha de usar essa função: webserver e if / else como solução para lidar com essa exceção no módulo?

    
por ujjain 29.07.2013 / 11:22

1 resposta

4

Você pode usar um fato personalizado para diferenciá-los e resolver um modelo usando esse fato:

class foo (
  $role,
  ){
    file { '/etc/security/access.conf':
        owner => 'root',
        group => 'root',
        mode => '644',
        content => template("$role.ldap/access-2.conf"),
    }
}

Usando a versão atual do facter , é fácil fornecer fatos personalizados em seus servidores:

# cat /etc/facter/facts.d/datacenter.yaml
---
role: webserver
location: Oz

Em seguida, dependendo de como você configurou sua hierarquia, você pode ter uma função e funções padrão por domínio ou host, um exemplo:

---
:backends:
  - yaml
:hierarchy:
  - "%{::hostname}"
  - common
:yaml:
  :datadir: "/etc/puppet/hieradata/%{::domain}/%{::location}"

Aqui, location também é um fato personalizado, por isso é fácil criar hierarquias personalizadas também. Para manipular exceções, escreva um fato personalizado e deixe o arquivo common.yaml manter os valores padrão.

    
por 29.07.2013 / 13:59