8

Have anyone ever managed several geographically distributed systems with Puppet?

I have several almost exactly similar deployments (except the server IP's), which management I'm looking to convert to Puppet.

I have 2 options:

  • Have each deployment to host it's own PuppetMaster for providing local configurations, then synchronize somehow the PuppetMasters (maybe with puppet again)

  • Host the PuppetMaster on AWS EC2 for high-availability, and provide configurations to all deployments from single point

Has anyone tried the second option, and how it worked out? I'm especially interested in High-Availability performance under such environment.

Thanks.

Improve this question

3 Answers 3

Reset to default
7

There is nothing wrong with either approach you propose. We have three puppetmasters, all located at a single site, and serving nodes all over the world - we separate them based on whether the connecting puppet node is in dev/test/prod. Other people prefer to run a puppetmaster per geographic region. Other folk have lots of puppetmasters, some only managing one node!

The key thing is that it is vital that you store and manage your puppetmaster manifest tree in a version control system - treat it like any other code your company maintains. I'd recommend Git, but Subversion will also do the trick if you are more used to that. The puppetmaster is simply a service that serves up its particular view of your VCS, rather than being a central database itself.

With your content in a VCS, you can then deploy the required manifests/modules to the respective puppetmasters, and keep them in sync easily. The convention seems to be for folk have a git/svn repo/module per puppet module, though there is nothing stopping you from putting the whole tree under one repo/module.

My questions to you would be:

  • How many nodes are in each deployment? If you're talking about 50+, then it would be worth having a local puppetmaster for sure.
  • Do the deployments have any 3rd parties that use them in addition to your company? The puppetmaster needs to have very high security - consider it to be the keys to the door of all of your systems, and will contain very sensitive information.
  • Similarly, for the deployment-based PMs, would you host them on their own server/VM, or would an existing machine need to be given the task? I highly recommend that the puppetmaster server has that role alone, for security.
  • How do you expect EC2 to provide you with higher availability? From my understanding, EC2 instances are not HA, though it should be possible to run 2+ puppetmasters behind the AWS load balancer service.
  • Are the deployments very different? Do you want to change them at different times of the day? Multiple puppetmasters gives you a finer level of control.
Improve this answer
2
  • 1
    Hi. We speaking about 10 - 20 nodes max in each deployment, the deployments are world-wide. There are no 3rd parties allowed inside the deployments. I'm actually interested to concentrate all Puppet related data on a dedicated machine, so the PM would be hosted on EC2 instance. I probably will be using Heartbeat + DRBD for the HA. The deployments are basically the same appliances, as said just the server IP's are different. Thanks again.
    – SyRenity
    Jan 13, 2010 at 10:04
  • It sounds very much like one puppetmaster cluster in EC2 will probably do the trick for you then. Just make sure you use Git or Subversion to store your manifests safely :)
    – Mike Pountney
    Jan 13, 2010 at 20:48
2

You could also use a Puppetmaster-less system using a distributed VCS such as Git, using the scheme described here:

http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control

Improve this answer
3
  • If you don't have a puppetmaster then you lose the storedconfigs support, which is one of the most powerful features of Puppet. Think cross-machine information gathering built-in to the updates; e.g. you can automatically collect information about running services on all (puppet-managed) hosts to generate firewalling rules, routing rules, monitoring configs, pull-based backups etc.
    – David Gardner
    Sep 9, 2010 at 9:25
  • Yes, that's a fair point. Certainly there are advantages to running a full Puppetmaster-based system, and usually I do. I can see situations where a very lightweight, VCS-based system like this would be useful though.
    – John Arundel
    Sep 10, 2010 at 17:04
  • If you are opting for masterless setup you can do that and set up puppetmaster server for means of receiving inventory from facters only — it doesn't have to be very high available then.
    – timurb
    Nov 19, 2011 at 22:21
0

We also have a number of puppet masters, different environments which we synchronise. To do this we manage all of our puppet modules and manifests in subversion and then deploy the puppet modules onto the puppetmasters using regular puppet manifests and a module called vcsdeploy which does the checking out:

http://www.practicalclouds.com/content/guide/pclouds-vcsdeploy-deploy-stuff

When we want to synchronise we tag a version and then update the nodes.pp for the puppet master.

regards

Dave

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.