6 ms·

I'm newer to the Docker scene but haven't really found any of the complaints in this article realized in my work. Faster speed would be nice but I don't really

by zests 7y ago

I'm newer to the Docker scene but haven't really found any of the complaints in this article realized in my work. Faster speed would be nice but I don't really mind it now. I see a lot of complaints about the docker daemon and root privileges on HN and I've tried to understand where they are coming from but I can't get anywhere. For instance, I understand the reasoning behind "if there is no need for a daemon there shouldn't be a daemon" but I don't really understand what the actual/realized/tangible benefits of not having a daemon would be.

roca 7y ago
We have observed the daemon getting into a bad state and stopping responding to container create requests, wedging our production system. I guess this kind of bug could happen with a non-daemon approach if there's shared state, but it seems less likely. Not using any components with root privileges obviously makes things more secure. Another benefit of not requiring a daemon or privileges is that then it should be easy to manage fully independent sets of containers. In particular a container should be able to manage its own nested containers in a straightforward way. This is painful in Docker.
wokwokwok 7y ago
It would be faster. I also don’t really care if a container take 2 seconds or 100ms to start... but building docker images is painfully slow. I’ve also ended up (numerous times) with the “docker daemon is borked” situation, which requires a restart to fix... and you can imagine how that sucks on a prod or multi tenant systems.
- roca 7y ago
  One reason we care about containers taking seconds to start is that our CI tests have to start and stop a lot of containers, and it all adds up. And running them in parallel wouldn't help because they would just bottleneck on the global docker daemon... or break entirely by interfering with each other, unless we run multiple Docker-in-Docker setups, which would be even more painful and add its own overhead.
- krferriter 7y ago
  I've also run into the daemon crashing on production systems and taking down all of the other containers on that host. I end up just killing the host and restarting the jobs on a newly provisioned one. There's a lot of overhead. If they could get it to run without requiring a persistent (and root) shared daemon that would be a big improvement.
- shaklee3 7y ago
  I think a lot of this depends on how you set up the context in your build. I've seen a lot of people just set the context to a specific directory with no ignores. The docker daemon by default tars up the entire context directory, which can be multiple GB. However, as you point out, even if you fix that problem, for some reason many of the stages take a very long time, even if they are just copying a small text file.
lmeyerov 7y ago
We hit security concerns here in two directions: -- When our sw gets deployed on-prem by our users (or in their cloud, or wherever), our customers rather not deploy our SW with root for no good reason. Some of them have to do things like fill out forms ahead of time or on use due to this (!). -- In turn, when we run third-party code, say as a normal dependency or a user-submitted script, we have no reason to trust it. That means we want to limit what it can do, and especially if something breaks out, have defensive layers. (Browsers & NodeJS are Technology From The Future in this regards.) Note that almost all "docker exploit X FUD" articles, in fine print, make assumptions around running docker as root / privileged / etc. It's 2019, we know better. Also, we happen to run an increasing amount of our stack as GPU code, which adds a (not so) funny layer to all this.
- james_s_tayler 7y ago
  I didn't consider the on-prem use case, but I can see how that could become an issue.

by zests 7y ago

roca 7y ago

We have observed the daemon getting into a bad state and stopping responding to container create requests, wedging our production system. I guess this kind of bug could happen with a non-daemon approach if there's shared state, but it seems less likely. Not using any components with root privileges obviously makes things more secure. Another benefit of not requiring a daemon or privileges is that then it should be easy to manage fully independent sets of containers. In particular a container should be able to manage its own nested containers in a straightforward way. This is painful in Docker.

wokwokwok 7y ago

It would be faster. I also don’t really care if a container take 2 seconds or 100ms to start... but building docker images is painfully slow. I’ve also ended up (numerous times) with the “docker daemon is borked” situation, which requires a restart to fix... and you can imagine how that sucks on a prod or multi tenant systems.

roca 7y ago
One reason we care about containers taking seconds to start is that our CI tests have to start and stop a lot of containers, and it all adds up. And running them in parallel wouldn't help because they would just bottleneck on the global docker daemon... or break entirely by interfering with each other, unless we run multiple Docker-in-Docker setups, which would be even more painful and add its own overhead.
krferriter 7y ago
I've also run into the daemon crashing on production systems and taking down all of the other containers on that host. I end up just killing the host and restarting the jobs on a newly provisioned one. There's a lot of overhead. If they could get it to run without requiring a persistent (and root) shared daemon that would be a big improvement.
shaklee3 7y ago
I think a lot of this depends on how you set up the context in your build. I've seen a lot of people just set the context to a specific directory with no ignores. The docker daemon by default tars up the entire context directory, which can be multiple GB. However, as you point out, even if you fix that problem, for some reason many of the stages take a very long time, even if they are just copying a small text file.

lmeyerov 7y ago

We hit security concerns here in two directions: -- When our sw gets deployed on-prem by our users (or in their cloud, or wherever), our customers rather not deploy our SW with root for no good reason. Some of them have to do things like fill out forms ahead of time or on use due to this (!). -- In turn, when we run third-party code, say as a normal dependency or a user-submitted script, we have no reason to trust it. That means we want to limit what it can do, and especially if something breaks out, have defensive layers. (Browsers & NodeJS are Technology From The Future in this regards.) Note that almost all "docker exploit X FUD" articles, in fine print, make assumptions around running docker as root / privileged / etc. It's 2019, we know better. Also, we happen to run an increasing amount of our stack as GPU code, which adds a (not so) funny layer to all this.

james_s_tayler 7y ago
I didn't consider the on-prem use case, but I can see how that could become an issue.