11–20 of 45 posts
Earlier quoted context omitted.
Would you be willing to elaborate on the reason why you avoid kubernetes?
Like I said it's a personal bias, mainly about Google. The only time I had to use it was with RH's cloud and if it wasn't for their good documentation I would have dropped the client. Everytime I looked under the hood it reminded why I hate being a developer around 35% of the time.
Earlier quoted context omitted.
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.
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…
Don't know if that accounts for the whole reason or not.
Or we could just ditch Docker for one of the alternatives, like Podman that doesn't need root, nor a daemon.
Earlier quoted context omitted.
Like I said it's a personal bias, mainly about Google. The only time I had to use it was with RH's cloud and if it wasn't for their good documentation I would have dropped the client. Everytime I looked under the hood it reminded why I hate being a developer around 35% of the time.
That’s a rather bizarre reason to avoid a pretty solid system.
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?
Earlier quoted context omitted.
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…
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.
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?
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.
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.
Or we could just ditch Docker for one of the alternatives, like Podman that doesn't need root, nor a daemon.
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.