I’ve used chef in a java shop before. We had hudson build the war files since it simply understands maven and can process pom files easily. The build artifacts are uploaded into Nexus. From there, you could also have hudson or jenkins update a data bag or a node attribute that specifies the version of the artifact you need chef-client to deploy. If you have chef-client running as a daemon, they’ll pick up the change on the next chef run and deploy your app. The recipe could be written in a way that uses the remote_file resource if it knew the nexus url to download the artifact from – the main difference on a new artifact is the version. You could also develop your own nexus LWRP to achieve this same result and be more flexible. If you don’t have chef-client running as a daemon, you’ll need some orchestration tool that kicks off chef-client on-demand. Again, hudson and jenkins could execute the knife ssh commands for you and achieve this, but you should consider the orchestration tool that best suits your needs.
The one downside to this approach: works well for one organization where you don’t have to manage the knife client keys and configuration on the orchestration side, but for larger implementations where you’re dealing with many chef organizations, you’ll need to figure out how to manage the knife client keys and configurations for each organization.
On 5/31/13 9:15 AM, "firstname.lastname@example.org:email@example.com" <firstname.lastname@example.org:email@example.com> wrote:
My company is looking at a way to automate Java deployments, and manage
environments. There are tools from the Java community that will automate
deployments, but they won’t do configuration management more broadly, and none
of them are terribly well established.
Our environments are relatively diverse, but to start with, we’d like to manage
a collection of apps running on Tomcat servers. We build with Maven and deploy
CI snapshots and releases to an internal Nexus repository. In an ideal world,
I’d like to be able to do two things:
When a new release occurs, tell Chef that test servers should receive that
release by incrementing the version number. Then have Chef download the
binaries from Nexus (which I’m sure it can do with its Maven resource), and
pass them to Tomcat. It seems to me this should be pretty easy.
On development servers, have Chef continuously check the snapshots on Nexus
and perform the same installation procedure when an update occurs. This also
seems like it’s probably achievable.
What worries me is that Chef doesn’t seem to be very widely used for Java
environments, and I’m wondering if there’s a reason. Am I going down the wrong
road, or does it seem like this is a good fit?
For background, Chef will also need to configure agents for Logstash and Nagios
(which I know it can do), and update an XML file that defines Logback logging
configuration for Tomcat.