Puppet users - Sep 2009 - How to structure configuration using Puppet and version control tools

Hello all.


We''re running Puppet to manage our linux-servers, but as of now we
don''t
really have a good setup for dealing with different environments
(production, qass, and so forth). The puppet manifests have been added to
Subversion. Our current apporach for staging for example a puppet class, we
create one class for each environment (appending "_prod",
"_qass", and so
forth to the class name), and make changes to the class contents
accordingly. I''m sure there are better ways of doing this kind of
thing.

So what we need is a structured way of staging puppet manifests, but in two
slightly different aspects:

   1. Manifests that are exactly equal in all environments (for example
   linux hardening)
   2. Manifests that have different parameters in the different environments
   (for example DNS setup)

I suspect using modules is the way to go. I''m not too experienced with
version control yet, but I''m sure this type of tool may get us far. But
before we start restructuring our puppet setup I''d like to hear from
other
puppet users on how they use Puppet and Subversion to manage manifest
staging and so forth.


Best regards,
Kenneth Holter

--~--~---------~--~----~------------~-------~--~----~
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 30 sep, 17:20, Kenneth Holter <kenneho....@gmail.com>
wrote:
> Hello all.
>
> We''re running Puppet to manage our linux-servers, but as of now we
don''t
> really have a good setup for dealing with different environments
> (production, qass, and so forth). The puppet manifests have been added to
> Subversion.
We also have our puppet conf versioned by SVN. And, well, ... we still
don''t have a proper system for various stages.

I thought of creating multiple branches in SVN (each branch being
configured as a puppet environment) and then, when changes seem OK,
merge (svn merge) them from the dev branch to the testing branch and
so forth.

But this of course requires some change in SVN usage: commit only
things that belong together (so that you can ''svn merge -c N
...'')
instead of committing any changes that are dangling in your working
copy.

Anyway, I would also like to hear how people do this in their setups.

Thanks,
Calimero
--~--~---------~--~----~------------~-------~--~----~
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, Oct 1, 2009 at 10:56 AM, Calimero <calimero.ng@evolutive.org>
wrote:
>
> On 30 sep, 17:20, Kenneth Holter <kenneho....@gmail.com> wrote:
>> Hello all.
>>
>> We''re running Puppet to manage our linux-servers, but as of
now we don''t
>> really have a good setup for dealing with different environments
>> (production, qass, and so forth). The puppet manifests have been added
to
>> Subversion.
>
> We also have our puppet conf versioned by SVN. And, well, ... we still
> don''t have a proper system for various stages.
>
> I thought of creating multiple branches in SVN (each branch being
> configured as a puppet environment) and then, when changes seem OK,
> merge (svn merge) them from the dev branch to the testing branch and
> so forth.
>
> But this of course requires some change in SVN usage: commit only
> things that belong together (so that you can ''svn merge -c N
...'')
> instead of committing any changes that are dangling in your working
> copy.
>
> Anyway, I would also like to hear how people do this in their setups.
>
We make use of a combination of SVN tags as well as environments. We
configure puppet with the following environments:

development, staging (a.k.a. QA), production, prod-clone, branch1 and branch2

The first 3 should be self-explanatory. Prod-clone is for emergency
fixes outside of our normal update schedule where we can point a
production machine to a branch with the prod puppet code + a fix.
Branch1 and Branch2 are similar to development for major refactoring.

We also have to deal with production control issues, so we created a
schedule for each environment - Development, Branch1 and Branch2 we
are free to update at any time, so systems in those environments are
generally new builds or test/dev systems. QA we update in our Tuesday
evening change window and Production and Prod-clone are updated in our
Thursday evening change window. Prod-clone, by its nature, can get
updated anytime after that, but only in an emergency situation to fix
a problem.

Development is our puppet SVN trunk. Branch1 and Branch2 *can* be SVN
branches, but aren''t always. More often than not they''re trunk
plus
some local changes that once we vet are merged back into trunk. At
some point before Tuesday, we copy trunk to a tag that becomes the
next QA->Production configuration.

We tried doing things the Right Way(TM) with SVN and having branches,
merging fixes from trunk to the branches, cutting tags from the
branches, etc. but it was just too much overhead for what we were
doing. We have found if we keep the release tags fairly frequent
(every week or two), it''s fairly easy to stay on top of things and not
break anything. We also comment our check-ins in a specific format so
we know what host(s) the change(s) affect and what the change is. We
use this to generate a summary page that is presented at our weekly
rollout meetings so that the other groups (DBAs, App Developers, etc.)
can see what changes are scheduled for the next change.

This lets us remain agile enough to respond to things, but also gives
some oversight to the process so we don''t go breaking anything in
production because we fat-fingered an SVN update or something similar.

Matt

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---