Open rhuss opened 9 years ago
Yet another idea:
After the image has been build one could compress it into a single layer by:
/bin/true
export
to get a tar-stream and ...create
with query option fromSrc=-
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 ;-)
Do you know https://github.com/jwilder/docker-squash ?
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)
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
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
@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 :)
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.
@jgangemi agreed, as soon as you use it as kind of a maven template it isn't usable standalone anymore.
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)
Don't worry, we will keep care of it :)
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.
Also the pull authentication for the FROM
image should be picked up properly as described in #358
@vberruchon see #330 on how to do Maven variable interpolation inside Dockerfile
s with resource filtering
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 ?
@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)
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.
Actual property replacement just has landed with #777 and is available from 0.21.0
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
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.
The following features should be added for a better experience when using Dockerfiles directly:
dockerFile
instead ofdockerFileDir
and the base directory is then set to the directory of this Dockerfile (ifdockerFileDir
is used, then the name of the dockerfile is supposed to beDockerfile
)ADD_ASSEMBLY
will add the proper ADD statements for the assmbly