On Sun, Dec 18, 2011 at 10:27 AM, Douglas Garstang
<doug.garstang@gmail.com>wrote:
> Question... for those that have multiple environments, dev, prod
> etc... do you share your modules directory, or does each environment
> have it''s own copy of the modules directory? Which one has worked
> better?
>
This largely depends on your organizational structure, version control
system access control, and desired use of environments, but the most
standard approach is to have completely separate module paths.
[dev]
modulepath = /var/lib/puppet/environments/dev/modules
[test]
modulepath = /var/lib/puppet/environments/test/modules
[prod]
modulepath = /var/lib/puppet/environments/prod/modules
If your deployment is one where you say have a Core OS team who are
responsible for the base distribution, and say application teams who are
responsible for their own modules (and are the primary consumers of their
own modules) you may end up with something like:
[dev]
modulepath
/var/lib/puppet/environments/dev/modules:/var/lib/puppet/apps/dev/modules
[test]
modulepath
/var/lib/puppet/environments/test/modules:/var/lib/puppet/apps/test/modules
[prod]
modulepath
/var/lib/puppet/environments/prod/modules:/var/lib/puppet/apps/prod/modules
This might be an appropriate choice if your app developers were responsible
for migrating their own changes in the "apps" modulepath from dev
-> test
-> prod and you didn''t want to have to set up the more complex VCS
ACLs to
micro-manage access within the "environments" modulepath.
You may have more rigorous testing requirements than this, where the app
developers need to be able to test their changes in apps-{dev,test,prod}
against all the combinations of envs-{dev,test,prod} due to business rules
around canarying changes, so you may end up with something like:
[dev]
modulepath
/var/lib/puppet/environments/dev/modules:/var/lib/puppet/apps/dev/modules
[dev_apps_test]
modulepath
/var/lib/puppet/environments/dev/modules:/var/lib/puppet/apps/test/modules
[dev_apps_prod]
modulepath
/var/lib/puppet/environments/dev/modules:/var/lib/puppet/apps/prod/modules
[test]
modulepath
/var/lib/puppet/environments/test/modules:/var/lib/puppet/apps/test/modules
[test_apps_dev]
modulepath
/var/lib/puppet/environments/test/modules:/var/lib/puppet/apps/dev/modules
[test_apps_prod]
modulepath
/var/lib/puppet/environments/test/modules:/var/lib/puppet/apps/prod/modules
[prod]
modulepath
/var/lib/puppet/environments/prod/modules:/var/lib/puppet/apps/prod/modules
[prod_apps_dev]
modulepath
/var/lib/puppet/environments/prod/modules:/var/lib/puppet/apps/dev/modules
[prod_apps_test]
modulepath
/var/lib/puppet/environments/prod/modules:/var/lib/puppet/apps/test/modules
An example of where this might make sense would be say if the Core OS team
enforced that a certain percentage of all servers needed to be running
"test" to canary changes, and so when the app team are testing their
changes, they need to test against the various combinations.
There is a balancing act here, much like there is with managing any large
software stack where different areas of the codebase are owned by different
groups.
Divide things up too broadly, and you''re not testing enough real world
combinations.
Divide things up too finely, and you''re weighing everyone down with too
much process to get their job done.
It''s easy to fall into the latter trap as the person responsible for a
Puppet deployment that other teams develop code for.
--
Nigel Kersten
Product Manager, Puppet Labs
--
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.