Setting up a Puppet Master to deploy from a Git repository without GitHub or Bitbucket or similar is straightforward, thanks to the flexibility of Git hooks. Versioning manifests for Puppet or alternatives such as Chef is an excellent idea, allowing the benefits of a VCS to be leveraged to provide a centralised comprehensive historical trail even when working with multiple devops. One good approach is to host the repository using external service GitHub or Bitbucket or similar, setting appropriate access permissions and using Capistrano or similar to deploy and trigger a Puppet run. This has the disadvantage of placing a large amount of trust in the VCS service, however. An alternative would be to run your own repository server internally; however, that seems overkill for a single-repository case. A much lighter solution is to simply use Git over SSH and host the repository directly on your Puppet Master.
Throughout, an OS of Ubuntu Server 14.04 LTS is assumed; instructions for other environments should be similar.
versioning the puppet config
If you are already running a Puppet Master with a versioned config, you can likely use the same one with minimal changes. If setting up a fresh Puppet Master, you might like to install Puppet Master using your choice of packages, and then version the resultant configs. e.g.
Create (or reuse) a repository from the contents of /etc/puppet.
creating the bare git repository
Create a bare Git repository, such as is suitable for receiving pushes. It’s better to use a bare repository rather than one with a working copy, to ensure conflicts are not run into. Ensure that it and the target /etc/puppet are owned by the user through which you’ll be connecting, which should be able to sudo without password. If such a user is called ubuntu:
Create a post-receive hook in the bare Git repository, to update /etc/puppet and trigger a Puppet run. As ubuntu or similar user:
triggering the first puppet run
If using fresh Git repository, ensure puppet.conf is checked in and set with appropriate settings (dns_alt_names, server, etc.). At this point, the Puppet Master should be set up and running.
Set the Git remote, and push the Git repository, which should automatically update the contents of /etc/puppet, trigger a Puppet run, and report the results directly to the console:
Thereafter, git push should trigger a Puppet run, without requiring the repository to be hosted externally or a deployment mechanism invoked.
Clearly, this isn’t that involved. But that’s the point; it’s easy to set up and maintain, and requires very few moving parts. Very little of this is Puppet-specific (the approach indeed being similar to that used for years to deploy all sorts of things), so it should be straightforward to adapt it for use with other automation tools.