
Docker 19.03: Rootless Mode (Experimental) - UberIsAnnoying
https://github.com/moby/moby/blob/master/docs/rootless.md
======
AdamGibbins
Or we could just ditch Docker for one of the alternatives, like Podman that
doesn't need root, nor a daemon.

~~~
paulddraper
Yep. I only half care about rootless. I definitely care about the daemon.

It sucks.

It flies in the face of traditional Linux process management where _child
processes are child processes_.

(Unless you want an init system, where you need a daemon. But docker is a
sucky init system.)

Docker breaks even the most basic things.

    
    
        $ time docker run some heavy computation
    

Oh wait, that doesn't work.

~~~
the8472
For the trivial case a child process would work. But ultimately docker _does_
try to be closer to an init system or maybe screen since you can detach/attach
to processes. Since reparenting to arbitrary processes is not possible in
linux it's also not possible to retain the parent-child relationship for
spawned containers.

If you want the fork-exec model then docker is indeed the wrong tool for the
job.

~~~
jchw
The thing is, I don't even really like Docker as an init daemon. I have my
gripes about Systemd but I see no downsides to not having a long-running
daemon for a container engine. Really, whether you need root or not isn't even
the most important issue; you can do sudo or suid or whatever with any
container engine; Docker just has it be an implicit, unintuitive behavior.

I used to use systemd+rkt for simple container setups when I didn't need all
of Kubernetes. Never noticed any downsides versus using Docker, but on the
flip side, I had far fewer issues with my containers not properly starting at
boot.

~~~
paulddraper
I read an article (can't find it now) that said from a previous project the
Docker authors concluded they wanted a daemon so they didn't have to do things
like file locks, etc. around image management.

Don't know if that accounts for the whole reason or not.

~~~
jhealy
Sounds like it might've been this article?

[https://jpetazzo.github.io/2017/02/24/from-dotcloud-to-
docke...](https://jpetazzo.github.io/2017/02/24/from-dotcloud-to-docker/)?

------
a-ve
To the container wizards: Is it possible to orchestrate lxc containers using
kubernetes? I've been looking at lxc containers for a while and really would
not like to run Docker as root.

~~~
cyphar
LXD has orchestration support natively, though it's not at all like Kubernetes
(you are manually moving containers around and so on).

I have heard that some folks have looked into using LXC under Kubernetes (and
theoretically the OCI templates for LXC could possibly make this somewhat
work) but there isn't an obvious way to do that today AFAIK. And I'm not
convinced (given CNI which touches some deep bits of runc's particular
behaviour) it would work with everything you'd want it to.

~~~
bboreham
> given CNI which touches some deep bits of runc's particular behaviour

Could you explain? I’m a maintainer of CNI and I know almost nothing about
runc, so I’m not clear where they touch.

The first CNI implementation came out of rkt, pre-dating runc by a year or
two.

~~~
cyphar
I mean that it likely makes certain assumptions about how runc sets up
containers which aren't true of LXC. I'm sure you could get CNI to work with
LXC (in fact, someone might've already done that -- I'm not sure tbh) but it
wouldn't be something you'd be able to drop-in without at least a bit of extra
work. For instance, LXC's hooks run in different contexts to OCI hooks (though
we recently discovered that runc runs hooks in different contexts to the OCI
spec, but that's another topic).

And historically, yes it might predate the runc binary but the libcontainer
code that is now part of runc predated CNI -- and all of our fun
idiosyncrasies are in libcontainer.

~~~
bboreham
> likely makes certain assumptions about how runc sets up containers

Nope. CNI takes as parameters a “container ID” (any string) and a network
namespace path. No knowledge is needed or implied about how those things fit
with actual containers.

~~~
cyphar
There are some circumstances where that might not work as seamlessly as
possible (such as with user namespaces -- runc and LXC set those up slightly
differently and run hooks in slightly different orders and contexts) but it
wouldn't be too hard to get it to work. I did a quick search, and it turns out
that making CNI work under LXC did require some patches (though I'm not sure
if they were CNI or LXC patches -- the blog post doesn't link to either) but
they were all merged a bit less than 2 years ago[1].

[1]: [https://s3hh.wordpress.com/2017/10/19/cni-for-
lxc/](https://s3hh.wordpress.com/2017/10/19/cni-for-lxc/)

------
ohiovr
Docker has supported namespaces for a while now so that even if the user in
the container is root it could be a subordinate id on the host with no
administrative authority. What is new though?

~~~
cyphar
The daemon is running as an unprivileged user. Docker with userns-remap is
still running as root (and recent vulnerabilities like CVE-2018-15664 are
still a significant worry even if you ran with user namespaces enabled).

