Home / server / Questions / 443737
Accepted
Aitch
Asked: 2012-10-31 07:10:11 +0800 CST

With puppet, can you have the client ask to be a certain set of roles?

  • 772

I've recently got my puppetmaster and client up and running and have had the client correctly signed, then requested and applied simple changes, all good.

I have a growing number of machines (>100). They are not consistently named (historical reasons). They fall into a handful of categories (think of it like: dataserver_type1, dataserver_type2, webserver_type1, webserver_type2....). New instances of these types of machines are added weekly.

I don't understand (yet) or cannot see how I can declare a "generic" node of (say) "dataserver_type1" that contains whatever modules it needs, and set something in the client puppet.conf that says "I am a dataserver_type1" without using the hostname/FQDN

If I set the node name in the catalog as (say) "my-data-server-type1" - the certified hostname - it picks it up and works. I know you can use patterns for hostnames but as I said, my server names are not consistent, and I can't change them.

This seems disingenuous to have to edit a file and manually add a node for each server, when they continue to grow.

Edit:

Digging deeper, it seems roles may be what I want. But there still seems to be an element whereby the master has contain a list of roles that a specific named server should do. Perhaps what I am asking is, how can a client say "I want to be this role", without the server having to be updated?

puppet

2 Answers

  1. Nodes are always centrally defined, either in your manifests or an external node classifier (or both).

    I guess you could put together an ENC that allows clients to specify their role.. but why are you wanting to touch each computer to configure it locally?

    Sounds like you might just need some better organization to your node manifests. Maybe some node inheritance for your system "roles" to reduce duplication every time you make a new node, as well as some good regex node names that cover sets of system names (as in, you might not be able to cover every webserver_type2 with one regex, but put one in place that covers the naming convention you're using for new nodes).

    • 2
  2. Best Answer

    Coming back with a solution and for future googlers. Thanks to others for the input.

    There was a discussion here that led to a set of files hinting at a solution.

    However my limited experience suggests this was a little out of date in terms of file locations. On the client, you need a file like so:

    root@vbox1-test:/etc/puppet# cat custom_facts.yml 
servertype: webserver-type1

    On the server (puppetmaster) if you follow the files in the second link provided then the .rb works fine, but the location is wrong (I'm using v3.x). Try moving it to:

    ubuntu@puppetmaster:/etc/puppet/modules/custom/lib/facter$ ls custom_facts.rb
custom_facts.rb

    Within any one of your module .pp files etc, simply add something like

    ...
notify { "My servertype is: ${servertype}" : }
...

    Again the second link alludes to the fact you can do a "case" statement of sorts to then pick and choose which modules/manifests are used. So i can apply a base set of rules to most machines, then some custom ones for certain types, without touching the server manifests.

    The effect you get on the client is something like this:

    root@vbox1-test:/etc/puppet# puppet agent --test
Info: Retrieving plugin
/File[/var/lib/puppet/lib/facter]/ensure: created
/File[/var/lib/puppet/lib/facter/custom_facts.rb]/ensure: defined content as '{md5}xxxxxxxxxxxxxxxxxxxxxxx'
Info: Loading facts in /var/lib/puppet/lib/facter/custom_facts.rb
Info: Caching catalog for vbox1-test
Info: Applying configuration version '1351762428'
My servertype is: webserver-type1
/Stage[main]//Node[default]/Notify[My servertype is: webserver-type1]/message: defined 'message' as 'My servertype is: webserver-type1'
Finished catalog run in 0.05 seconds

    I'm pretty optimistic this give me what I want and I can keep the manifests free of server names, which are legacy and growing continually.

    • 1