在Puppet中有一个LDAP模块，100个服务器使用它，并在运行authconfig –updateall来激活新的LDAPconfiguration之前，在所有服务器上编辑大约10个文件。
这些服务器中的大多数（98）都需要一个标准的access-1.conf作为它们的access.conf，但是2台服务器需要access-2.conf。 这是一个很大的ldap模块的一部分，因此所有100个服务器都需要ldap模块的99％，但是一些服务器（基于他们的angular色将来更多）需要access.conf的一个例外。
[root @ puppetmaster modules]＃cat /etc/puppet/hieradata/environment/prd/webserver-03.yaml classes： – webserver – webserver-apache-02
# Test variables role: webserver cluster: apache-02 我正在考虑在manifest / 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'), } }
DRY（不要重复自己）的原则对我来说很重要，我宁愿不克隆整个模块。 将来会有很多情况，我希望使用angular色来分配基于服务器angular色的特定文件/configuration，同时仍然与其他服务器共享一个模块。
你认为如何使用这个angular色：webserver和if / else作为处理模块中这个exception的解决scheme？
您可以使用自定义事实来区分它们，并使用该事实来parsing模板：
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
然后，取决于您如何configuration层次结构，可以为每个域或主机设置一个默认angular色和angular色，例如：
--- :backends: - yaml :hierarchy: - "%{::hostname}" - common :yaml: :datadir: "/etc/puppet/hieradata/%{::domain}/%{::location}"
在这里， location也是一个自定义事实，因此也很容易build立自定义层次结构。 为了处理exception，写一个自定义的事实，并让common.yaml文件保存默认值。