[chef] Re: Re: Re: ideas on deploying java applications

[Ran Tavory < >]

We build rpms using the mvn (on centos) and deploy the rpm. The rpm bundles the war file along with its required context file.

We don't do live deployments to tomcat so rpm install will (atomically) stop tomcat, copy the new war, cleanup work directories and start tomcat.

I'm just building it now, so it's not production yet, but if this helps I'll share a gist that demonstrates how to do it in mvn: http://gist.github.com/626051

On Tue, Oct 5, 2010 at 7:14 PM, Seth Chisamore < "> > wrote:

Sounds easy but building OS native packages isn't something most Java teams have the will or knowledge to do.

Seth

--
Opscode, Inc.
Seth Chisamore, Technical Evangelist
T: (404) 348-0505 E: " target="_blank">
Twitter, IRC, Github: schisamo

On Tue, Oct 5, 2010 at 12:46 PM, Sean OMeara < " target="_blank"> > wrote:

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 < " target="_blank"> > 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
>
>

--

/Ran