make it easy to supply environment variables to be passed to docker:run or docker:run-build from a properties file

[jstrachan]

when running things inside kubernetes there's a bunch of environment variables that get generated to describe the IP / ports where all the services are.

I raised this issue in fabric8 to make it easier to run docker images as if they were really inside a kubernetes environment: fabric8io/fabric8#3619 (comment)

to be able to do that it'd be nice if the docker-maven-plugin could have a canonical file somewhere in target (e.g. target/docker/environment.properties or something) thats either manually configured or defined by default - that it looks for to set/override environment variables when running a docker container.

Then folks can generate the env vars using other maven plugin (e.g. we can have a "mvn fabric8:env goal to generate the kubernetes environment variables into that file) and can then easily pass them into the docker image.

[jgangemi]

you could probably accomplish this through the maven properties plugin and a build profile. the only drawback is you'd need to explicitly invoke the initialization goal along side any goal you call that is outside the normal life cycle.

this is similar to #52.

[jstrachan]

@jgangemi aha - great idea! :) I'll have an experiment with the maven properties plugin

[jstrachan]

though it would be cleaner to allow this to just be configured on the docker:run configuration though; then it won't affect the generation of images etc

[jgangemi]

configuring it to run as part of docker:run cannot be done w/o dev work. there was a discussion about this in #121.

it's possible it could be treated like the assembly plugin and invoked directly though, i need to do more investigation. it's unfortunate maven doesn't provide a way to at least run the initialization goal by default as part of other standalone goals.

[rhuss]

I think calling the initialization phase should be possible to introduce a custom lifecycle and call the initialisation phase because that's unique and independent from the packaging type (in contrast to the package phase which calls different plugins dependent on whether we are building a war, ear, jar, ...).

However, allowing to specify an external properties file with environments variables to set when running a container has its charm, too.

[iocanel]

So, I played a little bit around this. I managed to populate maven project properties (using an other plugin) and then have the docker-maven-plugin use the "props" configuration handler. The only problem I see is that when using the external configuration handler the approach is all or nothing, meaning that it generates a new build and run configs using the project properties, without taking into consideration any configuration provided directly on the plugin.

Would it make sense to use the existing configuration as a base and then use the external resolver for enriching / overriding the existing one?

[rhuss]

Yup, sounds good, but that's probably another story. I opened issue #136 for that.

Here I think it's ok to add a <envProperties> configuration, which allows to specify a properties file in the format:

CATALINA_OPTS=-Xmx32m
JOLOKIA_OFF=true

(hopefully the syntax restrictions for properties and env files are the same :). This should be possible to add quite easily.

[rhuss]

Added a configuration property envPropertyFile to the <run> section. This property file can now contain environment variables which take precedence over environment variables defined directly int the pom. It can be also given as a property if a property based configuration is used (e.g. with docker.envPropertyFile=....

I just pushed a fresh snapshot 0.11.3-SNAPSHOT so you could give it a try. I want to release 0.11.3 this weekend probably.

[iocanel]

Build the integration branch locally and tried it out. Works great !!!