Best strategy for generating multiple images using the Docker plugin

[Vincent Massol]

Hi guys,

Thanks for the wonderful docker maven plugin: https://dmp.fabric8.io :)

I'm trying to modify our XWiki build to use it. We generate several images for XWiki, for example: mysql+tomcat, postgresql+tomcat

I'm wondering whether the canonical structure should be:

* 1) 2 maven modules, one for each image. In this case how can I share the same Dockerfile (with some properties to be filtered inside)?

* 2) A single maven module with 2 <image>. In this case how can I define different maven properties for each image so the Dockerfile can be resolved with the proper values for each image?

I've read https://dmp.fabric8.io/#docker:build but I wasn't able to figure out how to pass different properties for each image (for solution 2)).

Thanks a lot

-Vincent

[Roland Huss]

Hi Vincent,

thanks for using d-m-p ;-)

I think, for your use case it's properly the best to use different Maven profiles with varying plugin configurations to achieve different variations for the same Dockerfile. The drawback is, that you would have to call Maven multiple times with each profile enable for creating the images.

As an alternative, you can use a multi-module setup and point to the same dockerFileDir in each module (e.g. by using `${project.basedir}/../shared-docker-dir/` or so). Then you can re-use the same file and fill it with different parameters. That way you can create all images with a single Maven run.

'hope this helps ...

... roland

--
You received this message because you are subscribed to the Google Groups "fabric8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fabric8+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

... roland

[Vincent Massol]

Hi Roland,

Thanks for the reply.

I think, for your use case it's properly the best to use different Maven profiles with varying plugin configurations to achieve different variations for the same Dockerfile. The drawback is, that you would have to call Maven multiple times with each profile enable for creating the images.

I was fearing you'd say this ;) As you guessed, I didn't want to use profiles since this would mean running several times maven and I need to generate all the XWiki images in a single run.

As an alternative, you can use a multi-module setup and point to the same dockerFileDir in each module (e.g. by using `${project.basedir}/../shared-docker-dir/` or so). Then you can re-use the same file and fill it with different parameters. That way you can create all images with a single Maven run.

Ok thanks for this workaround. I don't like it too much since it goes against the maven philosophy.

I can think of 2 ideas to improve the plugin:

* 1) Allow specifying properties inside the <image> tag and those would be used when filtering. This seems the simplest by far.

* 2) Allow specifying a JAR artifact in the plugin configuration and this artifact would get expanded in the target dir. This would allow to have a maven module generating this artifact containing reusable files such as a Dockerfile + other files. This would be very similar to what is done in the maven remote resources plugin. 

Actually, thinking about it, this is what I'll do (option 2)) :) I'll use the remote resource plugin and bind it to a phase so that it's executed before the image build.

WDYT about option 1) ? Is that something you guys have already discussed about? Is it the philosophy of the plugin to generate several images or should it only generate one image (keeping the same philosophy as maven, which is that each module should generate only one artifact)?

Thanks

-Vincent

[Roland Huss]

Hi Vincent,

another possible solution which is similar to your proposed solution 1) could be to use `<buildArgs>` in an individual images configuration. This would use Docker build arg support and you can fill it individually for each image. See https://dmp.fabric8.io/#build-buildargs and https://dmp.fabric8.io/#build-configuration for details, but it boils down to:

<images>

   <image> 

      <name>image-a</name>

      <buildArgs>

         <paramA>firstValue</paramA>

       </buildArgs>

   </image>

   <image> 

      <name>image-b</name>

      <buildArgs>

         <paramA>secondValueValue</paramA>

       </buildArgs>

   </image>

</image>

And then in your Dockerfile you have an "ARG paramA" declaration, using it with "${paramA} within the Dockerfile.

Would this solve your use case? 

Happy to discuss this further, but please on a GitHub issue to better track it.

Happy new year .... ;-)

... roland

--

... roland

[Vincent Massol]

Thanks Roland for the idea. This seems like a good way to solve the need for the Dockerfile parametrization (using ARG commands in our dockerfile template). However it wouldn't solve the need for the other configuration files. For example we have a hibernate.cfg.xml file that should contain some variations depending on whether the image is for MySQL or PostgreSQL.

I could cheat a little and have that file generated when the container is first executed and thus set some ENV variable in the Dockerfile to indicate the defined DB.

However I think it's globally easier if I use the maven remote resources plugin. 

Well TBH I'm still hesitating since the maven remote resources plugin solution requires several maven modules (1 for the template files and 1 per image to generate) whereas your idea with buildArgs would require only a single maven module that would generate all the images at once.

I think I'll go with the multiple modules solution since that seems more mavenish and it allows to be able to build only a single image when testing for example.

I'll be working on this today and in the coming days so I'll report here about the progress :)

Thanks again and a happy new year 2018!

Thanks

-Vincent

[Vincent Massol]

Ah I forgot one point where I'm stuck ATM: https://groups.google.com/forum/#!topic/fabric8/v3pVx05SXUM

If you have any idea that would be great ;)

Thanks

-Vincent