Enhance direct Dockerfile support

[rhuss]

The following features should be added for a better experience when using Dockerfiles directly:

• It should be possible to support multiple Dockerfiles (as Docker 1.6 does). The idea is to use dockerFile instead of dockerFileDir and the base directory is then set to the directory of this Dockerfile (if dockerFileDir is used, then the name of the dockerfile is supposed to be Dockerfile)
• Allow variable substitution within Dockerfiles (as for other Maven resources).
• Allows special variables for:
  • ADD_ASSEMBLY will add the proper ADD statements for the assmbly
• Allow the configuration of the assembly directory used during the build. See also Add ability to configure the directory to which assembled files are written to.  #203
• Optional: Allow optimizations like compressing all subsequent RUN statements into a single RUN statement or so.

[rhuss]

Yet another idea:

After the image has been build one could compress it into a single layer by:

• Starting a container with /bin/true
• Using export to get a tar-stream and ...
• ... pipe that directly to create with query option fromSrc=-
• Remove the initial image
• Name the new image like the old image

Quite involved, but at the end we would have a nicely squeezed image which is especially useful if this image would be used as a based image.

Whether this is worth to implement is discussable, though ;-)

[twz123]

Do you know https://github.com/jwilder/docker-squash ?

[rhuss]

Yeah, but never tried it (and forgot about it again ;-). Thanks for the heads up.

Might be an even more advance algorithm one could look at. However, with the plugin we are restricted for things which can be done via the Docker API (don't know whether docker-squash can do it)

[vberruchon]

Hi Roland, I can see here in the envisaged features :
"Allow variable substitution within Dockerfiles (as for other Maven resources)."

I'd like to use variables defined in my pom.xml in my Dockerfile,
after reading the documentation I believed that the defined vars would have been available for the docker build process? Seems it's not true?
Would variable substitution be the only way to have this?
Or would you have an idea to allow this?.

For example I'd like to use the ${project.version} value during the build process based on my Dockerfile...

About features, possibility to have multiple "dockerFile" instead of an unique dockerFileDir directive would be great too.

Thank you
Vincent

[rhuss]

@vberruchon: yes, exactly this feature is planned, but not yet implemented. You should be able to use Maven properties in a Dockerfile. This will be in one of the next releases, shouldn't be to hard of course.

Maven property replacement works of course when you use the other, non-Dockerfile, mode. Maybe that's an option in the meantime ?

btw, I'm open for pull requests, so if you like to push this you can send a PR, too ;-). I can help you here, too.

/wrt multiple docke files: I also think that it is probably better to use a dockerFile directive instead of dockerFileDir, so multiple Dockerfiles would be possible. dockerFileDir is the implied by the directory location where the dockerfile sits. Also not a big thing :)

[jgangemi]

just as an aside, supporting this ties the Dockerfile directly to the maven build, which seems to slightly go against the original motives of supporting the external file.

not that i am against supporting this functionality, but i think we will need to put that in bold letters somewhere b/c i guarantee we'll start getting tickets of why things don't work.

[rhuss]

@jgangemi agreed, as soon as you use it as kind of a maven template it isn't usable standalone anymore.

[vberruchon]

Ok thank you
It's true about the fact it won't be anymore a "pure" Dockerfile, so perhaps it shouldn't be the same filename "Dockerfile" but something like "Dockerfile.template" or something like that...

(I'd like to contribute but really not much time at the moment. I will keep it in mind but you'll probably have released the next version before)

[rhuss]

Don't worry, we will keep care of it :)

[rhuss]

With respect to resource filtering we must be careful with the expression interpolation facility introduced by Docker 1.9 which uses ${ ... } for this, clashing with Maven's property syntax.

[rhuss]

Also the pull authentication for the FROM image should be picked up properly as described in #358

[alan-czajkowski]

@vberruchon see #330 on how to do Maven variable interpolation inside Dockerfiles with resource filtering

[rhuss]

Reiterating on the Dockerfile support in general, I have more and more the feeling that we should separate the two ways of building images more prominently (and not only by a low-level dockerFileDir which can be easily overlooked). Also because of potentially other ways to build images (see e.g. #414)

We could add extra configuration field <dockerfileBuild> on the same level as <build> for make the distinction clear. This could work also with a <type> field in the <build> section, but that would not easily be backwards compatible.

Thoughts on this ?

[alan-czajkowski]

@rhuss break backwards compatibility, i'd rather the plugin have a sane configuration layout than force it to be backwards compatible, especially since your versioning still implies beta (0.X)

[rhuss]

As mentioned in #543 it make sense to also add the <env> and <label> from the xml configuration over to the Dockerfile. We should either reserve a placeholder for that or determine heuristically the spot where to put the ENV and LABEL section.

[rhuss]

Actual property replacement just has landed with #777 and is available from 0.21.0

[adam42a]

If you could add some logging output as follows, it'd probably save a few people some time.

What threw me is that d-m-p creates a temporary directory but in dockerFileMode

target/<dockerOutputDirectory>/<imageName>/build

and it puts the Dockerfile in there, but it doesn't include the other files which are in <dockerFileDir>

The only way to be sure that they were included was to either run the image and see if it died, or attach to the image and look around, or open up the outputDirectory.tar with 7zip and check.

It would be cool if there was some logging at info level rather than just the following (I use verbose=true) :

[INFO] --- docker-maven-plugin:0.22.1:build (build-docker-image) @ tardis --- [INFO] Building tar: C:\dev\workspace\tardis\target\docker-build\xyz987\tmp\docker-build.tar [INFO] DOCKER> [xyz987/tardis:latest]: Created docker-build.tar in 170 milliseconds

[ankon]

and it puts the Dockerfile in there, but it doesn't include the other files which are in

From the documentation it ignores dockerFileDir when dockerFile is set (or better: it uses the parent of the docker file as dockerFileDir): https://github.com/fabric8io/docker-maven-plugin/blob/master/src/main/java/io/fabric8/maven/docker/config/BuildImageConfiguration.java#L30

The logging would be awesome indeed, I also spent a while just now with that issue.