One master per environment, or one to rule them all?

[Antony Gelberg]

I've asked a similar question on the Terraform mailing-list but on reflection, I think it's more appropriate here.

Let's say I need several environments, and I'm using AWS, with each environment in a separate VPC. I'm going to configure instances with Puppet (and deploy with Jenkins). I see two basic design options here:

Option 1: Puppet master in one environment / VPC, either:

1. In their own VPC, e.g. "devops".
   
2. Less-optimally, piggy-backed on an application environment VPC, e.g. "staging".

This master would be responsible for configuring all servers across all other environments / VPCs.

Implications:

• Have to open up security groups, scope for environments to affect each other.
  
• Configuring Puppet environments using something like r10k, high dependency on that enviroment
  
• VPCs will have to have different CIDRs (not sure if this is a big deal).
  

Option 2: Every environment to have its own Puppet master.

Implications:

• More costly.
  
• Feels "cleaner", each Puppet master only needs to handle one environment.
  
• Less likely for environments to interfere with each other.
  
• Potentially less (or more?) pain with managing Puppet environments.
  
• Might be overly complex.
  

Is either of these an obviously better choice than the other? If (1) is better, is sub-option (1) or (1) better?

Or are both options both viable and sane?

NB Assume that "master" may mean "masters" according to the need.

[Daniel Urist]

Option (2) allows you to test upgrades to the puppet infrastructure itself, which changes not infrequently. 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d5c26bc6-c7ce-4439-8073-41c462f9ded2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[antgel]

Yup, I had noted and discussed that with my colleagues. It's got to be a big boon. A broken Puppet that ruled them all, could cause big havoc. In fact, I seem to remember this causing big havoc in a previous workplace, where someone decided to "just upgrade Puppet" because the current version was blocking him...

Apart from that, any other pros and cons to either method? I guess not, otherwise you'd have mentioned them. :)

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

[treydock]

I think a combination of the two makes sense, and that's what we do. Our production masters have many environment to segregate systems. We also have a test master with isolated CA, mcollective, PuppetDB and Foreman to test changes to those systems.

Our test environment uses a dedicated puppet environment that way we can use a single r10k managed control repo across all systems. So things like roles and profiles and hiera data can be shared between prod and test puppet with separate changes managed in branches.

- Trey

[Jason McMahan]

I agree with Trey, ours is very similar to his as well. 

It works well when testing the latest Puppetdb for example.

[Ryan Murphy]

I currently have a Production Master and a Non-Production master.  This is nice because it makes it easier for us to use Exported Resources and have a Non-Prod Nagios server and a Prod Nagios server. That way regardless of what environment a node is in, on the Non-Prod server they will all show up in Nagios. Also it lets me accidentally break things in Non-Prod rather than testing Puppet code on the Production master right away.