When you dive in a complex project, even though you try to be as good as possible with documentation, sometime you just miss things.
I’ve had a good opportunity to realize this just recently while working on puppet. A common head scratcher in puppet is finding a way to keep system, technology and platform specifics separate. I will probably write at length on this particular subject a bit later, but to give a quick explanation, just consider this quick scenario: * You host web servers for the same vhosts in two different locations * You manage them with the same puppet instance * They need a unique configuration * Some details such as their name server change
Puppet allows you to get to the point where you can just write this:
class webserver {
include unix
include nginx
nginx::upstream { rails_app:
servers => ["127.0.0.1:8000", "127.0.0.1:8001"]
}
nginx::upstream_vhost { "www.example.com":
upstream => rails_app,
listen => 80
}
nginx::static_vhost { "static.example.com":
root => "/srv/www/static.example.com",
listen => 80
}
}This is great, generic and allows you to deploy configurations to many machines, so it’s a bit of a hassle to have to go through the trouble of going through case statements just for DNS.
This allows me do do clever local variables like these:
--- order: [ fqdn, operatingsystem ] values: ns_server: www01.remote.example.com: "10.1.1.1" default: "10.1.2.1"
And call them from classes like this:
class unix {
[...]
$ns_server = yamlvar(ns_server)
file { "/etc/resolv.conf":
owner => root,
group => $root_group,
mode => 0644,
content => template("unix/resolv.conf.erb")
}
[...]
}Well this is all fine and dandy until I came upon this: http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php . That’s right, @ripienaar already did the work and guess what ? http://www.devco.net/archives/2010/09/14/puppet_261_and_extlookup.php it’s already in puppet 2.6.1 !