Questions about puppet best practices on roles and profiles

[NgeeGoh]

Hi all, 

I am new to Puppet and currently doing some Proof of Concept work to see if Puppet could fit into our processes. 

I have set up a puppet master server on Azure and a VM with puppet agent installed. Since I want to dig in more about the puppet manifests and its configuration features, I only use the VM with puppet agent installed as a standalone puppet. 

I have also set up a control repo for the puppet with roles/ profiles model

I have a couple of questions about what would be the best practices:

1. I am a bit confused about how to handle resources and data in puppet manifest. For example, I got a list of windows features that i need to install/ run in JSON file which is located in a resource folder i created in the same level as site and manifest, and in the windowsfeature manifest (in profile) I load the json data and loop through all the data to install/ run the windows features. Would it be nicer and cleaner if i implemented Hierra here? To be honest, the implementation of Hierra to me is also not very clear.

2. As far as I know, puppet control repo controls different environments based on branches which i feel a bit strange, while Chef manages all environments under one folder in git which I find its more manageable since we can apply the configuration to the different environments with different data without worrying about changing git branches. Just wondeirng if we could somehow achieve this in puppet or is there any obvious benefits of this current model in puppet?

Cheers, 

[jcbollinger]

On Tuesday, April 9, 2019 at 10:30:39 AM UTC-5, NgeeGoh wrote:

Hi all, 

I am new to Puppet and currently doing some Proof of Concept work to see if Puppet could fit into our processes. 

I have set up a puppet master server on Azure and a VM with puppet agent installed. Since I want to dig in more about the puppet manifests and its configuration features, I only use the VM with puppet agent installed as a standalone puppet. 

That's a bit odd.  If you are using Puppet only in standalone mode then you do not need a master.  Not using a master is the key characteristic of standalone mode.

 

I have also set up a control repo for the puppet with roles/ profiles model

I have a couple of questions about what would be the best practices:

1. I am a bit confused about how to handle resources and data in puppet manifest. For example, I got a list of windows features that i need to install/ run in JSON file which is located in a resource folder i created in the same level as site and manifest, and in the windowsfeature manifest (in profile) I load the json data and loop through all the data to install/ run the windows features. Would it be nicer and cleaner if i implemented Hierra here? To be honest, the implementation of Hierra to me is also not very clear.

It would be more conventional, at least, to use Hiera for data describing the wanted configuration of your nodes, and it would be a bit more tightly integrated with Puppet.  Once you get the data into the system, however, there are no operational consequences arising from how you did so.

For "resources" in the sense of files that need to be installed on the target node, one of a variety of other approaches would be typical.  For smallish flat files that need to be installed verbatim, I think most people would just put a copy of the file in the files/ directory of an appropriate module.  Similar for file-content templates of any significant complexity, except those would go in a templates/ directory.  Individual pieces of configurable data, however, are generally mapped to class parameters.  During catalog building, class parameters values can be and often are automatically populated from Hiera data.

 

2. As far as I know, puppet control repo controls different environments based on branches which i feel a bit strange, while Chef manages all environments under one folder in git which I find its more manageable since we can apply the configuration to the different environments with different data without worrying about changing git branches. Just wondeirng if we could somehow achieve this in puppet or is there any obvious benefits of this current model in puppet?

Use of control repos is not a feature of core Puppet. It is a technique that has become popular to use on top of Puppet, but you are under no obligation to use it.  You absolutely can keep all environments in a single branch of a single repo if that's what you want to do.  Puppet will not know or care.  It is true, however, that the PE version of Puppet has built-in support for control repos.  If that's the direction you're headed then the control-repo approach may be the path of least resistance.

But there certainly are benefits to the branch-per-environment model.  First and foremost, it provides for better isolation between environments and clearer versioning of environment contents.  It also provides a more structured and API-friendly representation of your list of environments, since they map 1:1 to control-repo branches.

Moreover, it is relatively easy to structure things with a control repo so that (explicit) branch management plays no part in day-to-day operation and maintenance.  The principal difference you would feel is that you need to push and pull changes separately for each environment, but that's part of the point of the approach.

Note also that you may be attributing too much significance to environments.  People set up multiple environments much more frequently and widely than is in fact warranted.  In particular, they tend to associate Puppet "environments"  with operational "environments" such as dev / QA / production of the infrastructure being managed, whereas often those would be better mapped to different roles.  The point of different Puppet environments is to support different sets of Puppet modules, data, and nodes.  It can be counterproductive map the lifecycle stages of the infrastructure being managed  to Puppet environments, because that opens unnecessary opportunities for breakage when you perform a lifecycle advance -- you not only change how your nodes are configured, but you also change the code used to configure them.

John