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.
Best Answer
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: