Hey all, I''m rather new to Puppet (but I really like what I see) and am trying to get started on the right foot. I would like to define my modules in a generic fashion so that if I have to change something in the future it doesn''t break. For instance, I want to monitor all my servers, but instead of defining a ''zabbix-agent'' module I''ve built a module named ''monitoring''. That way if I want to change to Cacti or SNMP I can just change the ''monitoring'' module and not have to touch anything else. Another example would be switching between different databases (mysql, PostgreSQL. SQLite, etc.) Does this seem like the proper thing to do? Or should I build out a zabbix-agent module and a cacti module and switch between them in the node definition? Just looking for some best practices. Thanx! Richard _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 2/7/08, Richard Hurt <rnhurt@gmail.com> wrote:> Hey all, > > I''m rather new to Puppet (but I really like what I see) and am trying to get > started on the right foot. I would like to define my modules in a generic > fashion so that if I have to change something in the future it doesn''t > break. For instance, I want to monitor all my servers, but instead of > defining a ''zabbix-agent'' module I''ve built a module named ''monitoring''. > That way if I want to change to Cacti or SNMP I can just change the > ''monitoring'' module and not have to touch anything else. Another example > would be switching between different databases (mysql, PostgreSQL. SQLite, > etc.) > > Does this seem like the proper thing to do? Or should I build out a > zabbix-agent module and a cacti module and switch between them in the node > definition? Just looking for some best practices.We do it like this: 1. Every component gets a module, some with multiple classes based on the way it could be deployed. For example, our ntp module has ntp::client, ntp::server and ntp::base. 2. A static class called "base" exists, and it''s sole job is to include all the modules that should exist on every system by default. (Setting up your resolver, apt/yum sources, nrpe, munin-node, etc.) 3. Static classes exist for each high level "type" of system. These often include "base", along with any specific modules they need (monitoring servers get nagios::server, etc.) 4. Nodes often include only the static class defined for it''s type from 3. So, you have something like: modules/foo manifests/site.pp manifests/site/base.pp manifests/site/type.pp This makes it really easy to deal with node definitions, since they are quite slim. Lots of ways to skin this cat -- just do something that makes sense for your infrastructure, make it a standard, and adhere to it. Consistency is king. :) Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.com
Richard Hurt schrieb:> Hey all, > > I''m rather new to Puppet (but I really like what I see) and am trying to get > started on the right foot. I would like to define my modules in a generic > fashion so that if I have to change something in the future it doesn''t > break. For instance, I want to monitor all my servers, but instead of > defining a ''zabbix-agent'' module I''ve built a module named ''monitoring''. > That way if I want to change to Cacti or SNMP I can just change the > ''monitoring'' module and not have to touch anything else. Another example > would be switching between different databases (mysql, PostgreSQL. SQLite, > etc.) > > Does this seem like the proper thing to do? Or should I build out a > zabbix-agent module and a cacti module and switch between them in the node > definition? Just looking for some best practices.Even if you believe changing you monitoring app occurs often, I would recommend a indirection there:: class zabbix::agent {} class monitoring { include zabbix::agent } This way you can develop a new_app::agent class on the side and then quickly switch over(or install it in parallel) by modifying the monitoring class. Regards, David
Further to what Adam has done, my setup is very similar in the sense that: a) I have a baseclass that sets up the basic stuff b) I have a "templates" system similar to the types Adam mention (not to be confused with templating using erb) where I have the various high level roles defined such as "workstation" inherits baseclass "laptop" inherits workstation "desktop" workstation "server" inherits baseclass "physical_server" inherits "server" "virtual_server" inherits "server" c) My nodes definition (with actual node/machine names) then inherits from the "templates" system and only special modules that cannot be generalised within the template is specified here. This means that when I get a new laptop (yes, I do need another one and no, I don''t have too many already and honey, it''s the same situation when you want to buy shoes!), it''s simply a matter of adding a "new_laptop_name inherits laptop" and it''s up and running. My next endavour will be to properly generate the nodes and templates definitions from the sqlite db I currently use to hold all data, but I need a little more than 24 hours a day I''m currently getting.... /peter On 07/02/2008, Adam Jacob <adam@hjksolutions.com> wrote:> On 2/7/08, Richard Hurt <rnhurt@gmail.com> wrote: > > Hey all, > > > > I''m rather new to Puppet (but I really like what I see) and am trying to get > > started on the right foot. I would like to define my modules in a generic > > fashion so that if I have to change something in the future it doesn''t > > break. For instance, I want to monitor all my servers, but instead of > > defining a ''zabbix-agent'' module I''ve built a module named ''monitoring''. > > That way if I want to change to Cacti or SNMP I can just change the > > ''monitoring'' module and not have to touch anything else. Another example > > would be switching between different databases (mysql, PostgreSQL. SQLite, > > etc.) > > > > Does this seem like the proper thing to do? Or should I build out a > > zabbix-agent module and a cacti module and switch between them in the node > > definition? Just looking for some best practices. > > We do it like this: > > 1. Every component gets a module, some with multiple classes based on > the way it could be deployed. For example, our ntp module has > ntp::client, ntp::server and ntp::base. > > 2. A static class called "base" exists, and it''s sole job is to > include all the modules that should exist on every system by default. > (Setting up your resolver, apt/yum sources, nrpe, munin-node, etc.) > > 3. Static classes exist for each high level "type" of system. These > often include "base", along with any specific modules they need > (monitoring servers get nagios::server, etc.) > > 4. Nodes often include only the static class defined for it''s type from 3. > > So, you have something like: > > modules/foo > manifests/site.pp > manifests/site/base.pp > manifests/site/type.pp > > This makes it really easy to deal with node definitions, since they > are quite slim. > > Lots of ways to skin this cat -- just do something that makes sense > for your infrastructure, make it a standard, and adhere to it. > Consistency is king. :) > > Adam > > -- > HJK Solutions - We Launch Startups - http://www.hjksolutions.com > Adam Jacob, Senior Partner > T: (206) 508-4759 E: adam@hjksolutions.com > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >-- /peter
On Feb 7, 2008 12:47 PM, Richard Hurt <rnhurt@gmail.com> wrote:> Does this seem like the proper thing to do? Or should I build out a > zabbix-agent module and a cacti module and switch between them in the node > definition? Just looking for some best practices.As has mentioned by others, your environment and needs are going to dictate what is best for you. To add to the "here''s what we do", well, here''s what we do. 1. Each individual component or service gets its own module - nagios, ntp, postfix, spamassassin, mysql, apache, etc. 2. The module has the various classes, similar to what Adam is doing; client and server ''modes''. 3. We do the node "templating" similar to the Puppet Best Practices wiki page, though each "template" is a class nodetype. So we have nodetype (for the basics on all systems), then nodetype::web, nodetype::dns, nodetype::build, etc and each subclass inherits nodetype. 4. Nodes include the nodetype most appropriate to their function. For example, web servers get nodetype::web. We''re pretty set on the software we are using for services. That is, we don''t plan to switch mysql to postgres or apache to mongrel. We''re still tinkering with cacti and munin and a couple others. I think David''s suggestion has merit (class monitoring {include zabbix}) and we''ll look at that option. However, one of our goals when we''ve got the configuration better sanitized from our site specific configuration is to publish the modules as recipes on the Puppet wiki, rather than generalize a module as you''re describing. This way we can share how we''re doing XYZ implementation. David''s configuration is very much complete and quite excellent, but it is also very complex and can be overwhelming to someone new to Puppet. -joshua