Обработка исключений для модулей в Puppet

Question

Обработка исключений для модулей в Puppet

У меня есть модуль LDAP в Puppet, который используется 100 серверами и редактирует около 10 файлов на всех серверах, прежде чем запустить authconfig --updateall, чтобы активировать новую конфигурацию LDAP.

Большинству (98) из этих серверов требуется стандартный access-1.conf в качестве access.conf, но 2 серверам нужен access-2.conf. Это часть большого модуля ldap, поэтому все 100 серверов нуждаются в 99% этого модуля ldap, но некоторые серверы (в будущем, в зависимости от их роли) нуждаются в исключении для access.conf.

[модули root@puppetmaster]# cat /etc/puppet/hieradata/environment/prd/webserver-03.yaml классы: - веб-сервер - веб-сервер-apache-02

# Test variables
role: webserver
cluster: apache-02

Я думаю об использовании чего-то подобного в манифестах /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'),
    }
}

Принцип СУХОЙ (не повторяйся) важен для меня, я бы не стал клонировать весь модуль. В будущем будет много случаев, когда я захочу использовать роли для распространения определенных файлов / конфигураций в зависимости от роли сервера, но при этом делить модуль с другими серверами.

Что вы думаете об использовании этой роли: веб-сервер и if / else в качестве решения для обработки этого исключения в модуле?

1

puppet puppetmaster hiera

Источник

ujjain 29 июл '13 в 09:22

1 ответ

Решение

Другие вопросы по тегам puppet puppetmaster hiera

dawud 29 июл '13 в 11:59 2013-07-29 11:59 · Accepted Answer · 2013-07-29 11:59

Вы можете использовать пользовательский факт, чтобы различать их, и разрешить шаблон, используя этот факт:

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

Используя текущий facter Версия, легко предоставить пользовательские факты на ваших серверах:

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

Затем, в зависимости от того, как вы настроили свою иерархию, вы можете иметь роль по умолчанию и роли для домена или хоста, например:

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

Вот, location is also a custom fact, so it is easy to build custom hierarchies as well. To handle exceptions, write a custom fact, and let the common.yaml file hold the default values.