Puppet users - Apr 2007 - Best practice, dev/test/staging/production environments

I like the Stanford Best Practices guide for puppet.  One thing I
didn''t
see it address was handling of separate environments, for example  Dev,
Test, Staging, Production.

My thoughts on this so far, are:

brainstorm #1)  Handle environment differences with metadata:

 node devProductName01 {
   $env = "dev"
   include ProductName-webserver
 }

 node testProductName01 {
    $env = "test"
    include ProductName-webserver
 }

 class ProductName-webserver inherits webserver {
    file { "/etc/httpd/conf/httpd.conf":
       content =>
template("/puppet/templates/ProductName/$env/httpd.conf.tmpl") }
 }

The template directory tree would look like:
  /puppet/templates/ProductName/{dev,test,staging,prod}/

Promotion of a new ''httpd.conf.tmpl'' would simply be copied
from dev ->
test -> staging -> prod

brainstorm #2)  Keep separate classes by environment, to allow them to
be modified independently.  Would require merging changes for
promotion.  ie:

 node devProductName01 {
    include dev-ProductName-webserver
 }

 class dev-ProductName-webserver inherits ProductName-webserver {
    file { "/etc/httpd/conf/httpd.conf":
      content =>
template("/puppet/templates/ProductName/httpd.conf.tmpl") }

    file { "/tmp/newfile": content =>
template("/puppet/templates/ProductName/dev/newfile.tmpl") }
 }

Promotion from dev -> test would involve merging the new element
(File[/tmp/newfile]) from the dev class to the test class (and so on up
through production).

brainstorm #3)  Separate instances of puppet including
manifests/files/templates/apps/etc.  Promotion involves merging all new
objects from one instace of puppet to another.

--

What are others doing in regards to managing multiple environments with
Puppet and the promotion of new elements between them?

----
Joe Miller
GoDaddy.com

On Apr 3, 2007, at 8:14 PM, jmiller@godaddy.com wrote:
> I like the Stanford Best Practices guide for puppet.  One thing I  
> didn''t
> see it address was handling of separate environments, for example   
> Dev,
> Test, Staging, Production.
>
> My thoughts on this so far, are:
>
> brainstorm #1)  Handle environment differences with metadata:
>
>  node devProductName01 {
>    $env = "dev"
>    include ProductName-webserver
>  }
This is the kind of thing I normally help people set up when I do  
consulting work for them, and it comes up at nearly every site.  At  
my last client, I helped them implement a custom function in the  
parser to determine their environment (since theirs is based on IP  
space).

It doesn''t really answer your question, but it gives an idea of how  
you might set the environment without specifying it separately for  
every node.
> The template directory tree would look like:
>   /puppet/templates/ProductName/{dev,test,staging,prod}/
>
> Promotion of a new ''httpd.conf.tmpl'' would simply be
copied from
> dev ->
> test -> staging -> prod
I think you''re going to find that won''t scale over time,
because
you''re going to end up with lots of duplication between the different  
environments.  This is a classic branch/merge scenario.
> brainstorm #2)  Keep separate classes by environment, to allow them to
> be modified independently.  Would require merging changes for
> promotion.  ie:
[...]
> Promotion from dev -> test would involve merging the new element
> (File[/tmp/newfile]) from the dev class to the test class (and so  
> on up
> through production).
>
> brainstorm #3)  Separate instances of puppet including
> manifests/files/templates/apps/etc.  Promotion involves merging all  
> new
> objects from one instace of puppet to another.
This is definitely what I recommend.
> What are others doing in regards to managing multiple environments  
> with
> Puppet and the promotion of new elements between them?
Note that there was a thread on this in January:

http://mail.madstop.com/pipermail/puppet-users/2007-January/000969.html

It doesn''t exactly answer your question, but it discusses it in great  
depth.

I''d like to formally support, within Puppet, the concept of a  
''release'', such that every client would be running at a given
release.  I don''t know how much support I''d provide for this  
internally -- i.e., whether you could run multiple releases in one  
puppetmaster server, or you''d need one server per release -- but I  
know for things like logging you''re going to want to know immediately  
which release a given host is in.  You''re probably going to react  
very differently if your test web server is down vs. your production.

Either way, though, I highly recommend the use of branches.  It''s  
been working for developers for ages, and I see nothing in what we''re  
doing to indicate we should be any different.

  --
  I had a linguistics professor who said that it''s man''s
ability to use
  language that makes him the dominant species on the planet.  That may
  be. But I think there''s one other thing that separates us from  
animals.
  We aren''t afraid of vacuum cleaners.      --Jeff Stilson
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

--On Tuesday, April 03, 2007 9:26 PM -0500 Luke Kanies <luke@madstop.com> 
wrote:
>> brainstorm #3)  Separate instances of puppet including
>> manifests/files/templates/apps/etc.  Promotion involves merging all
>> new
>> objects from one instace of puppet to another.
>
> This is definitely what I recommend.
That is certainly what we have done.

I was planning to look into namespaces as a possible solution.  Are 
namespaces documented yet?

On Apr 4, 2007, at 2:07 AM, Digant C Kasundra wrote:
>
> I was planning to look into namespaces as a possible solution.  Are
> namespaces documented yet?
I don''t think so.

  --
  The Internet, of course, is more than just a place to find pictures of
  people having sex with dogs.             -- Time Magazine, 3 July 1995
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On Apr 3, 2007, at 6:14 PM, jmiller@godaddy.com wrote:
> I like the Stanford Best Practices guide for puppet.  One thing I  
> didn''t
> see it address was handling of separate environments, for example   
> Dev,
> Test, Staging, Production.
I''m a bit of a stickler when it comes to separating environments.  We  
have multiple Production environments that I''d like to manage with a  
single Production puppetmaster, which is where I think the  
namespacing and modules are going to help a lot.  But in my opinion,  
Dev, QA and Staging should each be isolated networks.  At the least  
Dev/QA should be separate from Staging which definitely needs to be  
isolated from production because it should mimic it as closely as  
possible).  Machines are cheap in comparison to catastrophic changes  
(which puppet makes easy to do!).

-Blake

--On Thursday, April 05, 2007 12:02 PM -0700 Blake Barnett 
<shadoi@nanovoid.com> wrote:
>> I like the Stanford Best Practices guide for puppet.  One thing I
>> didn''t
>> see it address was handling of separate environments, for example
>> Dev,
>> Test, Staging, Production.
When speaking with members of my group here, I''m finding a need for 
something similar here.  I''m hoping namespaces might solve this problem
but
if not, I''m wondering if external node definitions might be able to 
indicate which manifest path the puppetmaster should use when responding to 
a node.


-- 
Digant C Kasundra <digant@stanford.edu>

On Apr 5, 2007, at 7:02 PM, Digant C Kasundra wrote:
>
> When speaking with members of my group here, I''m finding a need
for
> something similar here.  I''m hoping namespaces might solve this  
> problem but
> if not, I''m wondering if external node definitions might be able
to
> indicate which manifest path the puppetmaster should use when  
> responding to
> a node.
It''s fundamentally a merging problem, and I really think any solution  
that doesn''t rely on merging is going to be difficult.

I''ve tried to describe what I want to do:

https://reductivelabs.com/trac/puppet/wiki/PuppetEnvironment

Namespaces won''t work very well, because, for instance your  
''dev::sudo'' and ''prod::sudo'' classes will
tend to be the same but
your ''dev::webserver'' and ''prod::webserver''
classes (as an example;
not necessarily in your case) would probably be very similar but not  
exactly the same.  This is pretty easy to do with branches and  
merging, but pretty difficult to do with a bunch of text files in the  
same repository.

It''s all a question of the best way to deal with two aspects of the  
problem:  Significant but not complete overlap between different  
environments (i.e., almost all of your apps will be configured almost  
exactly the same in all environments, and the difficulty is managing  
the small differences), and how to migrate changes through the system  
at different rates (some changes need to happen in all environments  
immediately, and some can take months to get through).

  --
  True Terror is to wake up one morning and discover that your high
  school class is running the country.     -- Kurt Vonnegut
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com