I'm using puppet to deploy new versions of our application to our server instances.
I do this by having a custom puppet node classifier that talks to a database that defines what version of an application is supposed to be on a particular node: parameters: application: "webapp", webapp_version: "0.5", webapp_config: "123", webapp_symlink: "0.4" My puppet recipe then makes sure that webapp version 0.5 is installed (via yum and rpms), makes sure the right versioned configuration files are in place, and makes sure that the "current" symlink points at 0.4 so that we can roll to a different version by flipping a symlink. The puppet recipe has a lot of "requires" to make sure that the upgrade of the application is graceful and does things in the right order. My upgrade then goes like this, all controlled via a custom web interface: 1) Insert a jobgroup for the upgrade and a job for each server instance into a db 2) A job processor then takes the first group of machines to upgrade, changes their webapp version to the new version, and runs puppet on them 3) Lather, rinse, repeat step 2 until complete (roll the application out to prevent downtime), although if there is a puppet failure, all pending jobs get cancelled. Given that there are so many ways to skin the same cat, I'm wondering how others are doing their application deployments using Puppet. Or, if you are using Puppet but do your app deployments via some other mechanism, how do you do it, and why aren't you using Puppet to do it? Pete -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
