Alex Scoble
2013-Oct-15 21:21 UTC
[Puppet Users] Building another Puppet module for Splunk
Hi All, I''ve been working on yet another Puppet module to deploy and manage Splunk. Yep, I know that there are already many out there, but none do what I need and also work the way we work and also have control of the various conf files built in. It''s still a work in progress and isn''t fully documented, but it is working for systems running RHEL 6. I also plan to get it working and featurefull for Windows systems as well. I''m sure that Debian support wouldn''t be too hard either, but I''ll leave that to others to do if they so choose. This is also my first github project, coincidentally. You can find it here: https://github.com/ITBlogger/puppet-module-splunkmgr I''ve tried to follow Puppet''s style guide as much as possible and have used Puppet Labs'' own NTP module as a style reference as well. Sorry that the manifests related to managing the conf files (particularly the Splunk App for *nix one) aren''t all that easy to read, but the module is managing a lot of stanzas in the conf files. A few things you should know to use the module: It requires - This https://github.com/ITBlogger/puppet-splunk_conf/tree/patch-1 branch of cwooley''s splunk_conf module which uses augeas to manage the conf file stanzas. I''m waiting for him to merge in my pull request, but until then you''ll need to use my branch. This is because I changed his module to decouple stanza names from resource titles. This allows you to modify stanzas in two different conf files if needed. I originally did this so that Splunk and Splunk Universal Forwarder could be on the same system, but found this to be unnecessary in Splunk 6, but still liked the ability to name resource titles differently from stanza names. - The puppetlabs/firewall module - Puppet 3.0 or higher - All packages be served up by a private repo server - this could easily be changed to suit your needs, but this is how we work. We avoid putting installers and packages within Puppet modules and leverage Puppet''s package management and software installation providers It is written to take advantage of hiera, but use of hiera isn''t strictly necessary, although the documentation is written with hiera in mind using yaml as the backend. After using hiera for a few months, I can''t imagine a better way to manage nodes. As we are PE customers, we never used node classifier manifests and instead used the dashboard to manage nodes and hiera is way better than that. I also like it better than node classifier manifests as those put configuration data into your Puppet modules and I''m definitely a believer in keeping data and config management modules separate. Any input or constructive criticism you have would be much appreciated. Regards, Alex -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
Alex Scoble
2013-Oct-16 18:08 UTC
[Puppet Users] Re: Building another Puppet module for Splunk
By the way, I forgot to give thanks to the Puppet SE Team and to dhogland for their work on similar Splunk modules. I definitely integrated a lot of the work that they did into my module. Thanks, Alex On Tuesday, October 15, 2013 2:21:45 PM UTC-7, Alex Scoble wrote:> > Hi All, > > I''ve been working on yet another Puppet module to deploy and manage > Splunk. Yep, I know that there are already many out there, but none do what > I need and also work the way we work and also have control of the various > conf files built in. > > It''s still a work in progress and isn''t fully documented, but it is > working for systems running RHEL 6. I also plan to get it working and > featurefull for Windows systems as well. I''m sure that Debian support > wouldn''t be too hard either, but I''ll leave that to others to do if they so > choose. > > This is also my first github project, coincidentally. > > You can find it here: https://github.com/ITBlogger/puppet-module-splunkmgr > > I''ve tried to follow Puppet''s style guide as much as possible and have > used Puppet Labs'' own NTP module as a style reference as well. Sorry that > the manifests related to managing the conf files (particularly the Splunk > App for *nix one) aren''t all that easy to read, but the module is managing > a lot of stanzas in the conf files. > > > A few things you should know to use the module: > > It requires > > - This https://github.com/ITBlogger/puppet-splunk_conf/tree/patch-1 branch > of cwooley''s splunk_conf module which uses augeas to manage the conf file > stanzas. I''m waiting for him to merge in my pull request, but until then > you''ll need to use my branch. This is because I changed his module to > decouple stanza names from resource titles. This allows you to modify > stanzas in two different conf files if needed. I originally did this so > that Splunk and Splunk Universal Forwarder could be on the same system, but > found this to be unnecessary in Splunk 6, but still liked the ability to > name resource titles differently from stanza names. > - The puppetlabs/firewall module > - Puppet 3.0 or higher > - All packages be served up by a private repo server - this could > easily be changed to suit your needs, but this is how we work. We avoid > putting installers and packages within Puppet modules and leverage Puppet''s > package management and software installation providers > > It is written to take advantage of hiera, but use of hiera isn''t strictly > necessary, although the documentation is written with hiera in mind using > yaml as the backend. After using hiera for a few months, I can''t imagine a > better way to manage nodes. As we are PE customers, we never used node > classifier manifests and instead used the dashboard to manage nodes and > hiera is way better than that. I also like it better than node classifier > manifests as those put configuration data into your Puppet modules and I''m > definitely a believer in keeping data and config management modules > separate. > > Any input or constructive criticism you have would be much appreciated. > > Regards, > > Alex > > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.