On Tue, Aug 3, 2010 at 7:45 PM, Eric Sorenson <[email protected]> wrote:
> 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]<puppet-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
Thanks for your detailed answer. It make perfect sense to implement thing
that way, by including different resources based on which environment the
client are defined in. But if the different projects had different
requirements for their servers, would you extend your example to check on
things like "if $evn == 'dev' and $project == 'projectA' then ....", or even
"if $fqdn == 'client1.example.com' then ..."?
In a real request I just got from on the the projects at work they wanted to
include a couple of classes just for one specific server, so I basically did
something like this:
-- code start --
class c_appserver::projectA {
include baseclass
include c_appserver
if ($fqdn == 'client1.dev.example.com') {
include some::class
}
}
-- code start --
If the "some::class" class were to be included on all development servers
for the project I'd be using "if ($env == 'dev') { ... }" instead.
Comments?
- Kenneth
--
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.
