Ask Your Question

best practices: how to configure a hierarchical host configuration (with examples, please)

asked 2016-06-05 18:14:56 -0600

Ron gravatar image

Apologies if this is a noob question.

I've been reading the puppet nutshell book and puppet cookbook. I have puppet 3.4.3 up on several machines, Centos 6 (32 bit) and Centos 7, and some machines running Mint 17. I'm about to add Fedora Workstation to the mix.

The puppet master is on Mint 17. (My main laptop. I may migrate this to a server once I get everything working.)

Puppet clients have all been authenticated to the Puppet Master, and I've successfully been able to install and mange software and make configuration changes on all clients from the manifest on the Puppet Master. So far, so good. I even have all my configs under git and pushed to github.

Currently, all configurations are by server name, and this has resulted in some replication in the manifest.

I have an idea of where I want to go next, but I would like to do it in an orderly fashion that's easy to maintain. To that end, I'd like to manage the servers in an hierarchy, like so:

AllPuppets: {
                        #  Code in this stanza applies to all Puppet clients.  (Server,s, desktops, everything)

AllServers: {
                        #  This is the subset of AllPuppets that are back-end servers.

AllDesktops: {
                         # This is the subset of AllPuppets that are desktop and laptop machines.  (Generally, Mint and Fedora.)

WebServers: {
                         # This is the subset of AllServers that run web applications.

FileServers: {
                         # This is the subset of AllServers that are primarily file servers.

How does one accomplish this in an maintainable manner? How does a server "belong" to a group? Can a group belong to a higher group in the hierarchy without calling out the server names again? Is there a standard way to do this?

Thanks very much.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2016-06-07 18:03:16 -0600

DarylW gravatar image

The most common way of organizing your module layout is referred to as the 'roles and profile' pattern. You use roles to describe your instances, profiles to describe the 'technology' that you are putting on your servers.

If you want to organize things the way you describe, there are several ways to do it. In your layout, you don't have a strict 'role' per server, so you may want to just start out creating your profiles. You need to classify all of your servers, classically done using the nodes.pp file with node declarations. In each node definition, you would specify each of the profiles that you want to use on each of your servers. That gives you specific control per server where you are individually placing a profile. If you specifically want to 'classify' each server as having a set of charicteristics the way you describe, you could use some sort of External Node Classifier. People commonly use Hiera as their ENC.

One thing that you could do to follow the strategy you have outlined above is to have a single default node definition, and in that node definition you would put an if condition based on each 'classification' you have listed above, and declare each one in a specific node definition in hiera. (I'll come back later and fill in some more specifics... ask any questions that you have!)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-06-05 18:14:56 -0600

Seen: 97 times

Last updated: Jun 07 '16