On 03/10/15 13:08, Joao Morais wrote:
How to manage a Puppet Server with multi-environment and multi-system?
This is something I have also been grappling with lately. We too, have a number of environments (development, staging, production) that a host might belong to, and a deployment model that propagates changes through the environments from dev, to staging, to production. When we initially deployed this infrastructure, we created Puppet dynamic environments corresponding to those physical environments (i.e. Puppetfile and Hiera repos, each with dev, staging, and production branches on each). In hindsight, I think this was a mistake to have this direct relationship between Puppet environments and physical host environments, for the reasons you suggest. Changes accumulate quickly in the dev environment, and it becomes challenging to promote certain changes to staging or production. You either merge the entire branch, and have to coordinate releases carefully with everyone working on dev, or you cherry pick particular commits from Dev, and then have to somehow manage keeping the environments in sync.
My plan now, is to change this to a model where nearly every host (dev, staging, and prod) is in a single 'production' Puppet dynamic environment. Rather than having puppet environments that correspond to physical environments, the single production Puppet environment represents the stable tested version of our Puppet code and Hiera config. That is, the way we deploy a dev or staging box, should be exactly the same as the way we deploy a production box. Where we are developing or testing a puppet module, we create a new feature branch/environment, and move a host to that environment for testing. Then once the change is tested, the feature branch is merged into production and applied to all hosts, and the testing host is moved back into the production environment. The idea here is that environments other than 'production' are generally for short-term use.
Because all hosts are on the same Puppet environment most of the time, we capture the differences between them in Hiera. Each of our hosts has a site code, which captures the host's geographic location and physical environment in a short alphanumeric id. This id is exposed as a fact, and incorporated into our Hiera hierarchy so we can target configuration to all hosts in a particular site. As with modules, config changes can be tested in a temporary feature branch before merging to production, and we can also use the Hiera hierarchy to scope changes to individual hosts, whole sites, or to all environments.
Gary Larizza describes a similar model, more cogently than I have, in a blog post here: http://garylarizza.com/blog/2014/03/26/random-r10k-workflow-ideas/
I'd be interested to hear from anyone who is already using such a model, and particularly if you've run into any problems with it.
-- Richard Gray _____________________________________________________________________________ This email has been filtered by SMX. For more info visit http://smxemail.com _____________________________________________________________________________ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/561198D3.5010306%40smxemail.com. For more options, visit https://groups.google.com/d/optout.
