Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables
On 04/24/2012 09:19 AM, Calimero 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/
[snip ...]
I use facter variables to set dynamic parameters based on the host. For
example I created a module to modify sysctl entries:
node dbserver.example.com {
include sysctl
# Modify sysctl values
$shmall = inline_template("<%= (memorysizeinbytes.to_i +
swapsizeinbytes.to_i) / 4096 %>")
sysctl_entry { "kernel.shmall": value => $shmall, ensure => present }
}
--
*Les Ault* VCP, RHCE
Linux Systems Administrator, Office of Information Technology
Computing Systems Services
The University of Tennessee
135A3 Kingston Pike Building
2309 Kingston Pike
Knoxville, TN 37996
Phone: 865-974-1640
--
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.
Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables
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 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:
>
> :<%= port%>>
>ServerName <%= servername %>
> <% if envstr != '' -%>
>ServerAlias <%= envstr %><%= servername %>
> <% end -%>
>
> <% if envname != 'prod' -%>
>php_admin_value display_errors on
> <% end -%>
>
> ...
>
>
>
> modules/yum/manifests/init.pp
[Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables
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:
:<%= port%>>
ServerName <%= servername %>
<% if envstr != '' -%>
ServerAlias <%= envstr %><%= servername %>
<% end -%>
<% if envname != 'prod' -%>
php_admin_value display_errors on
<% end -%>
...
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 iss
