Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile proposal #2 #57

Open
wants to merge 1 commit into
base: 3.x-develop
Choose a base branch
from

Conversation

VineetReynolds
Copy link

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
Copy link

pmuir commented Dec 19, 2014

Can you comment on why this approach is better?

@VineetReynolds
Copy link
Author

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
Copy link
Author

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
Copy link

goldmann commented Jan 6, 2015

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
Copy link

pmuir commented Jan 7, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants