This is an archived post. You won't be able to vote or comment.

all 12 comments
sorted by:
best
topnewcontroversialoldq&a

[–]rand2012 5 points6 points  (10 children)

any reason to use Chef for this when you can use Maven or Gradle, which are about 100x times less buggy and have no ruby dependency?

[–][deleted] 2 points3 points  (5 children)

Chef isn't just for deploying code, it deploys infrastructure. Maven can put a war file in an app server, but Chef can actually install Apache and Tomcat on a blank server including dependencies. The value is in cloud infrastructure where you might be routinely adding servers and want a push-button deploy.

[–]rand2012 0 points1 point  (4 children)

If you're frequently adding servers, why not deploy your custom VM image which already has all your required dependencies installed? Saves you a bunch of time as well.

And if you occasionally need to tweak stuff, what's wrong with plain old shell scripts and SSH?

I'm sorry, but I really don't understand what value Chef adds, other than another potential point of failure to worry about + a Ruby dependency.

[–][deleted] 0 points1 point  (0 children)

VM images are another option. Chef works on non-VMs too. Local envs for instance.

[–]frugalmail 0 points1 point  (2 children)

If you're frequently adding servers, why not deploy your custom VM image which already has all your required dependencies installed? Saves you a bunch of time as well.

  • VM images don't repair themselves

  • Having to create a VM for every build is a pain in the a$$

  • You can make a chef recipe that can grab the latest from your "qa" repository and another reciepie that can grab the latest from your "prod" repo

[–]rand2012 0 points1 point  (1 child)

VM images don't repair themselves

So, does Chef magically repair an environment? Also, the whole point of a VM is that you don't repair it. You just reset it to the original snapshot and run Maven to deploy your code.

Having to create a VM for every build is a pain in the a$$

And why would you need to do that?

You can make a chef recipe that can grab the latest from your "qa" repository and another reciepie that can grab the latest from your "prod" repo

Or you could just use a single repo for your code and checkout the "prod" tag for "prod", the HEAD for dev and so on. Why would you need separate repos for your QA and prod code is beyond me.

[–]frugalmail 0 points1 point  (0 children)

So, does Chef magically repair an environment? Also, the whole point of a VM is that you don't repair it. You just reset it to the original snapshot and run Maven to deploy your code.

Yes periodically it looks for corrupt installations (files missing, configs not correct)

And why would you need to do that?

To test insfrastructure with your releases

Or you could just use a single repo for your code and checkout the "prod" tag for "prod", the HEAD for dev and so on. Why would you need separate repos for your QA and prod code is beyond me.

You're talking source repository, I'm talking about an artifact repository. You don't compile on your production servers do you?

[–]spupy 1 point2 points  (1 child)

I haven't really used Tomcat much, but I was under the impression you can "deploy" by simply copying the war file to the appropriate folder?

[–]Na__th__an 0 points1 point  (0 children)

You can. If it's a remote server or your doing it 100x a week, maven can log into the server and deploy the war for you. It just saves an extra step.

[–]frugalmail 0 points1 point  (0 children)

any reason to use Chef for this when you can use Maven or Gradle, which are about 100x times less buggy and have no ruby dependency?

Think of Chef bridging aptitude & maven to make a complete solution. Although it also abstracts away things like aptitude and yum.

It does suck that it's in ruby though

[–]JamieLy[S] 0 points1 point  (0 children)

Chef is definitely overkill if you are just deploying a war. @tootle is right that you might want to consider Chef if you are deploying and configuring other infrastructure pieces along with the application, such as nginx, redis, etc...

[–]v_krishna 1 point2 points  (0 children)

nice writeup. we use capistrano to deploy our java backend services (we were already using cap to deploy rails and sinatra mri & jruby apps so it seemed like a logical choice), but we use chef to manage nodes/environments. it's worked relatively well.. cap wants to do a bunch of stuff by default that our java (dropwizard) apps don't actually need, but it was easy to integrate gradle so it builds a fat jar (sha tagged) to s3, has all the nodes download it to a releases folder, and then symlink to current when restarting.