3

I'm implementing a java based microservice with docker. Though I'm well known to Java and Maven, I'm not to so much to docker.

The service will have the job to get a file, parse it's content and write it to a mongodb. After that the service is not needed until next import.

The solution should be working with one file only per call and versioned when maven release is being performed.

The usage should be something like:

import.sh file-to-be-imported.xyz

Docker eventually is only needed for the runtime, not the development. Thus an execution script in which something like docker run params is called is enough in my opinion.

On maven release i'd like to do the following "specials" after tests have run:

  1. generate fat-jar in target
  2. generate updated import script with name of the jar (.jar) in target (updated on release) so import script
  3. update versions to new snapshot version (as default with maven release plugin)
  4. Update the container to the new version (i guess docker commit must be used for that somehow)
  5. Commit the updated container
  6. Store the updated container to an image (somehow done with docker save, i think)

I'd like to version the container with the jar it contains as changes to the implementation may have changes to the runtime environment or usage aswell.

Which maven plugin is suited for that use case? How do I have to alter my pom for that use case with given plugin.

How can I load the (formerly exported) latest versioned container afterwards from the script file?

Docker Hub is not an option for us. We'd solve deployment of the image with the recent script bundled out of the target-folder by jenkins.

As said before it's as simple as passing a filename to the jar's main method, which will handle everything else until the import is done. No app server involved or required.

roka
  • 55
  • 7
  • See: http://stackoverflow.com/questions/31696439/how-to-build-a-docker-container-for-a-java-app/31710204#31710204 – Mark O'Connor Oct 27 '15 at 21:18
  • Everyone's mileage may vary, but this might not be for everyone: "Docker eventually is only needed for the runtime, not the development". There is a lot of good use cases for some-or-a-lot of Docker in development. Think about the amazing consistency across environments that you get. – Sander Verhagen Oct 28 '15 at 07:06
  • This will actually solve the issue, i think. Thanks a lot Sander. ;-) – roka Oct 29 '15 at 11:15

0 Answers0