I have a system where we run the docker client on a different host than the docker daemon. More specifically, the client is run from a container with the host’s daemon, and has the daemon’s socket volume-mounted in.
So far, we’ve been curling the docker CLI directly into an alpine container for this, using the “https://get.docker.com/builds/Linux/x86_64/docker-$VERSION” link, but a teammate pointed out that the official docs do not recommend direct-download install for production systems (which this definitely is).
Some efforts have been made to use alpine’s package manager instead, but that’s a bit tricky since we want to be careful about which version of the CLI we use. It certainly can’t outpace the daemon, but also we want to pin back to allow users to have a more graceful migration when the CLI usage changes (like the 1.13 changes in subcommand layouts).
The issue here is that the alpine package manager makes this tricky, and we have to add special repos in order to get what we want, and it’s not clear to me which versions are guaranteed to be in which repos. For instance, the “default” alpine package manager right now only holds 1.12.6, I believe. Edge has 1.13, and to get other versions of docker we have to add other repos. If I am mistaken, please educate me!
Downloading the binaries from the well-known location is dead-simple and has worked so far, but some people just love package managers, and the message about “not for production” adds weight to that direction.
For installing the docker client CLI (doesn’t bother me if other things get installed too, I just don’t care about them) to arbitrary pinned versions, what is the recommended route? Is it best to continue direct download, or should we take the efforts to use the alpine package manager?