On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyc...@gmail.com> wrote: > On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang > <doug.garst...@gmail.com> wrote: >> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >> <doug.garst...@gmail.com> wrote: >>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <r...@devco.net> wrote: >>>> hello, >>>> >>>> ----- "Douglas Garstang" <doug.garst...@gmail.com> wrote: >>>> >>>>> I'd like to be able to split out my puppet production and test >>>>> environments so that I can continue to develop puppet >>>>> modules/manifests without breaking production. How are people doing >>>>> this? Puppet environments may be one way. I guess I'd have a >>>>> main(prod) environment and a test one. When I was finished with >>>>> testing, I could rsync the files over to the prod environment. Is >>>>> this >>>>> how others are doing it? >>>> >>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php >>>> >>>> That's how I do it, aim is to avoid many copies of the same module just >>>> because we have multiple environments, but still have the ability to >>>> create those versions during the dev cycle. >>>> >>>> not for everyone, but maybe it help you in the right direction. >>> >>> Thanks to everyone for the replies. >>> >>> Are you using multiple environments though? And, if using multiple >>> environments, how do you structure it? The puppet documentation is a >>> bit vague on the subject. For instance, it's not clear to me if you >>> would structure it so that you have a top level dir ABOVE puppet >>> called prod, test etc, or if you would create subdirs BELOW manifests, >>> modules etc called prod, test. >>> >>> The next question is, where do you branch? If you have a top level dir >>> above puppet, I guess that's pretty easy, but if you have multiple >>> dirs below manifests, modules etc, then you'd need to branch each >>> which becomes more complex. >> >> Hmmm. I'm not following this here. At the moment I have /etc/puppet, >> which is a working copy. Every now and then I commit my changes. I can >> add a dev environment to this working copy and safely use that to test >> modules and manifests on dev nodes, but there's still no way for me to >> roll those changes back to the production environment without some >> manual process. >> >> I could make a branch of /etc/puppet, and check it out, but then I'd >> need a second copy of puppetmaster running in a second location to >> test it against. I'm using passenger, so maybe I could fire up a >> second instance on another port, and maybe that would work. >> >> If I was to branch the prod dir inside puppet into a dev dir, then >> this is kind of where I get lost. If I was to branch /etc/puppet/dev >> or simialar, once again I'd need to check it out into a new location >> where I could work on it, and test it. This still needs a second copy >> of puppetmaster running, and it's actually worse this way because I >> don't have all the necessary puppet config from further up the tree. >> >> Grrrr. >> >> -- >> >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> >> >> > > We handle this as follows: > > Puppetmaster has /etc/puppet, /etc/puppet-development, > /etc/puppet-staging (among others) > > /etc/puppet-development -> svn checkout of trunk, updated whenever we > feel like it > /etc/puppet-staging -> svn checkout of a tag, updated Tuesdays > /etc/puppet -> svn checkout of a tag, updated Thursdays (allows 2 days > of testing a tag in Staging) > > puppet.conf contains (in addition to the standard stuff): > > [staging] > modulepath = /etc/puppet-staging/modules:/etc/puppet-staging/services > manifest = /etc/puppet-staging/manifests/site.pp > > [development] > modulepath = > /etc/puppet-development/modules:/etc/puppet-development/services > manifest = /etc/puppet-development/manifests/site.pp
So, Matt, it looks like you have three completely different puppet areas (/etc/puppet, /etc/puppet-development and so on). That's kind of what I thought I might need to do. There's no point in branching a specific directory inside puppet because then you don't have the rest of the stuff puppet needs to run, and... I'm not sure how svn feels about a branch INSIDE a working copy. But... how do you serve up those multiple puppet environments? Are you running multiple versions of the puppetmaster? I'm using passenger so it would seem like it would be fairly easy to run additional puppetmasters on different ports, except that I can't find where in the passenger config I can change the default /etc/puppet (it's not in the conf.d/puppetmaster.conf file). With multiple puppetmasters running, you would also need to configure each client to use a different port. I guess.... that's.... ok as long as you aren't changing the role of nodes from dev to prod and back. Doug Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
