On Mon, Dec 21, 2009 at 11:27 AM, Douglas Garstang <doug.garst...@gmail.com> wrote: > 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. >
There is one puppetmaster (well, mongrel) listening on 8140. Environments are built in to puppet, so you don't have to do anything different. We have a different client puppet.conf for each environment that specifies the right paths. Changing a client from one environment to another is as simple as "puppetd -t --environment=newenvironment" Matt -- 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.
