[colug-432] puppet: leveraging another module

[Scott Merrill]

> 
> 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.

>> (The role/profile/tech pattern of Puppet modules is one attempt to provide guidance around how and when modules can reach outside of their own boundaries.  If you’re not yet familiar with this pattern, do check it out.  A “myapp” profile might be justified to handle bridging both the “myapp” tech module and the sudo module.)
> 
> I'll have to look into this, thanks.
> 

It all started here: http://www.craigdunn.org/2012/05/239/

Additional useful links:
http://sysadvent.blogspot.com/2012/12/day-13-configuration-management-as-legos.html
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-1/
http://garylarizza.com/blog/2014/02/17/puppet-workflow-part-2/
http://puppetlunch.com/puppet/roles-and-profiles.html
https://puppetlabs.com/presentations/designing-puppet-rolesprofiles-pattern


>> 
>> Another option would be to make a design decision within your Puppet manifests that *all* sudo configurations will be handled via Hiera.  This appears to be well supported by the saz module.
>> 
>> https://github.com/saz/puppet-sudo#using-hiera
>> 
>> This makes it consistent within your modules that Hiera is the sole source of truth for sudo.  This can get a little more complicated, though, if you want specific rules enabled on some servers but not others.  It’s possible, depending on your Hiera hierarchy configuration, but takes a lot of careful planning.
> 
> I've been thinking about that.  I like the sole source of truth for sudo.  I was inadvertently working that direction, and the heira configuration got messy really quickly.  It also created that separation between the myapp module and the configuration that myapp requires to function properly.  I'd like to keep those things within a single logical container if possible.  In my heira config are a handful of "TODO: move this sudoers declaration to myappX module" to clean up the mess I made.
> 
> You're right about it being a design decision - something I need to ponder on a little more.

You’re often going to run into the “this thing belongs in module X, but it is defined in module Y” problem.  Roles and profiles help with this somewhat, but you need to be pretty diligent.

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.

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

Cheers,
Scott