[colug-432] puppet: leveraging another module

[Rick Hornsby]

> On Jun 11, 2015, at 21:36, Scott Merrill <skippy at skippy.net> wrote:
> 
>> 
>> I don't necessarily mind that they depend on a forge-based module.  stdlib and concat are already dependencies required for some forge-based modules I'm using.  To that end, I've separated the forge-based modules to /etc/puppet/modules and the home-grown modules to /var/lib/puppet/modules.  The thinking is that the modules in /etc/puppet/modules should not be touched, while the ones in /var/lib/puppet/modules are expected to be changed, updated, etc.
> 
> That’s a very interesting approach to module management.  I like it, and I suspect it will work very well for you as you get more and more Puppet experience; but I think you’ll eventually hit a wall in terms of module management.
> 
> The tool we use is Librarian Puppet: http://librarian-puppet.com/   This is basically like Ruby’s “bundler” command for Puppet modules.  It allows you to define a single file that enumerates all of your Puppet modules.  You can reference Puppet Forge modules, GitHub.com modules, and even internal-only git URLs for your home-grown not-for-public-consumption stuff.
> 
> Librarian Puppet is not without its warts, but I think it’s the best solution available right now.
> 
> Another technology to look at is r10k: http://docs.puppetlabs.com/pe/latest/r10k.html  We’re not using this currently, but it’ s something that Puppet Labs is working on energetically.  It solves a different problem than Librarian Puppet, but it uses Librarian Puppet to do its work.

Librarian/r10k is not an area that I've explored yet, but I have seen references to r10k.  Will have to dig into that a bit.  Module management has been something in the back of my mind from the beginning.

With chef, we used knife commands to get the cookbooks onto the server -

	knife cookbook upload <myapp>

My experience so far has been literally copying module/manifest files onto the Puppet server.  That's a little scary when thinking about letting others loose to possibly drop an init.pp manifest for theirapp into the stdlib module accidentally.  While I'm using Git to VC my module development, I haven't gotten to the point of integrating it into Puppet, but it is on my list.  It sounds like Librarian and/or r10k might help with that.

> You also need to be open minded to the fact that the solution you choose today might not be the best solution in six months.  The great thing about Puppet (and other config management tools) is that they *should* facilitate refactoring cleanly.  You can re-jigger the Puppet implementation in various ways while ensuring that the on-server implementation doesn’t change at all.

Copy that.  I expect that as I learn and discover more I'll figure out better ways to do things, or find that a different approach makes more sense.

> I’ve been thinking about starting a Puppet users Meetup.  If there’s sufficient interest, please speak up and I’ll make it happen.

I cannot, unfortunately.  I don't live in Columbus anymore.  However - I would encourage others to consider it.

Here's my "statement of experience" to COLUG on this -

If you're the person who is writing shell scripts to make changes on your *NIX systems, please take a look at Puppet.  The resistance to move away from a nightmare of scattered directories of shell scripts of often unknown origin to a config management tool like Puppet is largely in your head.  True, in technical terms, Puppet is different and requires new/different skills than churning out shell scripts.

However, technical considerations are much less likely to be the biggest barrier than cultural/mindset barriers.  Moving away from...

* We don't need Puppet, we have all this documentation on manual processes
* I don't need Puppet, I can just edit /etc/sudoers on these 4 hosts directly
* I don't need Puppet, I can just run these commands this one time (which turns into 12 times, which turns into 6 months later what commands did that guy who left run?)
* I don't need Puppet, I have a library of bash/ksh/zsh scripts
* I don't need Puppet, I know Perl
* I don't want Puppet, I don't know Ruby
* I don't need Puppet, I can write and distribute the haproxy.conf file by hand much faster and easier (I've said this exact thing about Chef.  It came back to bite me later.)

...to a configuration management system like Puppet (or Chef, etc) is very much about allowing yourself (and convincing those around you) to be open to something better than the way we have always done it.


-rick