The example control repo doesn’t, at present, have a mechanism to classify nodes.  To bolt puppet apply functionality onto an existing master-based control repo, it needs to sit along side a classification mechanism. This post will extend control repo with the ability to assign a role to a machine, and change hiera and the code […]

Adding classes At present, puppet apply should look something like this: $ sudo scripts/puppetapply.sh + /opt/puppetlabs/bin/puppet apply –test –environment=local /etc/puppetlabs/code/environments/local/manifests Info: Loading facts Notice: Compiled catalog for clientname in environment local in 0.16 seconds Info: Applying configuration version ‘xxx’ Notice: Applied catalog in 0.09 seconds Let’s add back in the clientscope class. This will populate […]

Hiera introduction Hiera is used to store data. Roles and profiles are about code reusability, and separating data and code is probably the other main pillar of Puppet best practise. Hiera layers the data, allowing you to selectively mask values with others based on properties of the puppet client.  The trick is to pick useful […]

Built in types So far, this control repo is limited to functionality built into the puppet agent, or that’s written from scratch. Built in types are documented by puppet, eg: https://puppet.com/docs/puppet/5.3/type.html You can get a list from the client: $ puppet resource –types augeas computer cron exec file filebucket […] In the control repo structure, […]

what are roles and profiles? Roles and profiles are the recommended way from Puppet to organise code. Documentation elsewhere on this includes: https://puppet.com/docs/pe/2017.2/r_n_p_full_example.html Summary: Each node / server / puppet agent has a single role. Webserver, database server, jenkins server, blog-webserver, customer-databaseserver, and so on.  Whatever makes sense in your environment. Profiles provide useful functionality […]

Putting all our code in site.pp isn’t very scalable. We want to follow Puppet best practise and use roles and profiles, so: cd control-repo # I’m going to assume this from now on git checkout puppetapply02 If you look at manifests/site.pp, there’s an include statement. This is the basis of how node classification is generally done. […]

Puppet apply and the puppet master need to start somewhere when compiling a puppet catalog. When control repo is used by the puppet master, the manifests/ directory is this start;  or entry point. Puppet apply needs to be told what to run; point it at a directory with puppet manifests in them, and it’ll process […]

To get started with the example control repo install a puppet client and pull down the control repo. The control-repo repository that accompanies these blog posts is published here: https://gitlab.com/benprescott-puppetapply/control-repo – so there’s a nice GUI for exploring what’s provided. Couple of assumptions here;  you’ll need to read the puppet docs if your situation doesn’t […]

My home puppet workflow looks a bit like this I clone my control repo, or work off a copy already on the machine in front of me. Once the new or modified profile is good to go, I’ll often use use puppet apply to test it; either locally, or an appropriate system. At some point, […]