Managing the puppet manifest using a vcs is a best
practice
and there is a lot of material on the web. The easier way to do it, is
to use git directly in the directory /etc/puppet and use a
simple synchronization strategy with an external repo, either to
publish your work, or simply to keep a backup somewhere.
Things are a bit more complicated when you would like to co-administer
the machine with multiple people. Setting up user accounts, permission
and everything can be a pain in the neck. Moreover working from your
desktop is always more comfortable then logging in as root on a remote
system and make changes there …
The solution I’ve chosen to make my life a bit easier is to use
gitolite, that is a
simple git gateway that works using ssh public keys for authentication
and does not require the creating of local users on the server
machine. Gitolite is available in debian and installing it is super
easy : apt-get install gitolite .
If you use puppet already you might be tempted to use puppet to manage
your gitolite installation. This is all good, but I don’t advice you
to use modules like this one
http://forge.puppetlabs.com/gwmngilfen/gitolite/1.0.0 as it’s going to
install gitolite from source and on debian it’s not necessary … For
my purposes, I didn’t find necessary to manage gitolite with puppet as
all the default config options where good enough for me.
Once your debian package is installed, in order to initialize your
repo, you just need to pass to gitolite the admin public key, that is
your .ssh/id_rsa.pub key and then run this command:
sudo -H -u gitolite gl-setup /tmp/youruser.pub
This will create the admin and testing repo in
/var/lib/gitolite/repositories and setup few other things. At this
point you are ready to test you gitolite installation by cloning the
admin repo :
git clone gitolite@example.org:gitolite-admin.git
Gitolite is engineered to use only the gitolite use to manage all your
repositories. To add more repositories and users you should have a
look at the
documentation and then
editing the file conf/gitolite.conf to add your new puppet repository.
At this point, you can go two ways. If you use git to manage your
puppet directory, you can just make a copy of it somewhere and then
add gitolite as a remote
git remote add origin gitolite@example.org:puppet.git
If you didn’t use git before, you can just copy the manifest in your
new git repository, make a first commit and push it on the server.
Every authorized users can now use git to clone your puppet
repository, hack, commit, push …
git clone gitolite@example.org:puppet
One last step is to add a small post-receive hook on the server to
synchronize your gitolite repository with the puppet directory in
/etc : This will sync your main puppet directory and trigger
changes on the nodes for the next puppetd run. First I created a small
shell script in /usr/local/bin/puppet-post-receive-hook.sh :
#!/bin/bash
umask 0022
cd /etc/puppet
git pull -q origin master
This script presuppose that your git repo in /etc/puppet has the
gitolite repo as origin … Then I added a simple hook in the gitolite
git repo that calls this script using sudo :
sudo /usr/local/bin/puppet-post-receive-hook.sh
And since you are at it you should also add a pre-commit hook to
check the manifest
syntax.
This will save you a lot of useless commits.
If you use a more complicated puppet
setup
using environments (I’m not there yet, and I don’t think my setup will
evolve in that direction in the near future), you can use
puppet-sync that seems a neat
script to do the job.
For the moment this setup works pretty well. I’m tempted to explore
mcollective to
trigger puppet runs on my nodes, but I’m there yet…