Hi John, Thank you for a most well considered response given my level of understanding. I'd much appreciate an example of a system sliced along 2 or more different dimensions that need to be flattened into one, this is the only part not clear to me.
Regards, Jeremy. On Monday, August 19, 2013 3:49:04 PM UTC+2, jcbollinger wrote: > > > > On Monday, August 19, 2013 1:59:46 AM UTC-5, JeremyCampbell wrote: >> >> I've setup dynamic environments using git but I'm confused about how >> environments are actually supposed to be used. We're a small ISP and have >> freeradius servers, VPN servers and web servers. I've been using >> environments to enable me as the sysadmin to build and test new >> manifests/modules before deploying them to our production servers. I have >> dedicated staging servers, one for each role (web,vpn,aaa), that are >> configured with the 'staging' environment. My workflow involves developing >> locally (with a local puppetmaster), pushing commits on the staging branch >> and then QA on the staging servers and then merging the staging branch into >> production and pushing to deploy it. >> >> However, our web development team have now requested their own >> staging/production environments for the web applications they are building. >> I then thought that perhaps these servers should be modelled using >> environments. Then I thought 'but these are application testing >> environments running in a production environment so they should have >> nothing to do with puppet environments'. I've managed to confuse myself, >> any help untangling my confusion would be greatly appreciated, thank you! >> > > > Do not read too much into the term "environment". Puppet environments are > a mechanism for partitioning your machines under management into groups > that (may) rely on separate[*] manifests, modules, and data. The feature > is often used to implement configuration staging in the form you describe > using now, but that is not their only possible use. For example, it might > in some cases make sense to use environments to separate machines assigned > to different divisions of the company, different geographic locations, etc.. > > Importantly, if you want to slice your systems along two (or more) > different dimensions then you need to flatten those into one. That can > certainly be done, but it doesn't scale well. > > [*] Note, too, that partitioning is incomplete: different environments > served by the same master cannot provide different binary plugins (custom > facts, functions, types, or providers). > > Inasmuch as you are uncertain how to proceed, I would avoid creating new > Puppet environments for now. You should have a good idea of why you want > separate environments before you create any. It is likely that you can use > ordinary Puppet facilities within each environment to manage the dev team's > different machine roles, if they even have different configuration > requirements in the first place. > > > John > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
