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.