puppet matching multiple agent hostnames to params.pp data structure

Question

I have a module called appserver in my puppet modules. In that module manifests I have a params.pp file which is inherited by init.pp file. In params.pp file I have the following data structure.

$servers = {
                appserver-mgr => { axis2   => {subDomain => 'mgt',},
                                    carbon  => {subDomain => 'mgt',},
                                    serverOptions => '-Dsetup',
                                    server_home => $carbon_home, },
                appserver-wkr => { axis2   => {subDomain => 'worker', members => ['appserver-mgr2-ip']},
                                    carbon => {subDomain => 'worker',},
                                    serverOptions => '-DworkerNode=true',
                                    server_home => $carbon_home, },
        }

In my init.pp file I'm filling my templates as follows using the said data structure.

    define fill_templates($axis2, $carbon, $clustering, $serverOptions, $server_home) {
            $ipAdd = $::ipaddress
            $hostName = $::hostname
            if $hostName == "${name}" {
                    notify {"host name match found for $hostName for $ipAdd":}
                    file {  "${server_home}/repository/conf/axis2/axis2.xml":
                            ensure  => file,
                            content => template('appserver/axis2.xml.erb'),
                    }
                    ->
                    file {  "${server_home}/repository/conf/carbon.xml":
                            ensure  => file,
                            content => template('appserver/carbon.xml.erb'),
                    }
                    ->
                    file {  "${server_home}/repository/conf/tomcat/catalina-server.xml":
                            ensure  => file,
                            content => template('appserver/catalina-server.xml.erb'),
                    }
            }
    }

As per the current method, if a matching node is found (say appserver-mgr) the respective data structure values are retrieved and applied to the templates. Currently these scripts are working as expected.

Now I want to change it as follows.

I have a cluster containing following nodes.

appserver-mgr-1
appserver-mgr-2
appserver-mgr-3

appserver-wkr-1
appserver-wkr-2
appserver-wkr-3
appserver-wkr-4
appserver-wkr-5

By using the same data structure in params.pp file, how can I apply the appserver-mgr configuration to *.mgr nodes 1-3 and appserver-wkr configuration to *.wkr nodes 1-5?

Can I use regular expressions for this task?

Answer 1

I'm quite sure that it would be possible to bend the Puppet DSL to do what you need here. However, the far better approach to this issue is Hiera.

node /appserver-mgr/ {
    $node_class    = 'appserver'
    $node_subclass = 'manager'
}
node /appserver-wrk/ {
    $node_class    = 'appserver'
    $node_subclass = 'worker'
}

Use the node_class and node_subclass variables in your Hierarchy.

# /etc/puppet/hiera.yaml
---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet/hieradata
:hierarchy:
  - "%{::clientcert}"
  - "class-%{node_class}-%{node_subclass}"
  - "class-%{node_class}"
  - common

Now you can define your data right in the YAML for Hiera, instead of params.pp.

# /etc/puppet/hieradata/class-appserver-manager.yaml
servers:
  axis2:
    subDomain: mgt
  carbon:
    subDomain: mgt
  serverOptions: -Dsetup
  server_home: %{carbon_home}

and for the worker:

 # /etc/puppet/hieradata/class-appserver-worker.yaml
 servers:
   axis2:
     subDomain: worker
     members: 
       - appserver-mgr2-ip
     carbon:
       subDomain: worker
   serverOptions: -DworkerNode=true
   server_home: %{carbon_home}

In your params class, the following then suffices:

$servers = hiera('servers')

Or you don't even bother with the params class, and just replace the uses of the $servers variable with hiera calls. But doing just one call in a params style class is a good practice.

Note: Using the variable value %{carbon_home} from Hiera is somewhat dangerous, you might want to hardcode the actual value in the YAML there.