I run a small startup offering a SAAS application (cloud based, no local servers at all). We have always tried to "do things right" so that we can scale - and my view is (happy to be challenged) that our application stack should absolutely be managed just as any other part of the configuration. We package our software components using "system packages" (deb files on ubuntu in our case). There was a time when we created the debs manually, but our software build process does them automatically now using git-buildpackage. the Continuous Integration server gets the latest changes from source control, tests them and creates the debs. deb packages handle versions, so if we want we can specify that one part of the app depends on a particular version of another part. As far as possible though we try to release the application stack as a whole so we avoid untested combinations. (this is a key recommendation of "the" Continuous Delivery book by the thoughtworks guys).
The version numbers of the packages in the different environments is managed by puppet, using hiera. The contents of the config files are also managed by puppet (again using hiera). As far as I can tell this is the perfect scenario - I'm really interested to know what problem Noah is referring to/ trying to solve (we haven't found it yet). If we need more capacity, we build another prod app server or db server etc. The app layers support dynamic load balancing - e.g. app servers automatically register themselves with the web server pool when they start-up. The web-servers automatically register with the load balancer etc. Being open with you, we could probably manage without all of this (for now) - we haven't achieved the scale to need most of it yet. But having it like this means we spend much much less time worrying about environments and software releases and more time getting the software right for the users. I'd love to hear what problems we're heading for that this setup can't cope with, so we can change course if necessary. Regards, James. On Saturday, December 1, 2012 10:46:06 PM UTC, Nick Cammorato wrote: > > 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/-/szJxmTB0iyIJ. 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.
