[chef] Re: ideas on deploying java applications


Chronological Thread 
  • From: Sean OMeara < >
  • To:
  • Subject: [chef] Re: ideas on deploying java applications
  • Date: Tue, 5 Oct 2010 12:46:39 -0400
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mxJup6B1fzbYJm2pLlFYmB4hxLSkJxtoS+HK4iokUxlCK7S+DFnLA1ZttaN6bLpXM/ DHTi0HSiPd1rEOiH2BvbgAHqVOlUCaeXmOXw6l6sUrIXnoo73vH0ygW6j37ESAEjovX7 WS+EjOiixMht6YzyudNOxV4XWiIBaByivL9XY=

Build your software, make an OS native package (deb, rpm), chuck it
into your package repository and then the chef recipe beomes Super
Easy.

-s

On Tue, 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: 
> 
> Twitter, IRC, Github: schisamo
>
>



Archive powered by MHonArc 2.6.16.

§