0

How do people organize their Puppet manifests and modules in your source code repository? I am not seeing any obvious way to implement changes in Puppet in a phased manner on a single Puppet master.

How are other people managing this? One master server instance per server group/SDLC phase? I would very much like to use the same Puppet modules in each phase and just use subversion to change what version of the Puppet modules gets applied to each server group/SDLC phase so I can roll changes out in a phased approach. I'm looking for a way to leverage the same modules and avoid accidents and variation due to duplicate modules.

I have a slew of servers I am looking at using puppet to manage, with several SDLC (software development life cycle) phases to cover. Disaster recovery, Production, Staging, User Acceptance Testing, Test, Development, Training

Edit to clarify 2nd part:

And how do you maintain your branches in your source repo? For example, with dev and test branches, and a file that defines where I get my patches from.

Do you edit:

repo:/dev/patchessource.txt to contain "patchserver/dev"

repo:/test/patchessource.txt to contain "patchserver/test"

and have those files different, and have to maintain that difference with merging and everything from dev to test or do people have a different file for each environment and migrate them over as a whole:

repo:/dev/devpatchsource.txt to contain "patchserver/dev"

repo:/dev/testpatchsource.txt to contain "patchserver/test"

that way when you merge your dev repo to your test repo you don't have to worry about the dev specific setting overwriting your test specific settings?

I don't see an obvious solution to make it simple for follow-on administrators who may not be well versed in source code management tools.

Any tips would be greatly appreciated.

danw
  • 25
  • 1
  • 7

1 Answers1

1

Environments is how this is solved. With environment you can define configurations for production, staging, ua testing, test, dev, training, etc.

Explaining in depth how to do so is a bit extensive but here are some references you can read to get you started:

In the master repository, you have a branch for development, testing and production (or whatever fits your workflow). You write your Puppet code happily on the development branch, commit, commit, push. Your Puppet Master gets updated (by R10K) when you push (through some Git hook or cron job) and your nodes gets their update at their schedule time.

Presumably, you have node which is set to the development environment so would get the changes you pushed to the development branch. You can test all that.

You're happy with your changes, merge into the next workflow step branch - say production. Push the merged changes and the cycle starts - Puppet Master gets the changes to the production environment and the production nodes apply the new configuration.

--

Now, there is a general confusion which I see people having. A development branch for the Control Repo does not mean "this is the configuration for the programmer machines". No, it means it's your Puppet Development Branch.

So then how do you maintain a set of servers, say Web server, for 3 teams - Dev, QA and Pproduction. I.e. each of those groups have a web server which are configured pretty much the same but have nuances as one is live production system, one is the QA group and another is the Dev.

For that you use Hiera. Each node would have the same classes applied to them but the nuance in the parameters or what have you are set through Hiera.

Of course you could use branches to also mean the "type of machine being managed" instead of Hiera but that is a bit ridiculous because you would not be using Git branch for their real purpose. The branch would be entirely different and you would need to manually "merge" them by copy/pasting from one to the other. That would be, ugly.

ETL
  • 6,443
  • 1
  • 26
  • 47
  • What about in the repo? How do you organize in the repo itself? Do people have separate branches for each phase, and duplicate files for all branches or do you edit each branch independently and merge changes while maintaining those environment specific modification? – danw Jan 22 '15 at 22:29
  • You have a branch for `dev`, which gets merged into, say, `pilot` and once good to go, gets merged into `production` (a.k.a `master`). That's a typical workflow using Git. If you mean environment as being a different requirements on how a machine is set up then you use Hiera for that. – ETL Jan 23 '15 at 00:13