/posts/ 2016/homelab-puppet
Feb 3, 2016
Warning: This post was written 3214 days ago, and may contain incorrect information, outdated opinions, and incorrect language due to my age at the time. Opinions in this post are not representative of who I am as a person today.
It might sound like using a nuclear weapon to swat a fly, but when you’re working with Puppet in your day job it can be really useful to have a test bench to fiddle with new ideas at home. After all thats what homelabs exist right?
Puppet Enterprise (archive.org) comes with a 10 free nodes license as stock, for a small homelab its perfect for managing that configuration that applies to all systems, DNS, routing, SSH keys, you get the idea. Also, as my day job runs Puppet Open Source its great to test out the commercial version and get to know it before the inevitable upgrade where a lot more is at stake.
For my installation I went with CentOS 7 and a single node installation, I use Code Manager to automatically deploy my configuration from a git repository I have stored in Gogs (archive.org), which if you’ve not seen already I highly suggest checking out. Agents are mostly Debian 8 with a sprinkle of CentOS7 and RHEL7 for my learning needs.
Heres some handy hints from my Puppet usage, both in work and home:
10 free nodes! Take advantage of it if you can. While open source Puppet is great, the installer and Console makes Enterprise worth the $100/year/node just for the saved time of fiddling with config.
It might seem obvious, but a lot of places suffer from NIH (archive.org) when it comes to Puppet and decide to re-write from scratch instead of expanding on an already open source module. While the vast majority of modules I use are public on the Forge I have slipped into a habit of quickly hacking together a profile for an application rather than write a full module to share. In general using the Forge will save you time, so take advantage of it.
While you can grab x .tar.gz from y website, extract, run, copy files and such, save yourself the pain and use distribution packages whenever possible. Not only does it make for much easier installation and management it saves you a lot of time when it comes to upgrading.
Trying to configure every part of a system with Puppet will burn you out quickly, cover the required elements and tick them off first. In my opinion Puppet shouldn’t be handling assigning IPs to devices or managing file systems, but setting DNS, firewall rules and package repositories are right up its street.
The --noop option is your friend. Make use of it to check that your new shiny config won’t blow a hole in the side of your system due to a dodgy Heira YAML file. In Puppet Enterprise you can even run this from the console.
If you have the infrastructure to spare, get a Jenkins system setup and lint/test that config before it hits a live system. If you want to get really fancy, have Jenkins auto push to your production branch after testing for that continuous deployment feeling.
While its a recent development I highly suggest you read the documentation and have a play with this. Hand holding multi system deployments is no longer needed!
I’m sure people have a hundred and one other things to say, but i’ll leave that for the experts…