5

I have a puppet/foreman server running on Debian 7 for managing my systems. I use the community version 3.7 of puppet and foreman 1.6.0. I use directory environments.

At the moment I use a rather complicated workflow for my self written modules of creating them in my develop environment, which is subversion controlled, then exporting them to an outside directory, building a puppet module of them (puppet module build ...) and installing that in production. I considered branching/tagging them to production with subversion but ruled that out back then for reasons I can't remember.

Meanwhile I learned a little git and would rather use git instead of subversion for this. My question is now if there are best practices to do so? I can imagine at least two approaches which both have their pros and cons. One would be putting the environment development under version control and then clone/branch this to production. Second would be making a git repo of every module an cloning them over to the environments.

As I said, I'm new to git, so I have no real clue of the strengths and weaknesses of it. Also I'm only using puppet and foreman for about 8 month.

Cheers, Christoph

Christoph
  • 107
  • 9

1 Answers1

6

The answer really depends on how version-controlled you want to be. There are a few main approaches:

  1. House everything in a single flat Git repository, and just clone it on your masters (or nodes if you're running masterless).

    This is by far the simplest option, but means that you'll have multiple copies of the same module across your production and development environments (though you could get around it with symlinks).

  1. Have your main Puppet code in a single Git repository, with Git submodules pointing to your custom modules. Deployment is the same as above, with the addition of --recursive to the git clone.

    The advantage of this approach is that you can easily reference external modules (the PuppetLabs Apache module for example) and it's relatively easy to pull in upstream changes, but you also have the overhead of having to deal with Git submodules, which are notoriously messy.

  1. Run your own Puppet Forge, and use Librarian-puppet or R10K to manage the installation of your modules.

    This has the advantage of being able to fully control the versions of your modules via SemVer without publishing them publicly - though rolling your own Puppet Forge is still considered "bleeding edge" by some.

Craig Watson
  • 9,575
  • 3
  • 32
  • 47
  • Sorry, for double comment. Should be one: In case 1. I guess I just could use etckeeper. I have a single master and thinking of using etckeeper anyway. For 2. I see the advantage of being able to integrate external modules, but I guess it would break the installation of modules with `puppet module install`. How would you move modules between environments with 1.? I would really like a clear distinction but would like to make it easy to update production from development. I assume you meant `/etc/puppet` when you said "house everything". Or at least `/etc/puppet/environments`. – Christoph Oct 22 '14 at 13:22