On Aug 3, 2010, at 6:30 AM, Kenneth Holter wrote:
> On other words, my clients area would look something like this:
> • "c_projectA", in which the classes "c_projectA::prod::webserver",
> "c_projectA::qass::webserver" and so forth would be implemented (and added to
> the node definition for the relevant servers)
> • "c_projectB", in which the classes "c_projectB::dev::database",
> "c_projectB::testing::database" and so forth would be implemented (and added
> to the node definition for the relevant servers)
> • etc
> I haven't thought out all the details yet, but I believe something like this
> would make having multiple server setups manageable. Any thoughts on this
> kind of setup?
>
This seems like it would lead to a confusing multiplicity of manifests.
Unless (in your example) webservers are completely divergent and have nothing
in common between qass and prod environments, I'd put all the webserver code in
one class and use decision-making conditionals inside the class to change
aspects of the resources. That way when someone else comes along and wants to
modify webserver behaviour they have only one place to look instead of four or
five. You're starting out with an external node tool, so setting variables at
top-level scope for projects and environments will make this easy. I've ended
up with a common structure among the different modules: typically there's a
case statement at the top which sets class-scope variables based on the globals
everyone on the team knows about and uses, then the actual resources below
which use those class-scope vars inline. EG:
class infrastructure::sudoers {
case $env { # globally set by external node tool
dev,qa,perf: {
$sudoersfile = "sudoers.preprod"
}
prod: {
$sudoersfile = "sudoers.prod"
}
default: { # always make a safe default in case $env is unset
$sudoersfile = "sudoers.minimal"
}
}
file { "sudoers":
path => $operatingsystem ? {
solaris => "/usr/local/etc/sudoers",
default => "/etc/sudoers",
},
owner => "root",
group => 0,
mode => "0440",
source => "puppet:///external/sudo/$sudoersfile",
}
}
Does that make sense? Not sure if the use-case maps up exactly to yours but it
sounds close enough that this might work for you and end up being a lot
simpler.
- Eric Sorenson - N37 17.255 W121 55.738 - http://twitter.com/ahpook -
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
