Been working with Puppet in a standalone configuration for the last 9 months or so. The basic architecture starts with a git repo that has the whole configuration. All the modules are external to the repo. Managing this has at times been cumbersome and recently I’ve been investigating using librarian-puppet to manage the modules. I’ve create a bare minimum configuration that I can share, it performs the main steps with a pair of scripts, one to initialize things and the other for routine calls to puppet apply.
Everything is at GitHub.
Hopefully it’s useful to others. One thing to note, I’m using the EPEL packaged puppet instead of the latest and my config is very RHEL oriented. So it will work on any derived distros.
Basic syntax checking. What more can I say. As I continue to work on modules, being able to quickly check syntax without having to insert into an working environment is invaluable.
As I start to generalize my base puppet config, I added support for Debian. That led me to look into the install automation, called preseeding. I started the process of converting my kickstart models to work with a preseed configuration. I have a working template, it still does not assign the static network values but does a complete no prompting install, tested with the latest release 7.0. I will test it with Ubuntu server as well. Once it’s solid, I will work on updating the bootstrap script to handle the puppet initialization. Check out the repo at github.
Update: Ok, so it still needs work. My tests did not reveal the prompts when the disk is new/uninitialized. Almost right.
I’ve been teaching myself Puppet. I determined early on that I preferred the standalone approach, where the whole configuration is stored in a centralized repository with the clients periodically checking out the configuration and applying the changes. Since there are some gaps in the information I found on the subject, I put the most basic structure together and made it available in github. Take this as a starting point. It will need modification to suit your needs.
The assumptions for this project are related to the kickstart project that can also be found in github. If you kickstart a new host/vm, you will want to place it under configuration management as quickly as possible, usually a requirement these days. I have included the bootstrap.sh script to act as the first step towards that goal. Once the initial checkout and application of the configuration occur, reboot and you can start using the new host/vm in it’s role.
Edit: Kick or don’t kick. Puppet does not care.
Being able to deploy a linux host from a standard template is a valuable part of any sysadmin’s skill set. Used in conjunction with configuration management tools like Puppet, you can readily deploy numerous systems with the knowledge that they are documented and reproducible. With so much emphasis on disaster recovery with the shortest possible RTO, how can you really deploy by hand anymore?
I put together the most common pieces to get you started. Check it out: https://github.com/breauxaj/autoinst-kickstart