Chow Loong Jin [2018-05-03 12:27 +0800]:
> On Wed, May 02, 2018 at 11:23:56AM +0200, Thomas Goirand wrote:
> > [...]
> > Frankly, I don't see the point in writing this kind of software. Sbuild
> > works super well with the overlay backend, and already has throw-able
> > chroots in tmpfs. Adding docker into this doesn't add any new feature,
> > and in some way, is less flexible than the already existing sbuild.
>
> Something that comes to mind is network isolation, which sbuild still
> doesn't seem to have proper support[1] for:
>
> [1] https://wiki.debian.org/sbuild#Disabling_network_access_for_dpkg-buildpackage
Not just network, but also process isolation and reducing privileges. schroot
would be way too "leaky" for a production CI system like ci.debian.net or
autopkgtest.ubuntu.com. The existing backend that compare much better to that
are -lxc and -lxd, and IMHO they are superior to docker. lxc and lxd are "full
OS" containers while docker is optimized for application containers and thus
needs some special treatment (like --privileged, which makes the whole thing
rather unsafe and often causes crashes if you try to start udev in the docker
container) to allow really booting a full OS. Usability wise, they are just as
simple as docker too, as linuxcontainers.org has a lot of pre-built OS images
for all kinds of OSes.
So I agree that there is very little point about adding a docker backend other
than "it's possible" (albeit inferior). As long as someone wants to maintain
it, there is little harm in including it.
Martin
