Machine: the none driver case

[jeanlaurent]

The none driver was broken ( #2270 ) in the wake of the 0.5.0 release, and was used as handy driver for integration tests in the machine codebase ever since.

When we tried to clarify the situation by removing the none driver in favor of a test one ( #2437 ), they were legitimate questions on the status of the features the none driver provided before 5.0 release.

I'm not sure to know most of the cases where people are using the none driver.

Since the none driver is currently half-baked, to move forward with a solid answer for everyone I'd like to list of the use cases for this none driver :

• Register an existing docker host which can be accessed through ssh ( #2270 )
• Register an existing docker host through the localsocket ( #643 )
• Used as a handy, lightweight driver for integration testing ( #2437 )

What are the usages of the none driver besides the one listed here ?

[mikedougherty]

"Register an existing docker host which is not accessible through ssh"

Or perhaps collapse that and the first two bullet points to solely "Register an existing docker host".

[marcellodesales]

I agree with @mikedougherty... Or use the same "docker-engine" methods to remotely connect to remote enginers.

[metasim]

My use case is closer to what @mikedougherty is alluding to. My server has docker already configured with TLS remote access enabled (self-signed certs), and I'm using the none driver to effectively allow me to set the DOCKER_TLS_VERIFY, DOCKER_HOST, DOCKER_CERT_PATH, and DOCKER_MACHINE_NAME environment variables. In 0.4.1 I would run docker-machine create -d none ... to add a skeleton entry, and then I had a custom script to copy over all the certificate files, etc. in the appropriate spots under ~/.docker/....

I didn't fiddle with the ssh part really just because I didn't need it. The "ssh" use case _may_ address my needs, but only if it doesn't attempt to mess with the existing certs (providing command line options to specify them), or require ssh as root (i.e. allow remote user to have access via group membership).

As I write, I'm seeing two cases (maybe two drivers): ssh and tls/secure-remote (i.e. whatever's on port 2376).

[jeffellin]

Basically I'd like to see something similar to the generic driver where provisioning of the docker engine isn't performed.

[brianclaridge-wf]

Same as @jeffellin @metasim. I'm using packer to provision custom docker hosts, where certs are created in that provisioning and using vagrant ssh to copy them back into ~/.docker/machine/machines/my_custom_host/.

[marcellodesales]

2628 I got this fixed and some users would like to get this to the team's attention

[eugeneware]

Also as the new docker on OS X (currently in beta) uses the /var/run/docker.sock it would be good to have this either automatically listed by default (not having to add it), or being able to add it with a simple docker-machine create -d "none" --url=unix:///var/run/docker.sock localdocker command.

Currently (as documented in several other issues) this doesn't work well.

So, this use case is becoming more important.

[metasim]

Here's a script that's currently working for me:

https://github.com/docker/machine/issues/3344#issuecomment-212536797

[neg3ntropy]

There has to be a mode of operation for client convenience only, that does not try to manage the server. Please

[davidl2]

So I figured out how to use the "generic" driver for a case where no other instance of docker-machine was configured to manage an exiting host. I had to add several lines to /etc/sudoers to get it to work...

    Defaults        env_reset
    __user__  ALL=NOPASSWD:  /bin/hostname, /usr/bin/tee /etc/hostname, /usr/bin/apt-get, /usr/bin/docker, /bin/systemctl, /bin/ip
    __user__  ALL=NOPASSWD:  /usr/bin/tee /etc/docker/* , /usr/bin/tee  /etc/systemd/system/docker.service

For the "generic" driver, it seems like there should be a mode where it can check that the hostname is OK (instead of unconditionally resetting it), check that the package version is up-to-date by reading the version string (instead of unconditionally forcing a package-system update), and check that the daemon is properly configured to restart (instead of of unconditionally regenerating the docker.service file).

However, an alternate driver that uses SSH to a user that's a member of the "docker" group would make more sense for the way I expect to use Docker.

[Yajo]

I think they tried to push the docker-machine usage scenario towards just provisioning, but having the none driver behaving as a connect to existing socket without provisioning one, docker-machine could start to be used more widely as the tool to choose the server I want to connect.

A simple use case is a company where there are several docker servers that only the sysadmin installs, updates, etc., but all devops use the dockers inside them.

Maybe instead of calling it none it could be noprovision, or it could be a new command docker-machine add-existing.