launch docker-machine to get environment

[chonton]

If docker environment variables are not set, use docker-machine to get what should be the environment variables.

• If no machine is available, create 'default' machine.
• otherwise, select a machine
  • If only one machine is available, use it.
  • If multiple machines available,
    • prefer to use 'default' machine.
    • If no 'default' machine, use the first running machine.
  • If selected machine is not running, start it.
• query selected machine for environment variables.

Since this is a time consuming process, cache results for other mojo executions in same Maven session

[jgangemi]

what happens if docker-machine isn't installed?

is there a way to disable this functionality and just have the same behavior as now? i don't think this should be the default behavior and instead the user should have to enable it explicitly.

[rhuss]

The idea is, if its not installed, everything is the same as now. I.e. it should be last in the fallback chain, so, if your DOCKER_HOST is set (or you use an explicite docker host via config), then nothing changes,

It's only that in the case you dont have a DOCKER_HOST set, and no docker-machine installed, that the error message might happen a bit later. something I could live with.

[jgangemi]

but even if i have docker-machine installed, i may not want to use this feature. it also looks like if default doesn't exist, it will try and use the first entry in the list returned from ls which may not be what ppl want either.

there should be a way to change the name of the docker-machine that is looked for and the a way to specify the behavior in the event that instance doesn't exist.

i also don't think we should create a new docker-machine instance if none are found by default. i think the user should be able to opt in/out of that behavior, w/ the default being out.

[rhuss]

Agree with having not too much magic. Would it be ok that by default we would us a docker-machine if it is installed and only one machine is created, then we use that as a fallback. From my feeling if people have docker-machine installed, they have this for a reason.

If more thane one machine is found then I would bail out, but also have an option e.g. like docker.machine=itest for specifically select this. Also, if this option is given an no such machine exists, I think its no harm to create this machine (if docker-machine is installed,a of course). And: If this option is given, this docker-machine should be used without any fallback.

Could we agree on this ?

[jgangemi]

well - here's the thing...if we are going to offer the ability to create a docker-machine instance, then i think we need a way to configure the options that are passed to it.

for instance, i do have docker-machine installed, but i also use vwmare instead of virtualbox and have a quick alias written that lets me create a new instance according to how i want.

if we want to keep things simple to start, we can just say that a machine instance is created w/ the defaults but i'd still like to see a way that someone can opt out of the plugin making any docker-machine calls and we can even keep that simple to start and just say it's all or nothing, instead of allowing ls but not create.

[chonton]

What happens if docker-machine isn't installed?

I haven't tested this scenario yet. Is it reasonable to expect that if you are using this plugin, you have docker-machine installed?

if we are going to offer the ability to create a docker-machine instance, then i think we need a way to configure the options that are passed to it.

Why I suggested this ability is for jenkins remote jobs. I can easily ensure that docker-machine is available on the jenkins slaves. I'd like it easy to make sure there is a basic machine available. If no machine is available, the default machine is built just as docker quickstart docs suggest.

If you want/need particular machine with esoteric options used, then make sure it's set up ahead of the build as the only active machine. Or, make sure that DOCKER_HOST is set. I am trying to follow the maven tradition of requiring minimal configuration to get going.

[jgangemi]

i don't really think the use of docker-machine and this plugin should be assumed. i think they can be independent of each other. i'm not saying no to this functionality, just playing devil's advocate for some other use cases.

as long as there is a way to opt out of using docker-machine completely, i'm fine with the general idea of this.

[chonton]

Agreed that this should be opt-in. I'm wondering what's the best way of indicating opt-in. Maybe specifying the machine name in a configuration element.

[rhuss]

@chonton @jgangemi I suggest to use configuration variable dockerMachine with a corresponding property docker.machine, similar to dockerHost and docker.host.

If this configuration variable is set, then docker-machine should be used with the given value as machine name. In that case there also should be no fallback but an error if docker-machine is not available because the user explicitly required docker-machine and would be surprised about any magic.

If the variable is not set, I would suggest to fallback to docker-machine, but only as last resort and only if only a single docker-machine is already present. To tune this, one could always set dockerHost (to avoid the fallback) or dockerMachine to select a different machine.

I agree with @jgangemi that we shouldn't create a docker machine automatically by default. However I could imagine to have either an extra property dockerMachineAutoCreate or some naming convention for the dockerMachine property (e.g. default[auto] will use docker machine default, but would create one when auto is given). That would probably have the advantage to no add yet another property (we already have so many :).

wdyt ?

[jgangemi]

i still think we should have a simple boolean that says useDockerMachine that controls opting out but i can live w/ this. 🍧

[seanf]

The TestContainers library (https://github.com/testcontainers/testcontainers-java) apparently calls docker-machine env automatically if it can't find docker via explicit configuration, so I was a little surprised when this plugin didn't do that for me.

The TestContainers logic is described here, but just for reference it's basically environment variables if present, then docker-machine (first machine): http://testcontainers.viewdocs.io/testcontainers-java/#user-content-docker-environment-discovery It would be nice to harmonise the variable names if practical, since I could see projects wanting to use both plugins.

I would vote for sensible defaults if no other config is available, rather than an error message. It's always nice if mvn install works without further configuration.

[seanf]

I just grepped for "machine" in the TestContainers code, and it looks like the current implementation:

• uses the machine named "default" if available
• otherwise uses the first machine returned by docker-machine ls

(But I'm sure the environment variables still trump that logic if present.)

TestContainers does not create a machine for you. Docker Machine Quickstart Terminal does that though, if you have run it.

Anyway, just another reference point.

[chonton]

Continued in #481