I’d say one of the “hardest” pasts of deploying puppet is building out the inital infrastructure. I say “hardest” because its really not that hard, but, if its a dlena room environment, with no config managment to use as a jumping off point, it can involve lots and lots of manaul config, trial and error, and who really wants any of that when you’re trying tobuild something to automate everything else?
I recently, after some testing/playing around in a multi-vagrant envionment, came up with what I’ve found to be a pretty good recepie, and since there doesn’t seem to be a TON out there for details, from scratch hwotos, I figured I’d write one up.
What I ended up with looks, at the high level, like this:
- Centralized PuppetCA system (master of masters one might say)
- Git control-repo, roles/profiles/hiera heavy, no in-house modules at this point.
- Consul, for service registration/health checks, clients use this for the DNS for finding masters (scales and is health check based)
- Consul, for deployment (since we can deploy to all masters in paralell, and consul knows what systems are masters)
- 99% automated spinning up of new masters (dns_alt_names are really all thats not automatable)
Odds are this is going to get pretty long, and might even get split into multiple posts, but, the high-high level steps are:
- Build your git (control)repo
- Build first master/ca from ^^^
- Build consul server(s) from ^^^
- Build Jenkins from ^^^
- Setup Jenkins build/deploy via consul exec
- Build a new master
- Build puppetdb