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 puppet-users+unsubscr...@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
