Pete Emerson wrote:
> I take it you're referring to this:
>
> http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
>
> So on the puppetmaster server I'd need to generate a puppet.conf to
> create a [section] for each version I need to run. Since iterating over
> arrays doesn't appear to be allowed I guess I'd need to look into
> writing my own function, or simply externalize this to a script that I'd
> write.
Here's a definition I wrote to manage puppet.conf environments:
define puppet_environment()
{
$envdir = "$puppet_conf_prefix/$name"
augeas {
"puppet-environ--$name":
context => "/files/etc/puppet/puppet.conf/$name",
changes => [
"rm *",
"set manifestdir $envdir/manifests",
"set manifest $envdir/manifests/site.pp",
"set modulepath $envdir/modules",
],
require => Package["puppetmaster"],
notify => Service["puppetmaster"];
}
file {
$envdir:
ensure => directory;
}
}
Then use it like this:
$puppet_conf_prefix = "/etc/puppet/environments"
$puppet_environments = [ "production", "testing", "devel-1", "devel-2" ]
puppet_environment {
$puppet_environments: ;
}
The advantage of this over a template is that Puppet won't overwrite the
entire puppet.conf, just the environments in $puppet_environments.
I tend to use lots of "throw-away" environments for my development, that
may live for anywhere between an hour or several weeks, depending on how
long time the development of a certain feature takes. I use them somewhat
similar to how one uses topic branches in Git. When I develop a new
feature, I create an environment for it, do my editing there, and when
I feel ready to test it, I try to run it once (using puppetd --onetime)
on a node that normally runs the production environment. Often with
--noop as well until I think it actually does what I want. When I feel
more confident about my changes, I change that node to that environment
and run it that way for a few days, and when I think it's stable, I check
in my changes to the VCS, and check them out in the production environment,
switching back my test nodes to production as well. And then remove that
development environment.
Depending on how big or riskful a change I'm doing is, I may test my
changes on several different nodes, and/or I may shorten the time my
test node runs my development environment. (Most of the times they
are small enough that I can skip semi-permanent running entirely. I
also have a special development environment that I never erase, but
re-use again and again for very small changes, the kind that takes
just a few minutes; in fact, each sysadmin here has their own such
environment.)
I can have several of these temporary environments open in parallell,
if I'm developing and testing several different things.
With the above workflow, it would be quite disruptive to have Puppet
suddenly overwrite puppet.conf on the master with a version that doesn't
have my environment in it. And having to add my environment to my
Puppet manifests before being able to use it feels like too much
overhead. (In fact, I would like to not have to edit puppet.conf at
all to add or remove environments. Being able to configure a "wildcard"
environment in puppet.conf would be nice.)
/Thomas Bellman
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
