We're just beginning with Chef at my workplace. However, with regard to Java application deployments, we have an internal system built with ruby that we've used for several years to deploy and manage Java software across thousands of servers. Our developers just recently open sourced it a few weeks ago. In case you find it useful for ideas for Chef, you can find it here:StevenOn Oct 5, 2010, at 12:36 PM, Seth Chisamore wrote:Fellow Cooks,
I've been brainstorming on the best approach to incorporate Java-based web application deployments into the Chef ecosystem. The tricky thing we have to contend with, is the two step build/deploy process most Java applications go through. In most Java shops code is checked out from the SCM and then some sort of build framework like Maven compiles and packages the application down into a deployable artifact (usually a WAR file). This artifact is then deployed into the Java application server(s).
Right now the data-bag driven application cookbook uses a one-step approach...ie code is just checked out and sym-linked as "current". It would be nice to have a Java application that is deployed via this cookbook follow a similar pattern. The application cookbook can just pull the final deployable WAR file down from some arbitrary location...ie a valid URL whose reference lives in the application data bag.We still have to deal with the "build" portion though....or do we? Most Java shops that are using something as sophisticated as Chef for application deployments probably already have a continuous integration server that does "builds". That's awesome and we shouldn't change it! What we need to do is just hook into this workflow...ie have Chef be the final mile.
In order to solve this I propose creating a Maven plugin that would do the following after a successful build:
-push the completed WAR to a configurable distribution point (Artifactory, S3 etc.).
-grab a reference to the completed WAR (artifact download url)
-make an authorized PUT request to the Chef server and update the application data bag with the the WAR's new location/name. We could probably leverage the jclouds chef-client to do this (ie the CI server or build machine becomes a node).
The next time the chef-client runs on all application servers the new artifact should be pulled down and the deployment is complete. I think creating a Maven plugin is the best approach since most CI servers work well with Maven. A smaller shop that doesn't have a CI server could also just check the code out of SCM and perform a build via Maven.
Thoughts?Seth
--
Opscode, Inc.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: " target="_blank">
Twitter, IRC, Github: schisamo
Archive powered by MHonArc 2.6.16.