[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] docker binary
- From: Trevor Jay <tjay redhat com>
- To: Waldemar Augustyn <waldemar astyn com>
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] docker binary
- Date: Tue, 21 Jul 2015 01:16:12 +0000
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
--
Sent from my Amiga 500.
(Trevor Jay) Red Hat Product Security
gpg-key: https://ssl.montrose.is/chat/gpg-key
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]