Right now we're deploying via cap and something custom and part of the deployment is a config yaml file which puppet parses via facter in order to determine how to do the OS/middleware config. It works fairly well, but it feels kludgy to do it this way.
I've been wanting to cook something up like what it sounds like you want for a while, since I hate push-based models, and I hate using ssh as a transport. This means there is almost nothing that makes me happy around right now. The basic idea is to have a web application that handles deployment, maintains a version to revision database(one of our old systems uses SVN and does this via tags, which gets, well, bad after a few years), plus metadata surrounding the release, like configuration information. Deployment is done by issuing an mcollective command to do a pull/clone/checkout/update/whatever from a VCS onto the target server. Config information is transferred into puppet via the master over REST from the deployment server using the ruby DSL, with everything stored in one big hash. You would require that module and then use those variables in your own modules, with a sanity check to verify the code actually updated. On Friday, November 30, 2012 12:37:11 PM UTC-5, Schofield wrote: > > I am at the beginning of merging the traditional OS/Middleware update > process with application development release process. The goal is to be > able to test a complete versioned OS/Middleware/Application stack as it > moves through dev/test/qa/prod environments. The key here is that entire > stack is labeled under a single version. In other terms, the node and > everything on it is aligned under a single version. Right now the > OS/Middleware is managed by puppet. The application release process is > not. I'm hoping some folks would like to comment on the following > questions I am pondering. > > - How to best version puppet classes and control the classification of > nodes based on the version of the node? > - Are there ENC's that integrate with SVN/GIT that make this easy? > - Should application deployment be brought under the control of puppet? > - If so how do you easily do this without burdening applications > developers with having to learn something about or have access to puppet? > - Is there a puppet API that an existing application release processes > can leverage to trigger OS/Middleware updates when an application version > is updated? > > Looking forward to your comments. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/481nwg4Grc0J. 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.
