Dockerfile proposal #2

[VineetReynolds]

PLEASE DO NOT MERGE YET.

This needs to be reviewed.

This is different from PR #56 in that the build is not performed during docker build. Instead, docker build expects the ticket-monster.war file to be present in the root directory.

[pmuir]

Can you comment on why this approach is better?

[VineetReynolds]

Yes, I would have stated it in the mail separately, but since you asked, I might as well explain it here.

This is not an isolated discussion. It's occurred elsewhere: http://blog.giantswarm.io/getting-started-with-java-development-on-docker

By adding the already built WAR file to the docker build, instead of performing the Maven build inside the docker build, we're omitting some unnecessary files in the created layer. Elucidating some of the arguments in the linked article, the created layer is thus truly lightweight - we're adding a build artifact that we can wget or curl from Nexus to create a docker image that can be supplied to QA. Notably, the layer omits development-time artifacts like M2_HOME/repository, the compiled classes etc. since the Maven build is never fired during docker build. The docker build is also expected to be performed faster.

Also, by my understanding RUN mvn clean package without disabling docker cache is not a good idea. The contents of the container file system are not examined after the command is run, to determine whether a cache hit or miss has occurred. Only the command, i.e. mvn clean package is used for comparison. So, there is a chance that a cache hit would actually return older build artifacts; this incorrect behavior would of course be corrected by disabling the docker cache. I think we're now requiring devops to go one step further as a result.

[VineetReynolds]

Also, @goldmann has used a WAR file in this example: https://github.com/goldmann/wildfly-docker-deployment-example, although I can't say if he's done it for the same reasons.

[goldmann]

I agree with @VineetReynolds. Building the war as part of the build process makes the resulting image very heavy and bloated. A better approach is to include the pre-built war file (it can be built in a container, in a separate process). I like to have clean resulting images.

You can have a dedicated build container with mounted volumes saving the .m2 directory or other temporary files, so these are not pulled each time you execute a build.

[pmuir]

A dedicated build container sounds like a good idea, if we can automate all of it.