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.
git push origin master
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…