Puppet users - May 2010 - Managing producton & backup datacenter

Hi,

Just want to know how you use puppet to cover a scenario where you
have a production and backup datacenter. Both environments should be
similar but not identical (just a dumb example - your ntp setup is
probably different in each). I think it''s desirable to have just one
implementation of modules and classes shared among production and
backup so as not to make changes in 2 places which is error prone.

I''ve got this setup covered by having a different domain name in each
environment and use the ${domainname} fact to distinguish between
them.

So for ntp I just have:

file {"/etc/ntp.conf":
      ....
     source => puppet://${puppetmaster}/ntp.conf.${domainname}
}

I realize this setup is kinda primitive ;-) but right now it works
fine.
I just wonder how you guys have it set up - maybe there''s some more
efficient and elegant way.

-Regards

--linuxdatacenter.blogspot.com--

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On May 2, 2010, at 9:38 PM, linuxdatacenter wrote:
> Hi,
> 
> Just want to know how you use puppet to cover a scenario where you
> have a production and backup datacenter. Both environments should be
> similar but not identical (just a dumb example - your ntp setup is
> probably different in each). I think it''s desirable to have just
one
> implementation of modules and classes shared among production and
> backup so as not to make changes in 2 places which is error prone.
> 
> I''ve got this setup covered by having a different domain name in
each
> environment and use the ${domainname} fact to distinguish between
> them.
> 
> So for ntp I just have:
> 
> file {"/etc/ntp.conf":
>      ....
>     source => puppet://${puppetmaster}/ntp.conf.${domainname}
> }
> 
> I realize this setup is kinda primitive ;-) but right now it works
> fine.
> I just wonder how you guys have it set up - maybe there''s some
more
> efficient and elegant way.
> 
> -Regards
I actually just set the ntpd server to be a local server name and let DNS sort
it out using the search domain.
-Patrick

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Yeah - ntpd was just a dumb example - of course you can do it this
way ;-).

But for more sophisticated puppet setups - what are your ways to
determine which environment you are in. I know puppet can manage
different environments at one time (each with its own set of modules
and files - you configure puppetmaster for this), but this AFAIK
requires you to maintain multiple instances of your modules and
classes.

-Regards

On May 3, 9:26 am, Patrick <kc7...@gmail.com>
wrote:
> On May 2, 2010, at 9:38 PM, linuxdatacenter wrote:
>
>
>
> > Hi,
>
> > Just want to know how you use puppet to cover a scenario where you
> > have a production and backup datacenter. Both environments should be
> > similar but not identical (just a dumb example - your ntp setup is
> > probably different in each). I think it''s desirable to have
just one
> > implementation of modules and classes shared among production and
> > backup so as not to make changes in 2 places which is error prone.
>
> > I''ve got this setup covered by having a different domain name
in each
> > environment and use the ${domainname} fact to distinguish between
> > them.
>
> > So for ntp I just have:
>
> > file {"/etc/ntp.conf":
> >      ....
> >     source => puppet://${puppetmaster}/ntp.conf.${domainname}
> > }
>
> > I realize this setup is kinda primitive ;-) but right now it works
> > fine.
> > I just wonder how you guys have it set up - maybe there''s
some more
> > efficient and elegant way.
>
> > -Regards
>
> I actually just set the ntpd server to be a local server name and let DNS
sort it out using the search domain.
> -Patrick
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group
athttp://groups.google.com/group/puppet-users?hl=en.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

hello,

----- "linuxdatacenter" <linuxdatacenter@gmail.com> wrote:
> Yeah - ntpd was just a dumb example - of course you can do it this
> way ;-).
> 
> But for more sophisticated puppet setups - what are your ways to
> determine which environment you are in. I know puppet can manage
> different environments at one time (each with its own set of modules
> and files - you configure puppetmaster for this), but this AFAIK
> requires you to maintain multiple instances of your modules and
> classes.

I define a fact - perhaps $location - and use extlookup[1] to manage the data
based on those facts, this way you can have simple code and adding more
dc''s locations etc is trivial in future and requires no/very little
code change


[1] http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php
> 
> -Regards
> 
> On May 3, 9:26 am, Patrick <kc7...@gmail.com> wrote:
> > On May 2, 2010, at 9:38 PM, linuxdatacenter wrote:
> >
> >
> >
> > > Hi,
> >
> > > Just want to know how you use puppet to cover a scenario where
> you
> > > have a production and backup datacenter. Both environments should
> be
> > > similar but not identical (just a dumb example - your ntp setup
> is
> > > probably different in each). I think it''s desirable to
have just
> one
> > > implementation of modules and classes shared among production and
> > > backup so as not to make changes in 2 places which is error
> prone.
> >
> > > I''ve got this setup covered by having a different domain
name in
> each
> > > environment and use the ${domainname} fact to distinguish between
> > > them.
> >
> > > So for ntp I just have:
> >
> > > file {"/etc/ntp.conf":
> > >      ....
> > >     source => puppet://${puppetmaster}/ntp.conf.${domainname}
> > > }
> >
> > > I realize this setup is kinda primitive ;-) but right now it
> works
> > > fine.
> > > I just wonder how you guys have it set up - maybe
there''s some
> more
> > > efficient and elegant way.
> >
> > > -Regards
> >
> > I actually just set the ntpd server to be a local server name and
> let DNS sort it out using the search domain.
> > -Patrick
> >
> > --
> > 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+unsubscribe@googlegroups.com.
> > For more options, visit this group
> athttp://groups.google.com/group/puppet-users?hl=en.
> 
> -- 
> 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+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
-- 
R.I.Pienaar

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

linuxdatacenter <linuxdatacenter@gmail.com> writes:
> Yeah - ntpd was just a dumb example - of course you can do it this way ;-).
>
> But for more sophisticated puppet setups - what are your ways to determine
> which environment you are in.
I wrote a custom fact, location, that embeds all the logic in a tiny bit of
custom Ruby.  (In fact, it just grabs the hostname, domain, and IP address,
then uses a tiny bit of logic to select between them.)

Then, all my puppet code can use $location to work with things like
location-specific settings, and I have a single fact to update if the rules
ever get more complicated.

(In fact, the hostname is only used because the *did* get more complicated
 when users demanded a machine "location" become logical, since a
system at
 the second site should act like it was part of the first.  Oh, well. :)
> I know puppet can manage different environments at one time (each with its
> own set of modules and files - you configure puppetmaster for this), but
> this AFAIK requires you to maintain multiple instances of your modules and
> classes.
Yeah, this isn''t about "environments" in that sense, but
rather another fact
about the machine that you use to build your configuration.

        Daniel

-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
               ♽ made with 100 percent post-consumer electrons

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Sun, 2 May 2010, linuxdatacenter wrote:
> Hi,
> 
> Just want to know how you use puppet to cover a scenario where you
> have a production and backup datacenter. Both environments should be
> similar but not identical (just a dumb example - your ntp setup is
> probably different in each). I think it''s desirable to have just
one
> implementation of modules and classes shared among production and
> backup so as not to make changes in 2 places which is error prone.
We have a function that sets a variable based on the subdomain portion of 
the fqdn and use that variable to key datacenter specific variables. Our 
fqdn contains the datacenter - for example the NTP server in Seattle is 
ntp.sea.example.com. In site.pp we have a giant case statement like: 

  $datacenter = getdatacenter()

  case $datacenter { 
    sea: { 
      $ntpserver = ''ntp.sea.example.com''
      ...
    }
    sfo: 
      $ntpserver = ''ntp.sfo.example.com''
      ...
    }
  }

Then put $ntpserver in the ntpd.conf template. I''d be happy to share
the
function if anyone''s interested.

-Eric

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> > But for more sophisticated puppet setups - what are your ways to
determine
> > which environment you are in.
>
> I wrote a custom fact, location, that embeds all the logic in a tiny bit of
> custom Ruby.  (In fact, it just grabs the hostname, domain, and IP address,
> then uses a tiny bit of logic to select between them.)
Same sort of solution here. I made a location fact that maps primary
ipaddress subnet to a descriptive location string.

From there I went a different route than the extlookup() + case
method. I ended up using exported resources with ''tag =>
$location''
and ''<<| tag = $location |>>'' on the client side.
If a resource
doesn''t have a native Type I used the same technique with the concat
module.

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Thu, 06 May 2010 08:54:51 +0200, donavan <donavan@desinc.net> wrote:
>> > But for more sophisticated puppet setups - what are your ways to  
>> determine
>> > which environment you are in.
>>
>> I wrote a custom fact, location, that embeds all the logic in a tiny  
>> bit of
>> custom Ruby.  (In fact, it just grabs the hostname, domain, and IP  
>> address,
>> then uses a tiny bit of logic to select between them.)
>
> Same sort of solution here. I made a location fact that maps primary
> ipaddress subnet to a descriptive location string.
>
> From there I went a different route than the extlookup() + case
> method. I ended up using exported resources with ''tag =>
$location''
> and ''<<| tag = $location |>>'' on the client
side. If a resource
> doesn''t have a native Type I used the same technique with the
concat
> module.
Can you please explain this method a bit more, for the
unexperienced like me?

Showing the actual code would be great, if it''s possible.

-- 
Cosimo

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Can you please explain this method a bit more, for the
> unexperienced like me?
>
> Showing the actual code would be great, if it''s possible.
Sure, I assume you mean the exported resource part. Using
storeconfigs[1] it''s possible to exchange information between nodes.
Brice has some great explanations on his blog[2]. This example, using
concat[3] should give you an idea:

class dns::resolver {
 # create a file fragment pointing to this node
 @@concat::fragment{
  "resolv.conf_${fqdn}":
   target => "/etc/resolv.conf",
   order => 10,
   content => "nameserver\t$ipaddress\t# $fqdn\n",
   tag => $location;
 }
}

class dns::client {
 # concat teh fragments into the target file
 concat{"/etc/resolv.conf": }
 # insert a local fragment with search domain
 concat_fragment{
  "resolv.conf_search":
   target => "/etc/resolv.conf",
   order => 05,
   content => "search\tdomain.com\n"
 }
 # "realize" (retrieve) Concat_fragment resources provided by other
nodes in the same $location
 Concat_fragment <<| tag = $location |>>
}

I also tested using native types like Host and Augeas. Both worked
fine as far as I could see. For resources like /etc/resolv.conf you
may want to include a safe default entry in dns::client. That could
help protect against no available dns::resolver nodes, for example.

[1]
http://projects.reductivelabs.com/projects/puppet/wiki/Using_Stored_Configuration
[2] http://www.masterzen.fr/2009/08/08/storeconfigs-use-cases/
[3]
http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.