Wed, 23 Sep 2009
Simplifying File Permissions in Puppet Manifests
I've been a user of Puppet for about three years now and
while on a recent dig in to some of my older classes it was a little
embarrassing to see lots of file types used like this:
file { "/srv/whi/maps":
ensure => present,
source => "puppet://$servername/whi/maps.conf"
owner => whi,
group => whi,
mode => 644
}
file { "/srv/whi/elocs":
ensure => present,
source => "puppet://$servername/whi/eloc.conf"
owner => whi,
group => whi,
mode => 644
}
Luckily as we get more experienced with a tool we can often go back and
improve on the first steps. By using an explicit File { settings
} inside a class you can assign a sensible set of defaults to all
the instances of the same type that lack overriding settings. So we can
shorten the previous example to -
File {
owner => whi,
group => whi,
mode => 644
}
file { "/srv/whi/maps":
ensure => present,
source => "puppet://$servername/whi/maps.conf"
}
file { "/srv/whi/elocs":
ensure => present,
source => "puppet://$servername/whi/eloc.conf"
}
While this isn't a huge win in raw characters typed (although in longer manifests they start to mount up) it does move all the common settings in to a single location (keeping us clear of DRY violations) and it leaves only the differences between file type definitions.
You can also apply those kind of settings (such as Exec { path =>
"path:list" } at the server level by including them in a top level
file and then overriding them as needed in each module. If you do this then
you need to be aware that any declared type that doesn't override it gets
the global setting, which can lead to the odd action from afar head
scratching.
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/09/23 22:16 | /tools/puppet | Permanent link to this entry | This entry and same date
Thu, 17 Sep 2009
Stand Alone Puppet
While Puppet can be used to manage large, complex
environments it's also a useful tool at the lower end of the spectrum.
Using just the puppet executable and a small inline class or
two you can write very useful manifests in only a handful of lines.
class build-host {
package { "build-essential": ensure => installed }
package { "subversion": ensure => installed }
file { "/home/dwilson/repos/":
ensure => directory,
owner => dwilson,
group => dwilson,
}
}
node default {
include build-host
}
To invoke the class you just run puppet -v build-host.pp.
It's also worth pointing out the node name of default. This saves you
manually changing the manifest whenever you move to another machine.
While it wouldn't be hard to replace the above example with a shell
script, by using puppet you can easily access the built-in abstractions
(which package manager to use, how should you add users) and remove a lot
of scaffolding code. And then when you're done you can promote the class to
your managed infrastructure.
I've used this to bootstrap provisioning servers (why should the provisioning host be the only machine that wasn't provisioned?), test small but annoying new classes on scratch servers and I'm currently working on integrating it with a small subversion backup testing project in my spare time at work (so very slowly).
Like this post? - Digg Me! | Add to del.icio.us! | reddit this!
Posted: 2009/09/17 21:33 | /tools/puppet | Permanent link to this entry | This entry and same date
Copyright © 2000-2010 Dean Wilson
