Thanks John for yet another very useful reply, it is much appreciated.
I'm going to do some more reading on Hiera and look at reworking my
modules.
And thank you Ramin for some examples of Hiera in practice, looks very
interesting! Going to have a play around with it next week :)
Thanks!
On Apr 25, 7:01 pm, Ramin K <ramin-l...@badapple.net> wrote:
> On 4/24/2012 10:31 AM,AndyTaylorwrote:
>
>
>
>
>
>
>
>
>
> > Thank you very much for your detailed reply John. I hadn't looked at
> > Hiera before, it looks very interesting. On the point of it's not good
> > to include node/site data in manifests, it's kind of essential in my
> > eyes to the setup I am trying to implement.
>
> > At my company, one server may serve a site which has very different
> > requirements to another, so I really needed something that was very
> > flexible. To expand on the structure I outlined in my previous post:
> > each server has it's own node.pp file. If you need to change something
> > (e.g. MySQL settings, which will probably the most frequent one that
> > needs changing), you can simply edit that server's node manifest file.
> > The great advantage here is that each site's node manifest serves as
> > documentation of what changes have been made to it. It's also very
> > easy to read and understand for someone new to Puppet.
>
> > From some quick reading of the Hiera posts on the Puppet Labs blog, I
> > guess I could simply have a yaml file for each server with overrides
> > instead of doing it via the node manifest. However, I don't really see
> > the advantage of this approach, except for it would cut out some of
> > the clutter in my Puppet modules. The idea of a hierarchical set of
> > data being considered in line with Facter facts is very interesting
> > though, especially if I combined it with some custom facts of my own;
> > I will do some more reading on that.
>
> > With the class/definition point, I am wherever possible using classes,
> > as usually I'm dealing with the nature of a node (e.g. you are a
> > webserver, database server etc.) The only case I have used definitions
> > is for these configuration file overrides. So if I'm understanding
> > your comments on class/definition use properly, I think I'm sort of
> > taking the right approach to it...
>
> > The key concern for me at the moment is flexibility and scalability...
> > none of my stuff is live yet, and I want to make sure I'm using best
> > practices before I put it all in place. :)
>
> Mr Bollinger did his usual excellent job of thoroughly explaining the
> problem space in other parts of this thread. I'd simply add that using a
> richer data store, such as Hiera, can keep you from doing complicated
> gymnastics in your module code.
>
> I'm using a hiera.yaml file similar to the following with fqdn at the
> top and common at the bottom. I've added a role fact which is reading
> /etc/role on the client. You can use any Facter fact such as %{domain}
> or write your own. %{location} or %{datacenter} seems to be a common one
> for admins with multiple sites.
>
> :hierarchy:
> - %{fqdn}
> - %{role}_%{environment}
> - %{role}
> - %{environment}
> - common
>
> In my mysql::data class I add a variable and give it a default of 256M.
>
> $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size', '256M')
>
> I can then set the following to deal with the specifics of my environment.
> 512M in my prod environment, production.yaml
> 4G in role db, db.yaml
> 1.5G on role db in environment stage, db_stage.yaml
> 8G on server db01.main.sfo, db01.main.sfo.mydomain.com.yaml
>
> Going one step further you can use hiera_array to merge data. For
> example you might allow a set of servers to monitor all servers and then
> allow the local monitors as well. Assuming a location fact and the
> following data files
>
> common.yaml
> monitoring_hosts:
> - 'mon01.ord'
> - 'mon02.ord'
>
> lax.yaml
> monitoring_hosts:
> - 'mon01.lax'
>
> class someclass::data {
> $hosts = hiera_array('monitoring_hosts')
>
> }
>
> someclass::data::hosts = ['mon01.lax','mon01.ord','mon02.ord']
>
> Hopefully this should give you some ideas of how to use Hiera in your
> new system.
>
> Ramin
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
