Puppet users - Aug 2013 - Puppet environments vs App environments

I''ve setup dynamic environments using git but I''m confused
about how
environments are actually supposed to be used. We''re a small ISP and
have
freeradius servers, VPN servers and web servers. I''ve been using 
environments to enable me as the sysadmin to build and test new 
manifests/modules before deploying them to our production servers. I have 
dedicated staging servers, one for each role (web,vpn,aaa), that are 
configured with the ''staging'' environment. My workflow
involves developing
locally (with a local puppetmaster), pushing commits on the staging branch 
and then QA on the staging servers and then merging the staging branch into 
production and pushing to deploy it.

However, our web development team have now requested their own 
staging/production environments for the web applications they are building. 
I then thought that perhaps these servers should be modelled using 
environments. Then I thought ''but these are application testing 
environments running in a production environment so they should have 
nothing to do with puppet environments''. I''ve managed to
confuse myself,
any help untangling my confusion would be greatly appreciated, thank you!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, August 19, 2013 1:59:46 AM UTC-5, JeremyCampbell
wrote:
>
> I''ve setup dynamic environments using git but I''m
confused about how
> environments are actually supposed to be used. We''re a small ISP
and have
> freeradius servers, VPN servers and web servers. I''ve been using 
> environments to enable me as the sysadmin to build and test new 
> manifests/modules before deploying them to our production servers. I have 
> dedicated staging servers, one for each role (web,vpn,aaa), that are 
> configured with the ''staging'' environment. My workflow
involves developing
> locally (with a local puppetmaster), pushing commits on the staging branch 
> and then QA on the staging servers and then merging the staging branch into
> production and pushing to deploy it.
>
> However, our web development team have now requested their own 
> staging/production environments for the web applications they are building.
> I then thought that perhaps these servers should be modelled using 
> environments. Then I thought ''but these are application testing 
> environments running in a production environment so they should have 
> nothing to do with puppet environments''. I''ve managed to
confuse myself,
> any help untangling my confusion would be greatly appreciated, thank you!
>

Do not read too much into the term "environment".  Puppet environments
are
a mechanism for partitioning your machines under management into groups 
that (may) rely on separate[*] manifests, modules, and data.  The feature 
is often used to implement configuration staging in the form you describe 
using now, but that is not their only possible use.  For example, it might 
in some cases make sense to use environments to separate machines assigned 
to different divisions of the company, different geographic locations, etc..

Importantly, if you want to slice your systems along two (or more) 
different dimensions then you need to flatten those into one.  That can 
certainly be done, but it doesn''t scale well.

[*] Note, too, that partitioning is incomplete: different environments 
served by the same master cannot provide different binary plugins (custom 
facts, functions, types, or providers).

Inasmuch as you are uncertain how to proceed, I would avoid creating new 
Puppet environments for now.  You should have a good idea of why you want 
separate environments before you create any.  It is likely that you can use 
ordinary Puppet facilities within each environment to manage the dev
team''s
different machine roles, if they even have different configuration 
requirements in the first place.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Hi John,

Thank you for a most well considered response given my level of 
understanding. I''d much appreciate an example of a system sliced along
2 or
more different dimensions that need to be flattened into one, this is the 
only part not clear to me.

Regards,
Jeremy.


On Monday, August 19, 2013 3:49:04 PM UTC+2, jcbollinger
wrote:
>
>
>
> On Monday, August 19, 2013 1:59:46 AM UTC-5, JeremyCampbell wrote:
>>
>> I''ve setup dynamic environments using git but I''m
confused about how
>> environments are actually supposed to be used. We''re a small
ISP and have
>> freeradius servers, VPN servers and web servers. I''ve been
using
>> environments to enable me as the sysadmin to build and test new 
>> manifests/modules before deploying them to our production servers. I
have
>> dedicated staging servers, one for each role (web,vpn,aaa), that are 
>> configured with the ''staging'' environment. My
workflow involves developing
>> locally (with a local puppetmaster), pushing commits on the staging
branch
>> and then QA on the staging servers and then merging the staging branch
into
>> production and pushing to deploy it.
>>
>> However, our web development team have now requested their own 
>> staging/production environments for the web applications they are
building.
>> I then thought that perhaps these servers should be modelled using 
>> environments. Then I thought ''but these are application
testing
>> environments running in a production environment so they should have 
>> nothing to do with puppet environments''. I''ve managed
to confuse myself,
>> any help untangling my confusion would be greatly appreciated, thank
you!
>>
>
>
> Do not read too much into the term "environment".  Puppet
environments are
> a mechanism for partitioning your machines under management into groups 
> that (may) rely on separate[*] manifests, modules, and data.  The feature 
> is often used to implement configuration staging in the form you describe 
> using now, but that is not their only possible use.  For example, it might 
> in some cases make sense to use environments to separate machines assigned 
> to different divisions of the company, different geographic locations,
etc..
>
> Importantly, if you want to slice your systems along two (or more) 
> different dimensions then you need to flatten those into one.  That can 
> certainly be done, but it doesn''t scale well.
>
> [*] Note, too, that partitioning is incomplete: different environments 
> served by the same master cannot provide different binary plugins (custom 
> facts, functions, types, or providers).
>
> Inasmuch as you are uncertain how to proceed, I would avoid creating new 
> Puppet environments for now.  You should have a good idea of why you want 
> separate environments before you create any.  It is likely that you can use
> ordinary Puppet facilities within each environment to manage the dev
team''s
> different machine roles, if they even have different configuration 
> requirements in the first place.
>
>
> John
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

On Monday, August 19, 2013 9:49:59 AM UTC-5, JeremyCampbell
wrote:
>
> Hi John,
>
> Thank you for a most well considered response given my level of 
> understanding. I''d much appreciate an example of a system sliced
along 2 or
> more different dimensions that need to be flattened into one, this is the 
> only part not clear to me.
>
>
It was not individual systems I was talking about slicing, but rather your 
overall pool of systems.  For example, suppose you want dev, staging, and 
production environments for your system configuration management.  Suppose 
you also want separate (sets of) environments for different departments 
(say R&D, sales, and accounting).  Flattening these means you end up with 
environments such as rnd_dev, rnd_staging, sales_production, etc. -- a 
total of nine environments.  Each system must be assigned to exactly one 
environment.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.