puppet matching multiple agent hostnames to params.pp data structure

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?

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.