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

["Mark J. Reed" < >]

We're looking at a similar issue, and so far we've found a couple
other options, each of which has its own scaling issues, but might be
appropriate in some cases.

1. Have the recipe check the code out and do a build.

This is more heavyweight than it needs to be, obviously, and
introduces build-time dependencies into the runtime deployment, but
it's viable if the app and/or the deployment is small enough.  It has
the advantage of keeping the support infrastructure simple.

But as long as your build server is able to talk to Chef to update the
WAR's new location/name, why not just do this instead:

2. Upload the WAR itself as a cookbook file.

This has the advantage that you don't introduce a new network access
dependency between your target nodes and your artifact repository (or
source code repository for option 1); if they can talk to the Chef
server, they can get the files.


> 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
>>
>
>



-- 
Mark J. Reed 
<
 >