This was a long email! The answer to your problems is definitely something
like
Hiera. You make a common.yaml that has all your "defaults" and then you can
overwrite these based on any fact you like, when building the hierarchy.
You can
make a hierarchy like:
fqdn
environment
common.yaml
Then you could make
environment/staging.yaml
fqdn/server1.yaml
And override any of the "defaults" in common.yaml with more specific
values. You even
just set something like php_errors: true in staging.yaml and then in the
template have
some kind of <% if php_errors %> log with errors <% end %> etc kind of
code. Hiera
is definitely the solution to what you're trying to do, it lets you extract
all that magic
out of the manifests and keep them clean and then rely on looking for the
most specific
match when traversing down the hierarchy.
On Tue, Apr 24, 2012 at 9:19 AM, Calimero <calimero...@evolutive.org> wrote:
> Hi,
>
> I worked with puppet (< 0.25) back in 2008/2009. We were able to
> deploy 200 servers from scratch and manage them. It worked fine.
>
> I'm now with a new customer and I'm pushing Puppet (and I'm also back
> to puppet on a side project).
>
> We're considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts. I'm
> "upgrading myself" to Puppet 2.6's new concepts and features.
>
> Anyway consider this for the sake of argument:
>
> - node server1.hostingcompanyAlpha.com
> -- hosted on a dedicated server at provider Alpha
> -- production
>
> - node server2.hostingcompanyBeta.net
> -- hosted on a dedicated server at provider Beta
> -- production
>
> - node staging.myprivatenetwork.priv
> -- hosted on my customer's private network
> -- staging/QA
>
> - node dev.myprivatenetwork.priv
> -- hosted on my customer's private network
> -- development server
>
> Those four nodes must host the same elements:
> - Apache HTTPD with multiple VHosts
> - PHP
> - Extra software ...
>
>
> There are a few differences between nodes:
> - Servers don't have the same capabilities (CPU/Mem/bandwidth): we
> need to tweak Apache's MaxClients settings on a per-host basis
> - We need to tweak PHP : displaying errors on 'staging' and 'dev' but
> hiding them on server1/server2 (ie: setting 'display_errors' to 'on'
> or 'off' in php.ini)
> - On development and staging/testing servers we need to change some of
> the VHosts definitions: add extra serverAliases, etc ...
> - server1, server2 and staging/dev must use different DNS servers (/
> etc/resolv.conf) and RPM Mirrors (yumrepo{ })
>
> I've read the following blog post:
>
> http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
>
>
>
> Back with puppet < 0.25, we'd use "global variables" (not even node
> inheritance).
>
> manifest/sites.pp had something like:
>
> $envname = 'prod'
> $envstr = ''
> $dns_servers = [ '10.0.0.42', '10.10.1.42' ]
>
> import "classes/*.pp"
>
> node 'server1.hostingcompanyAlpha.com' {
>
> $httpd_maxclients = 300
> $yum_base = "http://mirrors.hostingcompanyAlpha.com/ftp.centos.org/
> "
> $dns_servers = [ '1.2.3.4', '1.2.4.4' ] # Hosting Co.'s resolvers
>
>
> include mywebserver
> }
>
> node 'server2.hostingcompanyBeta.net' {
>
> $httpd_maxclients = 200
> $yum_base = "http://repo.hostingcompanyBeta.net/centos/";
> $dns_servers = [ '8.8.8.8.8' , '8.8.4.4' ]
>
>
> include mywebserver
> }
>
> node 'staging.myprivatenetwork.priv' {
>
> $httpd_maxclients = 50
> $php_display_errors = 'on'
> $envname = 'staging'
> $envstr = 'stag'
>
> include mywebserver
> }
>
>
> node 'dev.myprivatenetwork.priv' {
>
> $httpd_maxclients = 20
> $php_error_reporting = "E_ALL"
> $php_display_errors = 'on'
> $envname = 'dev'
> $envstr = 'dev'
>
> include mywebserver
> }
>
> manifests/classes/mywebserver.pp would contain somethine like this:
>
> import "php"
> import "httpd"
>
> class mywebserver {
>
> include centos # which would in turn include modules 'yum' and
> 'resolv'
>
> include httpd
> include php
> include php::apc
>
> define httpd::vhost { 'mysite' :
> servername => "www.mysite.com",
> documentroot => "/var/www/html/mysite.com",
> }
> }
>
>
>
> modules/httpd/manifests/init.pp had:
>
> # defaults
> $httpd_maxclients = 150
> $httpd_...
>
> class httpd {
>
> file { "/etc/httpd/conf/httpd.conf" :
> content => template("httpd/httpd.conf.default.erb"); #
> which would
> then use $httpd_maxclients
> }
>
> }
>
> We also had a httpd::vhost($ip = "*", $port = 80, $servername,
> $documentroot, ...) define which would write VHosts files based on the
> following template:
>
> <VirtualHost <%= ip %>:<%= port%>>
> ServerName <%= servername %>
> <% if envstr != '' -%>
> ServerAlias <%= envstr %><%= servername %>
> <% end -%>
>
> <% if envname != 'prod' -%>
> php_admin_value display_errors on
> <% end -%>
>
> ...
> </VirtualHost>
>
>
> modules/yum/manifests/init.pp had:
>
> # defaults
> $yum_base = "http://myrepo.myprivatenetwork.priv/centos";
>
> class yum {
> yumrep { "os" :
> baseurl = "${yum_base}/RPMS.os",
> }
> }
>
>
> modules/php/manifests/init.pp:
>
> php_memory_limit = "32M"
> php_error_reporting = "..."
> php_display_errors = "off"
> and so on ... (huge list)
>
> with php.ini.erb :
>
> display_errors = <%= php_display_errors %>
> error_reporting = <%= php_error_reporting %>
> ...
>
>
> And so on ... If you haven't dozed off already, you get the idea. :-)
>
> That way we could provide safe/sane default settings which could
> easily be tweaked on a per-host or per-class basis.
>
> Parameters were quite easy to track and were in the code (which is
> stored in SVN). There might be some scoping problems from time to
> time, I have to admit. But once we had our "pattern", things would be
> smooth.
>
>
>
> I do now have trouble understanding how I should proceed with Puppet
> 2.6 (and 2.7 in the future), if I'm to avoid global variables.
>
> Parameterized class are seemingly not an option and, from what I
> understand and read, are more of an alternative to class inheritance
> (Nigel Kersten's comment on issue #13537): you don't need to inherit
> from a parent class if you want to tweak some of the ressources, you
> could just pass parameters to your class in the first place.
> Indeed I do not see how parameterized classes would help me get such
> flexibility. Or I'd have to "pass down" all the variables I need from
> my node/host down to every class. Cumbersome, at best.
> Parameterized class a good for "coarse grained" tuning, but not "per
> host" tweaks" on a variety of items.
>
>
> Next option is an External Node Classifier which I would have to
> develop and maintain to fetch/rewrite/generate/whatever variables I
> need. I could probably get what I want but I'd end up having an extra
> tool to maintain (and train people to use).
>
> A "middle of the road" option would be Hiera and create a hierarchy
> base on the '$hostname' fact (yaml backed for 'custom' values, and
> probably a puppet backed to fetch the defaults ? I see that you can
> also pass a default value to hiera()) . I assume that's the way to go.
>
> Well... I'm a bit puzzled by all this. :-)
>
> I'd like some input from you guys (and gals !).
>
> I'll try and install Hiera (nice, more stuff I need to package !)
> anyway. By the way what's the target version (2.8 ?) for Hiera's
> integration into Puppet ?
>
> Thanks !
> G.
>
> --
> 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.
>
>
--
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.
