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? 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang <doug.garstang@gmail.com> writes:> 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?Our plan is to do basically that but with Git branches rather than rsync. We currently already have our entire Puppet configuration in a version control system (currently Subversion), and will be converting it to Git and then using Git branches to maintain the separate environments. The advantage of Git branches is that we can much more easily merge or cherry-pick changes between the environments. For example, changes that must be made in production can be made there and then merged into test, so that test stays in sync easily but can maintain separate changes. Our intention is to then cut a new production branch from test every three months and retain two production branches, cutting each production server from the old branch over to the new branch on a quarterly cycle according to the requirements of that production environment. That way, all servers benefit from general architectural changes, but those changes are thoroughly tested first in the test/dev environments (which will all point to the master branch). -- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
2009/12/20 Russ Allbery <rra@stanford.edu>:> The advantage of Git branches is that we can much more easily merge or > cherry-pick changes between the environments. For example, changes that > must be made in production can be made there and then merged into test, so > that test stays in sync easily but can maintain separate changes. > > Our intention is to then cut a new production branch from test every three > months and retain two production branches, cutting each production server > from the old branch over to the new branch on a quarterly cycle according > to the requirements of that production environment. That way, all servers > benefit from general architectural changes, but those changes are > thoroughly tested first in the test/dev environments (which will all point > to the master branch).+1 to Russ'' approach. By maintaining branches and creating a lifecycle you can also fit the cycle to your change control, embed it in your ticketing system, etc, etc. Teaches good development lifecycle skills to admins too. :) Regards James Turnbull -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
hello, ----- "Douglas Garstang" <doug.garstang@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. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > ----- "Douglas Garstang" <doug.garstang@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. 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >> hello, >> >> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang wrote:> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: > >> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >> >>> hello, >>> >>> ----- "Douglas Garstang" <doug.garstang@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. > / > >As I currently use SVN I prefer checking out the hole svn (branches/tags/trunk) to something like /etc/puppetconfig (you may use /usr/share/ or var or whatever you prefer) and create a symlink from /etc/puppet.conf to /etc/puppetconfig/branches/production/puppet.conf. The puppet.conf in trunk is usually used when changing server configuration on a testing puppet master. Both of them describe the production environtment as /etc/puppetconfig/branches/production and development as blah/blah/blah/trunk. So for normal manifest change you work with the production puppet master with environment development, but for config changes of puppet master you work with a different computer which uses the trunk config. Good luck, Silviu -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >>> hello, >>> >>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@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 Hope that helps. 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyclak@gmail.com> wrote:> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >> <doug.garstang@gmail.com> wrote: >>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >>>> hello, >>>> >>>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. >> To unsubscribe from this group, send email to puppet-users+unsubscribe@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.ppSo, 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
hello, ----- "Douglas Garstang" <doug.garstang@gmail.com> wrote:> >>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php> > [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? Areyou really should take some time to just play with this, or at least read the links, wiki pages and samples we''ve been posting here. Internally - when configured as in the quote above, or on the url in the top bit or on the puppet wiki environment page - puppet will take care of all the serving needs for you. if your client says it''s in the environment ''development'' then for Matts example it would find files/modules/etc in /etc/puppet-development/modules:/etc/puppet-development/services The devco.net url shows you how you could branch - using svn but git can work too - just a specific module and why that might be a good choice. Just play with it, setup a master and experiment, all the needed information is there, once you play with you''ll no doubt have a ''Oh, thats how it work!'' moment. -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 21, 2009 at 11:27 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyclak@gmail.com> wrote: >> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang >> <doug.garstang@gmail.com> wrote: >>> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >>> <doug.garstang@gmail.com> wrote: >>>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >>>>> hello, >>>>> >>>>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. >>> To unsubscribe from this group, send email to puppet-users+unsubscribe@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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 21, 2009 at 8:32 AM, R.I.Pienaar <rip@devco.net> wrote:> hello, > > > ----- "Douglas Garstang" <doug.garstang@gmail.com> wrote: > >> >>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php > >> > [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 really should take some time to just play with this, or at least read the links, wiki pages and samples we''ve been posting here. > > Internally - when configured as in the quote above, or on the url in the top bit or on the puppet wiki environment page - puppet will take care of all the serving needs for you. > > if your client says it''s in the environment ''development'' then for Matts example it would find files/modules/etc in /etc/puppet-development/modules:/etc/puppet-development/services > > The devco.net url shows you how you could branch - using svn but git can work too - just a specific module and why that might be a good choice. > > Just play with it, setup a master and experiment, all the needed information is there, once you play with you''ll no doubt have a ''Oh, thats how it work!'' moment.I did read the reductive labs documentation (which is unclear as usual), and the devco site before posting here, and again after someone referenced it. I understand the concept of multiple environments quite well, and that''s not the issue. The issue is how I integrate this functionality back into subversion such that I don''t have to be constantly copying files between development and production. The devco site does NOT show you how you can branch. It says you can do it, and that''s about it. It does not address for example the issue of when making a branch, and checking the branch out to work on it, you suddenly have no puppet environment to work in. How do you test? Lastly, I have a functional config presently. I don''t want to muck around with it and break it. There''s been many a time where I''ve gotten svn confused by doing constant moves of directories etc to the point where I have to completely blow everything away in that tree and start again. 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 21, 2009 at 8:36 AM, Matthew Hyclak <hyclak@gmail.com> wrote:> On Mon, Dec 21, 2009 at 11:27 AM, Douglas Garstang > <doug.garstang@gmail.com> wrote: >> On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyclak@gmail.com> wrote: >>> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang >>> <doug.garstang@gmail.com> wrote: >>>> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >>>> <doug.garstang@gmail.com> wrote: >>>>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >>>>>> hello, >>>>>> >>>>>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. >>>> To unsubscribe from this group, send email to puppet-users+unsubscribe@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"I''m not following Matt. If you have multiple base directories, /etc/puppet, etc/puppet-development and so on, how do you serve up content from all three locations at once with a single puppet master? I know there''s environments, but are you saying the puppet.conf in /etc/puppet refers to module and manifest dirs that are outside /etc/puppet in /etc/puppet-development? 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
hello, ''lo,> I did read the reductive labs documentation (which is unclear as > usual), and the devco site before posting here, and again after > someone referenced it. I understand the concept of multiple > environments quite well, and that''s not the issue. The issue is how I > integrate this functionality back into subversion such that I don''t > have to be constantly copying files between development and > production. > > The devco site does NOT show you how you can branch. It says you can > do it, and that''s about it. It does not address for example the issue > of when making a branch, and checking the branch out to work on it, > you suddenly have no puppet environment to work in. How do you test? >Based on the devco site. All your modules would live generally one directory, /etc/puppet/manifests/common/modules the modules there would apply to all your environments. Now you decide to work on your apache module in test. svn copy common/modules/apache development/modules/apache < edit files in development etc > svn ci development/modules/apache -m ''start dev on apache'' At this point, and if your puppetmaster has an up to date svn checkout, machines in the ''development'' environment will get your development version of the apache module you still need machines to test with, they still need to talk to a puppetmaster but this helps you isolate versions of code. Since development also still point at common should your apache module rely on your php module then it would just grab it from common (unless you also branched that). Now you''re done testing, you''re happy it works and you want to make your apache module the same as devel one everywhere, just merge the changes into common and ''svn delete development/modules/apache'' when done. Now all machines have the new module and you''ve been able to test it in isolation on your dev machines. This is a very simple approach it, maybe you have releases every tuesday, or maybe you have multiple environments between dev and production, you can adapt this approach to those no doubt I just kept it simple to get the concept across. For example many places have an environment per developer so they can just have their own test boxes (maybe VMs on their desktops). -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Mon, Dec 21, 2009 at 11:45 AM, Douglas Garstang <doug.garstang@gmail.com> wrote:> On Mon, Dec 21, 2009 at 8:36 AM, Matthew Hyclak <hyclak@gmail.com> wrote: >> On Mon, Dec 21, 2009 at 11:27 AM, Douglas Garstang >> <doug.garstang@gmail.com> wrote: >>> On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyclak@gmail.com> wrote: >>>> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang >>>> <doug.garstang@gmail.com> wrote: >>>>> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >>>>> <doug.garstang@gmail.com> wrote: >>>>>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: >>>>>>> hello, >>>>>>> >>>>>>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. >>>>> To unsubscribe from this group, send email to puppet-users+unsubscribe@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" > > I''m not following Matt. If you have multiple base directories, > /etc/puppet, etc/puppet-development and so on, how do you serve up > content from all three locations at once with a single puppet master? > I know there''s environments, but are you saying the puppet.conf in > /etc/puppet refers to module and manifest dirs that are outside > /etc/puppet in /etc/puppet-development? > > Doug.Yes, that''s what: [development] modulepath = /etc/puppet-development/modules:/etc/puppet-development/services manifest = /etc/puppet-development/manifests/site.pp does. When a client connects and says it is in the development environment (either by --environment= or it''s puppet.conf), the modules it uses are from /etc/puppet-development/modules, not from /etc/puppet/modules. This way, we keep production and staging (QA) versioned (svn tag). Anything in development is a moving target (svn trunk). Each puppet directory on the puppetmaster are complete checkouts of subversion (either trunk or a tag/branch). 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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
hello,> >>> 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> I''m not following Matt. If you have multiple base directories, > /etc/puppet, etc/puppet-development and so on, how do you serve up > content from all three locations at once with a single puppet master? > I know there''s environments, but are you saying the puppet.conf in > /etc/puppet refers to module and manifest dirs that are outside > /etc/puppet in /etc/puppet-development?/etc/puppet isn''t special in any way, it''s just a directory. Look at the sample config quoted above, it tells the master a different modulepath and manifest for each environment. So machines in staging and machines in development gets served by the master based on this config from other directories, doesn''t matter where they are. When a development machines does: include apache or source => puppet:///apache/httpd.conf it will fetch the code for the apache class from /etc/puppet-development/modules/apache/manifests/init.pp and the file from /etc/puppet-development/modules/apache/files/httpd.conf -- R.I.Pienaar -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang wrote:> 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). > >You can do that with multiple config.ru. But IMHO it would be better to stick with multiple environments for most cases. The development config.ru would look like (BIG NOTE: > 0.25): # a config.ru, for use with every rack-compatible webserver. # SSL needs to be handled outside this, though. # if puppet is not in your RUBYLIB: # $:.unshift(''/opt/puppet/lib'') $0 = "puppetmasterd" require ''puppet'' #HERE - ADD THIS LINE ARGV << "--confdir=/etc/puppet-devel" ARGV << "--rack" require ''puppet/application/puppetmasterd'' # we''re usually running inside a Rack::Builder.new {} block, # therefore we need to call run *here*. run Puppet::Application[:puppetmasterd].run -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Dec 19, 2009, at 11:54 PM, Douglas Garstang 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?My setup is pretty simple and doesn''t require manually copying anything, so I figured I''d share. I have three directories: /etc/puppet/manifests/prod /etc/puppet/manifests/test /etc/puppet/manifests/experimental Each of those is a working copy of the same SVN repo. Production systems (and others - see below) are given the `prod` manifests. Development, Test, and Staging systems are given the `test` manifests. `experimental` is where the manifests are actually worked on. I''ll temporarily set the environment to experimental on as many systems as it takes to make me comfortable that changes are good. Once I like them, I commit them, then `svn update test`. Depending on the scope of the change and my confidence in what I''ve done, I''ll either update `prod` as well, or go through $employer''s change control process. In `/etc/puppet.conf`, I have these at the end: # Additional environments [dev] manifest = /etc/puppet/manifests/test/site.pp modulepath = /etc/puppet/manifests/test/modules [test] manifest = /etc/puppet/manifests/test/site.pp modulepath = /etc/puppet/manifests/test/modules [staging] manifest = /etc/puppet/manifests/test/site.pp modulepath = /etc/puppet/manifests/test/modules # Experimental environment (primarily for Puppet tests) [experimental] manifest = /etc/puppet/manifests/experimental/site.pp modulepath = /etc/puppet/manifests/experimental/modules (I don''t currently do anything with modules, but I defined them in case I do one day.) The configuration above this, where the defaults are specified independent of any environment, points to the `prod` manifests. The defaults get applied to any system where the environment doesn''t match one explicitly defined. This includes systems with an environment of "prod", but more importantly, it includes systems with no environment at all. The idea being that the `prod` manifests are safest, so when in doubt, use those. As for putting systems into each environment, I have all mine in LDAP with an attribute called `environment`. Others have pointed out that there are ways to pull it off by manually touching each machine, if you''re into that kind of thing. :) -- Rob McBroom <http://www.skurfer.com/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang wrote:> On Mon, Dec 21, 2009 at 8:32 AM, R.I.Pienaar <rip@devco.net> wrote: > >> hello, >> >> >> ----- "Douglas Garstang" <doug.garstang@gmail.com> wrote: >> >> >>>>>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php >>>>>>> >>>> [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 really should take some time to just play with this, or at least read the links, wiki pages and samples we''ve been posting here. >> >> Internally - when configured as in the quote above, or on the url in the top bit or on the puppet wiki environment page - puppet will take care of all the serving needs for you. >> >> if your client says it''s in the environment ''development'' then for Matts example it would find files/modules/etc in /etc/puppet-development/modules:/etc/puppet-development/services >> >> The devco.net url shows you how you could branch - using svn but git can work too - just a specific module and why that might be a good choice. >> >> Just play with it, setup a master and experiment, all the needed information is there, once you play with you''ll no doubt have a ''Oh, thats how it work!'' moment. >> > > I did read the reductive labs documentation (which is unclear as > usual), and the devco site before posting here, and again after > someone referenced it. I understand the concept of multiple > environments quite well, and that''s not the issue. The issue is how I > integrate this functionality back into subversion such that I don''t > have to be constantly copying files between development and > production. > > The devco site does NOT show you how you can branch. It says you can > do it, and that''s about it. It does not address for example the issue > of when making a branch, and checking the branch out to work on it, > you suddenly have no puppet environment to work in. How do you test? > > Lastly, I have a functional config presently. I don''t want to muck > around with it and break it. There''s been many a time where I''ve > gotten svn confused by doing constant moves of directories etc to the > point where I have to completely blow everything away in that tree and > start again. > > 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-users@googlegroups.com. > To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. > > >Doug, I am not a version control expert but I think you might be confusing svn branches with cvs branches. As soon as you do: svn cp production development: you''ve not only made a new puppet environment, you''ve ''branched'' production into development. -- Joe McDonagh Silent Penguin Services Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode Blog: www.colonfail.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>> > Doug, I am not a version control expert but I think you might be > confusing svn branches with cvs branches. > As soon as you do: > > svn cp production development: > > you''ve not only made a new puppet environment, you''ve ''branched'' > production into development.I''d also recommend using a more fully featured DVCS like Git or Mercurial etc - their capabilities allow for much more flexible approaches. Regards James Turnbull -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
We''re look into ways to implement change management to our puppet configurations, and this approach is very interesting as it seems very straight forward and easy to maintain (btw, it''s very similar to the approach described on http://fnord.no/sysadmin/puppet/staging). As described on that web site, I''m thinking we could implement a script (i.e. svn-update script) that checks out individual modules based on specific tags. I''m guessing you have created a similar type of script. When making changes to a module, I''d like to make sure that that module is tested in development, testing and qass before being implemented on production servers. An idea would be to have that svn-update script enforce this policy by ensuring that only modules that are tagged for a specific environment can be updated on that particular environment. Let me illustrate by an example: Support we have module "ldap". When it''s ready for testing, we tags it for example like this "ldap_1.0_testing". In order to update it in the testing environment, the svn-update script verifies that that the module is suffixed by the keyword "testing". Furthermore, when ready for the qass environment, we tag the module again with "ldap_1.0_qass", so that the svn-update script will allow us to update the qass environment. Have anyone else developed a similar setup to ensure that modules are not updated on production servers before being tested on qass servers? Any comments on the idea I just described? Another issue I need to solve is how to test new versions of the puppetmaster. I''d like to organize testing of puppetmaster the same way l described above. In order to do this I suspect I need to figure out two things: 1) How can I install to versions of the RPM package containing puppetmaster on the same linux server? 2) How can I have the old puppetmaster hosting for example "production and qass", at the same time as having the new puppetmaster hosting "testing" and "development"? Do I have to have them running on different ports, and manually modify the /etc/puppet.conf file for each wrt modulepath etc? Best regards, Kenneth Holter Only tags that have for example "<module-name>_<module-version_testing" can be updated in the qass env, and On Mon, Dec 21, 2009 at 4:44 PM, Matthew Hyclak <hyclak@gmail.com> wrote:> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang > <doug.garstang@gmail.com> wrote: > > On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang > > <doug.garstang@gmail.com> wrote: > >> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <rip@devco.net> wrote: > >>> hello, > >>> > >>> ----- "Douglas Garstang" <doug.garstang@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-users@googlegroups.com. > > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@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 > > > Hope that helps. > > 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-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Kenneth Holter wrote:> > We''re look into ways to implement change management to our puppet > configurations, and this approach is very interesting as it seems very >Even easier: Maintain multiple Puppet infrastructures. Push your code to each as it is ready. Dev puppetmaster, dev puppet clients. Staging puppetmaster, staging puppet clients. Production puppetmaster, production puppet clients. It also will enable you to maintain a staging environment that is as close to prod as possible. -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Do you mean running puppetmaster on different linux servers? It would probably be the best solution, but I do think I prefer running multiple puppetmasters on one linux server if possible.. How are other people testing new puppetmasters? On Thu, Dec 31, 2009 at 6:42 PM, Scott Smith <scott@ohlol.net> wrote:> Kenneth Holter wrote: > > > > We''re look into ways to implement change management to our puppet > > configurations, and this approach is very interesting as it seems very > > > > Even easier: Maintain multiple Puppet infrastructures. Push your code to > each as it is ready. > > Dev puppetmaster, dev puppet clients. > Staging puppetmaster, staging puppet clients. > Production puppetmaster, production puppet clients. > > It also will enable you to maintain a staging environment that is as close > to prod as possible. > > -scott > > -- > > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Kenneth Holter wrote:> Do you mean running puppetmaster on different linux servers? It would > probably be the best solution, but I do think I prefer running multiple > puppetmasters on one linux server if possible.. How are other people > testing new puppetmasters? >What?! You mean your puppetmaster binds to every available interface on port 8140? Really? :) -scott -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Fri, 8 Jan 2010, Kenneth Holter wrote:> Do you mean running puppetmaster on different linux servers? It would > probably be the best solution, but I do think I prefer running multiple > puppetmasters on one linux server if possible.. How are other people > testing new puppetmasters? > > On Thu, Dec 31, 2009 at 6:42 PM, Scott Smith <scott@ohlol.net> wrote: > Kenneth Holter wrote: > > > > We''re look into ways to implement change management to our puppet > > configurations, and this approach is very interesting as it seems very > > > > Even easier: Maintain multiple Puppet infrastructures. Push your code to each as it is ready. > > Dev puppetmaster, dev puppet clients. > Staging puppetmaster, staging puppet clients. > Production puppetmaster, production puppet clients. > > It also will enable you to maintain a staging environment that is as close to prod as possible. > > -scottWe use multiple puppetmasters and branches. Virtualization makes it easy to spin up new puppetmasters. We have lab environments where we develop and test puppet code and each of those has its own puppetmaster and branch. Some admins have a personal puppetmaster and branch and we''ll also spin masters for specific projects. After testing the code in a branch we merge to trunk. Dev and QA systems run off trunk and after the changes pass QA we merge to a prod branch. In the future we''re going to take a tag off trunk and release that to the production puppetmasters. We''ve found that multiple branches can be tricky to keep in sync so we make a point of frequent merges to trunk and rebranching. Otherwise trunk and the branches get so out of sync that merging becomes a real chore. -Eric -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.