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