Machine: Feature request: Make it possible to specify desired version of docker-engine when creating a machine

[codablock]

Currently, machine will always install the latest version of docker-engine when provisioning a new machine.

The problem is, that we currently have no control about which version get's installed in our test and live environments. Especially for our live environment, we need 100% control about which version gets installed.

In case we need to create a new node, we must ensure that it is compatible to all other nodes, especially when it comes to our planned integration of swarm and multi host networking. We can not simply upgrade all machines in case a new version of docker-engine gets released.

To solve this, I would suggest a new option for the create command, that allows to specify the desired version of docker-engine. To make this work, the installer script at https://get.docker.com/ may need to be modified so that it can somehow work with this option (e.g. with the help of an env variable).

Currently, the only workaround for this that I see is to use --engine-install-url with a modified installer script that forces an older version.

[sehz]

+1. This is critical issue. We need ability to lock down docker version in order to reproduce deployment.

[NodeGuy]

:+1:

[yonah-codefresh]

+1

[alambike]

:+1:

[micheletedeschi]

+1 the last version 1.10 doesn't work on amazon ec2!

[mlabieniec]

:+1: agree amazon ec2 no longer works

[eesprit]

+1, the absence of this functionnality makes docker-machine useless if wanting to deploy CS version of docker engine (or am I missing something?)

[minzhang28]

👍

[mrburrito]

+1. this is critical! I'd also be happy if machine used an existing docker installation on the target host without upgrading it. I'm using it to manage GitLab-CI builders and I've got a pre-configured image with docker 1.12.3 to reduce provisioning time (from ~5-6 minutes down to 3). There's a problem with 1.12.4 and I need to know how to lock that version.

This is critical!

[bastianb]

+1. Got same an issue with 1.12.4 and our CI pipeline, (using gitlab-runner and AWS provider makes build hanging - 1.12.3 works fine) we have no way to prevent upgrade of our docker-engine while starting up docker-machine, even if AMI is based on docker-engine 1.12.3, somehow it upgrades it.
Version management while starting machine is a must have IMO!
Can't wait for it

[mrburrito]

@bastianb I configured our AMI (CentOS) with excludes=docker-* in /etc/yum.conf. machine's provisioning can't update it and everything is working now. Definitely need this feature though; that workaround is hackish and ugly!

[nathanleclaire]

even if AMI is based on docker-engine 1.12.3, somehow it upgrades it.

FWIW, I'd consider this a bug, since provisioning is intended to check for a docker binary and not install if it's present.

I'd be curious to see docker-machine --debug output in a https://gist.github.com demonstrating this so I could take a look why that isn't working as intended.

There does seem to be https://packages.docker.com/1.12/install.sh which theoretically could be used for --engine-install-url but sadly I can't seem to indicate patch version using that URL convention. @thaJeztah do you know if this is possible?

Thanks all.

[mrburrito]

@nathanleclaire gist has two log files, one is the full debug output, including all the responses from AWS, the other has the AWS responses stripped out because I doubt they're relevant to this problem

https://gist.github.com/mrburrito/54e6ce5fb5bf17699d06bbacfae2d567

The base AMI is CentOS 7.3.1611 with Docker 1.12.3 already installed via yum.

Run from macOS 10.12.1, Docker 1.13.0-rc3-beta32 (14523), machine 0.9.0-rc2

[thaJeztah]

@mrburrito @bastianb have you opened an issue on the 1.12.4 issue in the https://github.com/docker/docker/issues issue tracker? If not, please do, and add more information as to what the issue is; we are working on an 1.12.5 release, because we found an issue with the OS X builds, so there will be another patch release very soon; would be good to know what's causing it and get it fixed before 1.12.5

[nathanleclaire]

Thanks @mrburrito -- so here's the issue I think: https://gist.github.com/mrburrito/54e6ce5fb5bf17699d06bbacfae2d567#file-machine-autoupgrade-full-txt-L3592-L3597 yum update on CentOS will actually update the package itself? Perhaps we're conflating this with apt-get update which will simply update the local package info? (at a quick Google, looks like it -- we want yum check-update).

This would make a fairly easy contribution if anyone wants to grab it ;) (make sure to ping me on the PR) -- otherwise I'll update it myself when I get some time.

[mrburrito]

@thaJeztah in regards to the GitLab-CI failure? honestly not sure what the exact problem is, only that the way GitLab runners call Docker is hanging.

Here's a discussion of the issue on GitLab's tracker. There's a sample script in this comment talking about how they can fix it.

https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/1962#note_20003535

[mrburrito]

@nathanleclaire yep. yum update updates the package instead of pulling the latest repo index

[thaJeztah]

@mrburrito could you open an issue in the https://github.com/docker/docker/issues issue tracker for it?

[mrburrito]

@nathanleclaire working on that patch, but it's a rabbit hole.

I have it working with yum check-update (which exits with code 100 if updates are available) and that seems to be ok. Here's the snag...

The comment above that call indicates it wants to ensure the OS is up to date for libdevicemapper. check-update won't actually execute the updates. Would it be better to run the update but exclude the docker-* packages?

[nathanleclaire]

The comment above that call indicates it wants to ensure the OS is up to date for libdevicemapper. check-update won't actually execute the updates. Would it be better to run the update but exclude the docker-* packages?

Yes, that seems about right. Docker Engine is mostly the only piece I expects users to be able to "pin" the version of by bringing their own, at least in the current model

[thaJeztah]

Would using the version lock package be a solution? https://access.redhat.com/solutions/98873

[mattwagl]

Any updates on this? It would be great to know, if somebody is working on this issue, or if it's on the roadmap? I think we really need the ability to lock engine versions if docker-machine is intended to be used in production.

[parrisvarney]

This feature would be particularly helpful for when issues like #4156 pop up.

[SvenDowideit]

This is already possible using the --engine-install-url and the scripts that we use in Rancher - see https://github.com/rancher/install-docker

[mattwagl]

Thanks @SvenDowideit for the tip and for providing these scripts!

[rubot]

Besides setting up own scripts, or using rancher scripts, following injection works for me:

docker-machine -D create --driver generic --generic-ip-address <ip> --generic-ssh-user root --engine-storage-driver overlay2 --engine-install-url 'https://get.docker.com|head -n-1|cat - <(echo -e "VERSION=17.03.2\nCHANNEL=stable\ndo_install")' <machine-name>