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, I’ll update any roles as needed, push this change into my git server and this pushes the changes to my puppet master. The puppet daemons can then get hold of the new code.

My git server and puppet master run in VMs and aren’t powered up much, and they’re also not accessible on the train, say.

Puppet apply is much quicker for getting a bit of code, template etc., to work. By the time the code has got to git, the environment has rebuilt on the puppet master, and I’ve done a puppet run, I could have tripped over the bug, fixed it, and tried again.

It also makes the puppet master optional. If you want to get going with puppetising stuff, without the need to stand up infrastructure, then puppet apply will work.

But, you can still follow best practise, ie: data vs. code, control-repo, roles, profiles, etc.

I’ve written a series of posts on how to get control repo working in this way, and have also forked Puppet’s sample control repo as a starter for ten.

Intended audience

I found it quite hard to get going with puppet at home because I had to stand up a lot of infrastructure first. I discovered, talking to a colleague at work, that I wasn’t alone.  If you’re not using puppet every day at work and / or aren’t primarily a Linux sysadmin, getting the master going could present a barrier to entry. (I believe it’s available in a container – ‘Pupperware’ – ha ha, but arguably that’s even harder!)

So, I’m not assuming a lot of puppet or Linux knowledge.

I am assuming some git knowledge; because I don’t consider myself that knowledgeable, and if I preach about git, I’ll get it wrong.

If you come here with Linux and puppet knowledge, you can skip to the last page and read how it ends. The production branch contains the end state for this series, and you can review the commits to see what I did.

I’d been using puppet in anger for a couple of years before I tried to unpick how control-repo worked, and I’d not used puppet apply since formal training (which didn’t cover (or predated) roles, profiles, etc.) so hopefully it’s worth following along.

How I’ve organised the examples

I’ve layered the changes over the top of Puppet’s example control-repo in a sequence that follows the posts in this series.

My repository contains a bunch of git branches, each representing a logical step in the ‘story’.

As the posts progress, the solution becomes more complex;  the posts demonstrate each step along the way.

Next

puppet apply #2 – pre-requisites

TL;DR

• The modified control-repo repository is here: https://gitlab.com/benprescott-puppetapply/control-repo
• This is forked from: https://github.com/puppetlabs/control-repo
• The README contains a condensed description for how to use it.

All posts in the series

puppet apply #1 – introduction to driving control repo
puppet apply #2 – pre-requisites
puppet apply #3 – control repo entry point
puppet apply #4 – a profile
puppet apply #5 – roles and profiles
puppet apply #6 – installing modules
puppet apply #7 – classification via hiera
puppet apply #8 – puppet apply and hiera
puppet apply #9 – classification along side puppet apply

• Each post contains a link to the next post, use the puppet-apply tag to list them all.