Docker-maven-plugin: make it easy to use a src/main/docker/Dockerfile with property replacement

[jstrachan]

So along with the ideas behind this for kubernetes yaml files https://github.com/fabric8io/fabric8/issues/5861 - I'm liking the idea of having a simple small default Dockerfile using maven properties; then its a natural place for folks to add any custom commands or environment variables using native docker syntax.

e.g. for an 'executable jar' style microservice we could use a standard Dockerfile like this:

FROM fabric8/java-jboss-openjdk8-jdk:1.0.10

ENV JAVA_APP_JAR ${project.build.finalName}.jar

ADD ${project.build.finalName}.jar /app

Or something fairly minimal like that. I'm kinda thinking that if folks choose to just write a small minimal Dockerfile (that mostly defines one or two env vars, defines the distro to add and the base image); they will usually want to use maven property filtering by default.

So having an option to enable & disable maven property filtering if specifying the assembly.dockerFileDir would be great. I wonder if we should just enable it by default?

Incidentally I wonder if we should also default the assembly.dockerFileDir value to something like src/main/docker if no other assembly is specified? Then if there is a suitable Dockerfile in src/main/docker then OOTB folks could run this on their project without changing their pom:

mvn io.fabric8:docker-maven-version:0.14.3:build

Or worst case folks could just create an empty maven plugin configuration:

      <plugin>
        <groupId>io.fabric8</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.14.2</version>
      </plugin>

so they can use

mvn docker:build

Am just thinking of the minimal pom.xml changing overhead of adding a simple Dockerfile referencing the projects build artefact; so there's as little to edit on a project as possible

[jstrachan]

Actually thinking about this; its maybe not such an awesome idea; as the mvn plugin would somehow need to know how to copy the files, typically from the target folder into the newly created docker folder that the Dockerfile would be copied to so that the ADD command would work; so its maybe better to just inline the assembly (or use the assemblyRef) approach afterall

[rhuss]

I'm just thinking forth and back how to variable substitutions (also documented on #205) because unfortunately Docker uses the same propery syntax for it _build args_ feature which is supported by our plugin, too.

I definitely support to be able to allow the smallest possible configuration. However, I don't think it could be empty because you need to specify at least the Docker image name somewhere (because thats not part of a Dockerfile). Hacking this into a Dockerfile could be possible (e.g. as a LABEL, comment, or whatever), but I wonder whether this doesn't confuse people more than it helps.

fwiw, we got just a cool PR #433 for adding a dedicated Docker packaging which makes binding to phases even easier. However this is more for the use case where you have a dedicated Maven module for creating your image and/or running the integration tests. I guess for this packaging we could also include the docker:source goal for creating the tars as first class artefact which then can use for e.g. OpenShift binary builds.

Next week when I finally continue on our Maven plugin ecosystem I will tackle this along with other Dockerfile enhancement described in #205

[rodlogic]

This is also on my radar. Having an external Dockerfile is much cleaner since one doesn't need to learn a new syntax for creating what ultimately is a Dockerfile. However, being able to replace properties is a must.

[adrianluisgonzalez]

+1

[svanscho]

👍

[Gengar003]

Regarding filtering/substitutions/build args, and the issue that Docker uses the ${same} format as ${maven} does - the maven-invoker-plugin (an official Maven plugin from Apache) has the same issue with the pom.xml files of child processes, and a solution: https://maven.apache.org/plugins/maven-invoker-plugin/examples/filtering.html

They use @property.name@ for properties in files that must be filtered by the child process and not by the parent Maven process; applying this formatting convention to the docker-maven-plugin would result in Dockerfiles that can use Docker's build args and Maven filtering with no conflicts, e.g.

Dockerfile

FROM ubuntu:@dockerfile.image.tag@

RUN apt-get install @dockerfile.package.list@

ARG NVM_VERSION=0.33.0
RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/${NVM_VERSION}/install.sh | bash

COPY @basedir@ /my/project/dir

pom.xml

...
<properties>
  <dockerfile.image.tag>latest</dockerfile.image.tag>
  <dockerfile.package.list>curl wget</dockerfile.package.list>
</properties>
...
<plugin>
 <configuration>
   <images>
     <image>
       <name>user/demo</name>
       <build>
         <dockerFileDir>${basedir}</dockerFileDir>
         <buildArgs>
           <NVM_VERSION>0.32.0</NVM_VERSION>
         </buildArgs>
         <dockerFileFiltering>true</dockerFileFiltering> <!-- made-up new property to enable filtering of @property.names@ in the Dockerfile -->
       </build>
     </image>
   </images>
 </configuration>
 ...
</plugin>

[gunnarmorling]

Hey @rhuss, is there any news on this one? Being able to use a native Dockerfile would be great addition to the plug-in.

[flenzi]

Is this going to be merged ?

[rhuss]

Added now property replacement support via #777 and available in 0.21.0.

Documentation is here : https://dmp.fabric8.io/#build-filtering

[oliveiragabriel07]

Hello,

I'm trying to use this feature but I can't get project properties filtered in my Dockerfile, only custom properties works. Is this the expected behavior?