On Apr 24, 8: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-pupp...
>
> 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
Parameterized classes are an attempt to solve the problem of feeding
data to classes. They provide an alternative to global variables in
that sense, and especially they provide a more reliable and
predictable alternative to Puppet's historic dynamic scoping
behavior. In some cases they can be used instead of class
inheritance, too, but that's not their main focus. Sadly, the current
implementation has enough design shortcomings that I recommend
avoiding it. With luck, those issues will be resolved in the next
major release, "Telly".
> (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.
Another alternative would be to do exactly as you would have done with
0.24 or 0.25. Global variables, node variables, and dynamic scoping
still work in 2.6, and even 2.7 (though 2.7 will issue warnings about
resolving variables via dynamic scoping). As far as I know, global
variables will be supported in Telly, too, though you will have to
reference them by their fully-qualified names.
> 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 ?
Despite my comments about going the old-school route, I do think Hiera
is probably the most appropriate solution at this point. I think you
will find that you can adapt your style pretty easily to use it
instead of global variables (or even simply to use it to set global
variables).
As I understand it, Hiera integration is targeted for Telly. That may
or may not actually carry the version number '2.8'.
John
--
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.
