What is the docker way to deploy java projects in a docker container?
Do I copy the war into webapps:
FROM jetty:9.2.10
MAINTAINER Me "me@me.com"
ADD ./target/*.war /var/lib/jetty/webapps/ROOT.war
or do I take the exploded war file:
FROM jetty:9.2.10
MAINTAINER Me "me@me.com"
ADD ./target/app-0.1.0.BUILD-SNAPSHOT /var/lib/jetty/webapps/ROOT
Normally one would deploy the sealed war file if it was a normal container, but with docker, that means pushing a 10-20MB file every time you make a small change whereas adding the exploded war would only push the difference - the .class file that has changed.
Are there any downsides to deploying the exploded war instead of the war file?
You should actually ALWAYS deploy the exploded .war.
There are two elements of speed to think about here:
How fast is it to be able to push up your image to a container repository?
and
How quickly can a new instance of my container start serving requests? (important in an elastic-scaling environment)
The answer to both is the same: You are better off exploding the .war file when creating your container and NOT copying the .war file to it.
This has the following two very positive effects:
For those of us burdened by slow-upload connections, it's also a great idea to use a CI server or even a cloud-hosted VM to build and push your docker images to dockerhub or another container registry. That way you can take advantage of gigabit-scale upload speeds.
You can try this: Copy the war file into the container using COPY Copy the jetty runner jar into the container using COPY and then use the CMD to run it like this ["java -jar /path/to/jetty-runner.jar /path/to/app.war"]
http://www.eclipse.org/jetty/documentation/current/runner.html
NOTE: you will need to have java installed in the container.
I wonder how you're using your images. Adding a 20MB file while building an image should almost be instant. Mayb you somehow building images during deployment, like AWS does when you give it a Dockerfile.
In any case, I think it depends on how you're deploying. If you're moving the images around yourself, I don't see a lot of difference between ADDing a .war file and an exploded WAR directory. I would say do what's convenient for you. However, if you sometimes run the app from Docker and sometimes from a .war (which might miss some of the point of Docker), you might as well use the .war all the time.
If you're deploying to something like AWS Elastic Beanstalk (something that pulls the image from a repository), which wants either a Dockerfile or a Dockerrun.aws.json file, then separating the image from what you actually deploy makes some sense (or it has made sense to me so far). This allows the container to stay the same, while updating your app can be just copying a .jar/.war file to the right location (which also might miss part of the point of Docker ;).
What I've been doing is creating a base image on Docker Hub and then using the Dockerrun.aws.json file to map in my app. That way, AWS does not need to build my image, just pull it. That's much faster and less costly ($). But it does separate my app from the image, which might complicate deployment in some circumstances. However, because my image is so stable, I generally just bundle a .jar file, a Dockerrun.aws.json file and a shell script into a .zip and upload it to AWS. Pretty easy I think.
My Dockerfile is pretty simple and really all I need for my Spring Boot app:
You could do something similar and use the -v option, etc., to map volumes to your app, it's environment settings, etc. BTW, this image is available on Docker Hub.
This is how I do it:
On my todo list: separate out the WEB_INF/lib dir into its own container.