[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] docker and docker-latest packages on CentOS Virt SIG




> On May 10, 2016, at 05:48, Daniel J Walsh <dwalsh redhat com> wrote:
> 
> On 05/09/2016 07:38 PM, Erik Swanson (eriswans) wrote:
>>> On May 9, 2016, at 07:54, Lokesh Mandvekar <lsm5 fedoraproject org> wrote:
>>> 
>>> - /usr/bin/docker is a script which execs /usr/bin/docker-current (v1.9) or
>>>  /usr/bin/docker-latest (v1.10) based on what $DOCKERBINARY is set to.
>> Too late (or wrong forum?) perhaps, but this split is very distressing to me as an end-user because it breaks the use case of bind-mounting the docker client binary and socket into a privileged container, a pattern which otherwise would work on basically every Docker-host OS out there regardless of Docker version.
>> 
>> —
>> Erik Swanson
>> 
>> 
> Yes we had not thought about this.  I guess you would need to volume mount docker and docker-current or docker-latest into the container.

(And whatever envionrment/configuration the /usr/bin/docker stub uses to decide which to execute, as well.)

Currently, I can tell people to bind-mount /usr/bin/docker and the socket, and it’ll work *everywhere*. With this change, I’ll have to document a ridiculous matrix of how to launch a docker-using privileged container, varying on the host OS and the version of the host OS (and what version of Docker they’ve elected to use).

The assumption of /usr/bin/docker being a self-contained(-ish) binary guaranteed to be compatible with the running daemon’s socket isn’t entirely uncommon: A quick google search for “-v /usr/bin/docker:” shows ~1670 results, all of which are going to be broken by the eccentric change of making /usr/bin/docker a stub (or a symlink).

(Is there a more appropriate venue for this concern/appeal?)

—
Erik Swanson



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]