I wanted to post sooner ... oh well... This is resonably complicated and
easier understood on the whiteboard in my office :)
Our build processes uses 3 environments, noop setting, SVN, inventory fakedb
(csv file), and custom reports
*ENVs*
1. *dev* - separate server, you can do whatever you want here, puppet can
rebuild this server in case you go to far :)
2. *test* environment - low impact machines - a place to apply changes to
a large group of machines without getting fired if something goes wrong
(although developers might yell at you)
3. *prod - *high impact machines - only when you are absolutely sure ....
*SVN:*
3 separately visioned directories
- *conf *- manifests + site configuration file
- *dev* - services and modules
- *global* - everything not supported by environments (tools=[external
node classifier, custom reports, build process code], plugins)
*INVENTORY* - defines node attributes for external_node_classifier (and
provisioning process)
*environment column - *the external_node_classifier will send a node to
this new environment if he is not currently there.
*Build Process:
*1. identify changes
2. move test agents to dev puppet server (via inventory fake db)
*DEV ENV:*
3. Iterative development
4. test
5. create a release
*TEST ENV:
*6. checkout latest test release (automatically forces everything into
SAFE MODE, noop=true)
7. activate environment (turn safe mode = false)
8. create production release
*PROD ENV:
** *6. checkout latest prod release (automatically forces everything into
SAFE MODE, noop=true)
7. activate environment (turn safe mode = false)*
*
*Reporting:*
create new reports dir ENV/RELEASE/SAFE_MODE/
for each report type (ENV/RELEASE/SAFE_MODE/) - one report per host
if the report already exists, then the puppetd run does not coincide
with a new release and emails should be sent if anything changes.
*Limitations:
*- puppet servers manage part of the process by changing the puppet.conf
file
- environments do not support plugins, external_node_classifiers, etc..
- noop can only be set on the client side(not per environment)
*
MIsc:
*there are some other minor points not mentioned.
- svn commit hooks do things like verify code and notify admins when
releases are created
- conf and dev repos are separate so that users can make conf changes on
the test environment (skipping the dev steps in the process) and so that
conf changes can be triggered by scripts (EX: rootpwchange script), and
maybe eventually a web interface.
- when relevent, puppet server checks for the hosts in its environment
(inventory file) and broadcasts a puppetrun call.
- other...
*Phase 2:*
1. Tickets are created in some kind of a ticketing system
2. Code releases reference tickets
3. system associates all infrastructure changes(from reports) - with the
corresponding build IDs. Probably by autogenerating tiki pages in the build
management system (trac or whatever)
For any change in the infrastructure, you can see the ticket, the source
changes and the resulting changes in the infrastructure. Then the
infrastrucutre change process becomes a well understood and auditable
process.
enjoy!
Dan
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
