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
signature.asc
Description: PGP signature