I have questions about Puppet''s scalability. I am looking for info about how one might have multiple cooperating PuppetMasters on a network. I have found old links that talk about merging Puppet and Func, but they all seem out of date. My questions go more toward delegated puppet-mastering rather than data volume as I will attempt to explain: Picture a three-tier operations set-up with development, QA, and production environments. I have set up a Puppet Master in the development environment. I would like to expand the use of Puppet to cover all three environments, but the practice is to minimize cross-traffic as much as possible. So, what I would like to be able to do is have a Master PuppetMaster in dev which feeds two Deputy PuppetMasters in QA and production. Each of the three PuppetMasters would manage the clients in their environment, and the cross-traffic would be minimized to only between PuppetMasters. I have brain-stormed on my own and I have a couple of possibilities, but they all feel like messy hacks so far. So, I thought I''d ask here before trying any of my ideas. -- 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.
Hi Dan, A lot of people use a revision control system like SVN or Git, and each Puppet Master independently pulls a revision of Puppet code from this repository. You could manually control or setup some automatic method of upgrading your QA and prod machines to certain revisions. Your Dev puppet master then ''decides'' what revision your QA and Prod puppet masters need to have checked out. There''s a few Puppet modules around that handle checking out from repositories, or it wouldn''t be difficult to write your own. Depending on how many people you have committing to your Puppet repository though this could get troublesome, as if I wanted to push my revision 10 code to QA, i''ve also pushed my colleague''s revision 7, 8 and 9 code which has made changes I wasn''t expecting. This is where we are at the moment, it''s only started to become an issue as more and more people get comfortable with puppet. Our next evolution might be to have branches for each environment, so if I want to push my code from Dev to QA I just have to merge my change from Dev to QA in the Puppet repository and (hopefully) not have to worry about anything anyone else has been committing to Dev. On 20/01/12 04:34, Dan White wrote:> I have questions about Puppet''s scalability. > I am looking for info about how one might have multiple cooperating PuppetMasters on a network. > > I have found old links that talk about merging Puppet and Func, but they all seem out of date. > > My questions go more toward delegated puppet-mastering rather than data volume as I will attempt to explain: > > Picture a three-tier operations set-up with development, QA, and production environments. > > I have set up a Puppet Master in the development environment. > I would like to expand the use of Puppet to cover all three environments, but the practice is to minimize cross-traffic as much as possible. > > So, what I would like to be able to do is have a Master PuppetMaster in dev which feeds two Deputy PuppetMasters in QA and production. > Each of the three PuppetMasters would manage the clients in their environment, > and the cross-traffic would be minimized to only between PuppetMasters. > > I have brain-stormed on my own and I have a couple of possibilities, but they all feel like messy hacks so far. > So, I thought I''d ask here before trying any of my ideas.-- Luke Bigum Information Systems +44 (0) 20 3192 2520 Luke.Bigum@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- 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.
Thanks for responding. This approach is similar to one of the (messy) ideas I have. It seems to me that there are no built-in features that will let me do this, so I am (once again) trail-blazing. I like the idea of the Dev/Overlord PM using Puppet/(revision control) to run the Deputy PM''s. That keeps everything in the revision control system. Thank you for sharing that. "He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me.” Thomas Jefferson ----- Luke Bigum <Luke.Bigum@lmax.com> wrote:> Hi Dan, > > A lot of people use a revision control system like SVN or Git, and each > Puppet Master independently pulls a revision of Puppet code from this > repository. You could manually control or setup some automatic method of > upgrading your QA and prod machines to certain revisions. Your Dev > puppet master then ''decides'' what revision your QA and Prod puppet > masters need to have checked out. There''s a few Puppet modules around > that handle checking out from repositories, or it wouldn''t be difficult > to write your own. > > Depending on how many people you have committing to your Puppet > repository though this could get troublesome, as if I wanted to push my > revision 10 code to QA, i''ve also pushed my colleague''s revision 7, 8 > and 9 code which has made changes I wasn''t expecting. This is where we > are at the moment, it''s only started to become an issue as more and more > people get comfortable with puppet. Our next evolution might be to have > branches for each environment, so if I want to push my code from Dev to > QA I just have to merge my change from Dev to QA in the Puppet > repository and (hopefully) not have to worry about anything anyone else > has been committing to Dev. > > On 20/01/12 04:34, Dan White wrote: > > I have questions about Puppet''s scalability. > > I am looking for info about how one might have multiple cooperating PuppetMasters on a network. > > > > I have found old links that talk about merging Puppet and Func, but they all seem out of date. > > > > My questions go more toward delegated puppet-mastering rather than data volume as I will attempt to explain: > > > > Picture a three-tier operations set-up with development, QA, and production environments. > > > > I have set up a Puppet Master in the development environment. > > I would like to expand the use of Puppet to cover all three environments, but the practice is to minimize cross-traffic as much as possible. > > > > So, what I would like to be able to do is have a Master PuppetMaster in dev which feeds two Deputy PuppetMasters in QA and production. > > Each of the three PuppetMasters would manage the clients in their environment, > > and the cross-traffic would be minimized to only between PuppetMasters. > > > > I have brain-stormed on my own and I have a couple of possibilities, but they all feel like messy hacks so far. > > So, I thought I''d ask here before trying any of my ideas. > -- > Luke Bigum > Information Systems > +44 (0) 20 3192 2520 > Luke.Bigum@lmax.com | http://www.lmax.com > LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN > > > The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. > > -- > 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. >-- 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.
There are some good write ups on this topic at: http://docs.puppetlabs.com/guides/environment.html http://puppetlabs.com/blog/git-workflow-and-puppet-environments/ You are certainly not the first to use this type of workflow. On Fri, Jan 20, 2012 at 6:10 AM, Dan White <ygor@comcast.net> wrote:> Thanks for responding. > > This approach is similar to one of the (messy) ideas I have. > > It seems to me that there are no built-in features that will let me do this, so I am (once again) trail-blazing. > > I like the idea of the Dev/Overlord PM using Puppet/(revision control) to run the Deputy PM''s. That keeps everything in the revision control system. > > Thank you for sharing that. > > "He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me.” > Thomas Jefferson > > ----- Luke Bigum <Luke.Bigum@lmax.com> wrote: >> Hi Dan, >> >> A lot of people use a revision control system like SVN or Git, and each >> Puppet Master independently pulls a revision of Puppet code from this >> repository. You could manually control or setup some automatic method of >> upgrading your QA and prod machines to certain revisions. Your Dev >> puppet master then ''decides'' what revision your QA and Prod puppet >> masters need to have checked out. There''s a few Puppet modules around >> that handle checking out from repositories, or it wouldn''t be difficult >> to write your own. >> >> Depending on how many people you have committing to your Puppet >> repository though this could get troublesome, as if I wanted to push my >> revision 10 code to QA, i''ve also pushed my colleague''s revision 7, 8 >> and 9 code which has made changes I wasn''t expecting. This is where we >> are at the moment, it''s only started to become an issue as more and more >> people get comfortable with puppet. Our next evolution might be to have >> branches for each environment, so if I want to push my code from Dev to >> QA I just have to merge my change from Dev to QA in the Puppet >> repository and (hopefully) not have to worry about anything anyone else >> has been committing to Dev. >> >> On 20/01/12 04:34, Dan White wrote: >> > I have questions about Puppet''s scalability. >> > I am looking for info about how one might have multiple cooperating PuppetMasters on a network. >> > >> > I have found old links that talk about merging Puppet and Func, but they all seem out of date. >> > >> > My questions go more toward delegated puppet-mastering rather than data volume as I will attempt to explain: >> > >> > Picture a three-tier operations set-up with development, QA, and production environments. >> > >> > I have set up a Puppet Master in the development environment. >> > I would like to expand the use of Puppet to cover all three environments, but the practice is to minimize cross-traffic as much as possible. >> > >> > So, what I would like to be able to do is have a Master PuppetMaster in dev which feeds two Deputy PuppetMasters in QA and production. >> > Each of the three PuppetMasters would manage the clients in their environment, >> > and the cross-traffic would be minimized to only between PuppetMasters. >> > >> > I have brain-stormed on my own and I have a couple of possibilities, but they all feel like messy hacks so far. >> > So, I thought I''d ask here before trying any of my ideas. >> -- >> Luke Bigum >> Information Systems >> +44 (0) 20 3192 2520 >> Luke.Bigum@lmax.com | http://www.lmax.com >> LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN >> >> >> The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. >> >> -- >> 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. >> > > -- > 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. >-- 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.