Ok folks, I''ve read BestPractices and probably most of the wiki docs but I am still banging my head about how to layout a new puppet deployment. Everything is fresh, fresh repo, fresh puppet install. We will use SVN for version control. Here are some of my challenges. I go back and forth on how I feel best to solve them so I would appreciate any input. My company manages about 200 Linux boxes mostly RHEL4 and RHEL5. We have four datacenters which each requires a different resolvers, ldap settings, proxy server etc etc etc. Additionally we have customers who sometimes have settings that differ from that of the rest of the datacenter and further still, host ''classes'' or services, webserver, database server etc. 1. What are some good ways to organize all of this both from a file perspective? Does it make sense to define defaults in classes and then override them in datacenter classes? i.e. resolver class has resolver::list [ ''1.2.3.4'' ] then a datacenter class overrides it with Resolver::list [ ''4.4.4.4'' ] or maybe just append to it. 2. What is a class and what is a module? classes: datacenter datacenter::a customer customer::one service service::s_www service::s_sldap modules: resolver authconfig (ldap, nss_ldap) logrotate (basically matching the name of the package it configures) Then a node gets a datacenter, customer and service class which rely on the modules to make config changes. I would like to have the option of doing things additively and not just strictly replace values. For example in datacenter a the resolvers might be 1.1.1.1 and 2.2.2.2 but customer one wants to add their primary dc as the first resolver making their resolvers 3.3.3.3, 1.1.1.1, 2.2.2.2. But if we update the datacenter a resolvers to 2.2.2.2, 4.4.4.4 customer one''s server in datacenter a ends up with resolvers 3.3.3.3, 2.2.2.2, 4.4.4.4. 3. How to organize subversion repo, I want to have testing and development. puppet/trunk - development {modules,manifests,plugins,puppet.conf,etc.} puppet/tags/production/{modules,manifests,plugins,puppet.conf,etc.} puppet/tags/testing/{modules,manifests,plugins,etc.} (no need for puppet.conf and a few other things) So pretend you are starting anew, what would you do differently? Regards, -Alan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Alan, One thing I found handy was to build up 2 custom facts to add into facter: defaultroute and site. defaultroute is used to determine which site a host is in... Personally I found the class heirarchy too limited since you can''t inherit from multiple places... So you would need classes like site1-webserver, site2-webserver, site1-database, site2-database and so on... Too annoying. Adding in these custom facts allows you to add in config files based on which site the node lives. For example: file { "/etc/resolv.conf": source => "puppet:///network/resolv.conf-$site" owner => root, group => root, mode => 644 } Heres the custom facts I added. (Note: the default route is Solaris specific as I don''t need to manage any Linux boxes at my site) (Also note: My knowledge of Ruby is *really* basic at this stage, apologies if this code is bad) defaultroute.rb: Facter.add("defaultroute") do setcode do defroutefh = File.open("/etc/defaultrouter") defroutefh.readline.chomp end end site.rb: Facter.add("site") do setcode do case Facter.value(''defaultroute'') when "10.0.0.1" "site1" when "10.0.0.2", "10.0.0.3" "site2" else "unknown" end end end Now, this makes the answer to q1 a bit easier... I have mine modularised into groups based on what the config is about. Networking config is in one module, sudo management in another and so on. That way its (hopefully) more sane when you come to make changes. I guess the granularity that you put this on is up to you. 2. I will leave this one to someone more experienced with Puppet than me, but I use modules to group similar classes together - kind of like a library. Its probably a very simplistic view of things, but so far it has worked well for me... 3. My svn repository is set up as follows: - baseline/ Main trunk - This is where most of the work gets done... Keep your live Puppet Master config tree here... - tags/ Contains discrete release views. - branches/ Haven''t used this yet, but I''m planning on using this for larger changes, development work and so forth... I''m sure I have missed out something that I''m going to need later on, but figure its a reasonable starting point... --~--~---------~--~----~------------~-------~--~----~ 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, I would say that this is a good idea except for the custom fact part. Since these are not items that you will ''discover'' from the system, a custom function that looks up items in a table/LDAP server/whatever would be more appropriate. This reduces the load on both your clients and your network. Yes, not by much for only two facts but, once you start down this path, you will rapidly have a glut of facts that could more easily be discovered by the server. Trevor On Wed, May 6, 2009 at 03:26, Greg <greg.boug@gmail.com> wrote:> > Alan, > > One thing I found handy was to build up 2 custom facts to add into > facter: defaultroute and site. > defaultroute is used to determine which site a host is in... > Personally I found the class heirarchy > too limited since you can''t inherit from multiple places... So you > would need classes like site1-webserver, > site2-webserver, site1-database, site2-database and so on... Too > annoying. > > Adding in these custom facts allows you to add in config files based > on which site the node lives. > For example: > > file { "/etc/resolv.conf": > source => "puppet:///network/resolv.conf-$site" > owner => root, group => root, mode => 644 > } > > Heres the custom facts I added. > (Note: the default route is Solaris specific as I don''t need to manage > any Linux boxes at my site) > (Also note: My knowledge of Ruby is *really* basic at this stage, > apologies if this code is bad) > > defaultroute.rb: > Facter.add("defaultroute") do > setcode do > defroutefh = File.open("/etc/defaultrouter") > defroutefh.readline.chomp > end > end > > site.rb: > Facter.add("site") do > setcode do > case Facter.value(''defaultroute'') > when "10.0.0.1" > "site1" > when "10.0.0.2", "10.0.0.3" > "site2" > else > "unknown" > end > end > end > > Now, this makes the answer to q1 a bit easier... I have mine > modularised into groups based on what the config is about. Networking > config is in one module, sudo management in another and so on. That > way its (hopefully) more sane when you come to make changes. I guess > the granularity that you put this on is up to you. > > 2. I will leave this one to someone more experienced with Puppet than > me, but I use modules to group similar classes > together - kind of like a library. Its probably a very simplistic view > of things, but so far it has worked well for me... > > 3. My svn repository is set up as follows: > > - baseline/ > Main trunk - This is where most of the work gets done... Keep > your live Puppet Master config tree here... > - tags/ > Contains discrete release views. > - branches/ > Haven''t used this yet, but I''m planning on using this for > larger changes, development work and so forth... > > I''m sure I have missed out something that I''m going to need later on, > but figure its a reasonable starting point... > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hey Alan, On Fri, May 8, 2009 at 9:11 AM, Trevor Vaughan <peiriannydd@gmail.com> wrote:> > Hi, > > I would say that this is a good idea except for the custom fact part. > > Since these are not items that you will ''discover'' from the system, a > custom function that looks up items in a table/LDAP server/whatever > would be more appropriate.I agree with Trevor. It really is about whether or not you are talking about assignment or discovery. If you are discovering intrinsic qualities of a node then a custom fact makes sense. If you are assigning a value to a node or your provisioning tool is assigning that value then a function makes sense. Obviously, there is a gray area here. Alternatively, you could use an external nodes to tool. Currently, LDAP functions as a external nodes terminus, http://reductivelabs.com/trac/puppet/wiki/LDAPNodes.> > This reduces the load on both your clients and your network. Yes, not > by much for only two facts but, once you start down this path, you > will rapidly have a glut of facts that could more easily be discovered > by the server. > > Trevor > > On Wed, May 6, 2009 at 03:26, Greg <greg.boug@gmail.com> wrote: >> >> Alan, >> >> One thing I found handy was to build up 2 custom facts to add into >> facter: defaultroute and site. >> defaultroute is used to determine which site a host is in... >> Personally I found the class heirarchy >> too limited since you can''t inherit from multiple places... So you >> would need classes like site1-webserver, >> site2-webserver, site1-database, site2-database and so on... Too >> annoying. >> >> Adding in these custom facts allows you to add in config files based >> on which site the node lives. >> For example: >> >> file { "/etc/resolv.conf": >> source => "puppet:///network/resolv.conf-$site" >> owner => root, group => root, mode => 644 >> } >> >> Heres the custom facts I added. >> (Note: the default route is Solaris specific as I don''t need to manage >> any Linux boxes at my site) >> (Also note: My knowledge of Ruby is *really* basic at this stage, >> apologies if this code is bad) >> >> defaultroute.rb: >> Facter.add("defaultroute") do >> setcode do >> defroutefh = File.open("/etc/defaultrouter") >> defroutefh.readline.chomp >> end >> end >> >> site.rb: >> Facter.add("site") do >> setcode do >> case Facter.value(''defaultroute'') >> when "10.0.0.1" >> "site1" >> when "10.0.0.2", "10.0.0.3" >> "site2" >> else >> "unknown" >> end >> end >> end >> >> Now, this makes the answer to q1 a bit easier... I have mine >> modularised into groups based on what the config is about. Networking >> config is in one module, sudo management in another and so on. That >> way its (hopefully) more sane when you come to make changes. I guess >> the granularity that you put this on is up to you. >> >> 2. I will leave this one to someone more experienced with Puppet than >> me, but I use modules to group similar classes >> together - kind of like a library. Its probably a very simplistic view >> of things, but so far it has worked well for me... >> >> 3. My svn repository is set up as follows: >> >> - baseline/ >> Main trunk - This is where most of the work gets done... Keep >> your live Puppet Master config tree here... >> - tags/ >> Contains discrete release views. >> - branches/ >> Haven''t used this yet, but I''m planning on using this for >> larger changes, development work and so forth... >> >> I''m sure I have missed out something that I''m going to need later on, >> but figure its a reasonable starting point... >> > >> > > > >-- Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> If you are assigning a value to a node or your provisioning tool is assigning > that value then a function makes sense.Can you elaborate on how you would use a function in this case? -Ben --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---