Re: [atomic-devel] docker binary

[Waldemar Augustyn <waldemar astyn com>]

On 07/20/2015 06:16 PM, Trevor Jay wrote:
> On Sun, Jul 19, 2015 at 09:31:26PM -0700, Waldemar Augustyn wrote:
>> [...]
>> Host services such as docker, systemctl, and a few others find their way
>> to containers via bind mounts.  
>> [...]
>>
> They should be finding their way in as *endpoints* that native (to the container) clients talk to and not as "donor" binary blobs. Docker Inc. and other have tutorials and blogs that suggest approaches like:
>
>     -v /usr/bin/docker:/usr/bin/docker
>
> but this is a bad idea. There are too many risks to running donor binaries. Even if Atomic gave you the static linking you want, what about environmental or `/etc/` dependencies? No one from Fedora is going to do QA on running inside Ubuntu or vice versa.
>
> The reason Docker and systemd provide IPC-based access is so that you can:
>
>     -v /var/run/docker:/run/docker -v /var/run/docker.sock:/run/docker.sock
>
> And then install the native (to your container) docker client and use *that* to talk to the host through the IPC mechanism. The same is true of systemd and the dbus. 
>
> At worse, all you really need to ensure is that your container and host speak the same version of the IPC protocol (be it Docker or systemd). If you do docker-in-docker or containerized systemd, it doesn't matter what the host is up to at all.
>  
> _Trevor
>
Some very good points here. Thanks. For docker, that works. It would
seem, /etc/systemd  and /var/log/journal (and the host id) still need to
be bind mounted for a meaningful from-inside-the-container admin, right?