[colug-432] puppet: leveraging another module

[Matthew Hyclak]

Count me in for a meetup.

We're doing some things with Satellite 6 and Puppet/hiera/r10k that may be
interesting. I've been spending some time rewriting modules into the
roles/profiles pattern as well.

Matt

On Thu, Jun 11, 2015 at 10:36 PM, 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.
>
> >> (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
>
>
>
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.colug.net/pipermail/colug-432/attachments/20150612/4e2a6a58/attachment-0001.html