Correct way to deploy WAR files in docker image

You should actually ALWAYS deploy the exploded .war.

There are two elements of speed to think about here:

1. How fast is it to be able to push up your image to a container repository?

   and

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

1. It makes the differences between container versions much smaller, and so your upload time is less.
2. It means that, when dynamically scaling to meet application demand, your new container instances don't have to unzip your .war file before they can start responding to requests.

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.

This is how I do it:

FROM tomcat:8.0MAINTAINER David Ford <dford@smart-soft.com>ENV DB_HOST mySqlServerENV DB_USER joeBlowENV DB_PASSWORD bla bla blaEXPOSE 8080RUN rm -fr /usr/local/tomcat/webapps/ROOTCOPY target/webapp /usr/local/tomcat/webapps/ROOT

On my todo list: separate out the WEB_INF/lib dir into its own 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:

FROM java:8VOLUME /tmpVOLUME /appEXPOSE 8080ENTRYPOINT ["sh","/app/app.sh"]

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.