Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

Post reply on HN
Print view View original

201–210 of 229 posts

Re: Dissatisfied with Docker

#201

Post by shaklee3 »

wokwokwok wrote: post #28
zests wrote: post #6

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 s…

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.

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.

Re: Dissatisfied with Docker

#202

Post by fhgsfkcc »

paulddraper wrote: post #200
KaiserPro wrote: post #137

A few things that I would add to that list: o No primitives to deal with secrets. o Terrible disk handling (aufs was just horrid, overlay2 I think misses the point. device mapper is just, silly) o poor speed when downloading and uncompressing images. Of all of them, the most serious is the lack of secrets handling. Basically you have to use environment variables. Yes, you can use docker compose and stuff appears, but…

> the most serious is the lack of secrets handling. Basically you have to use environment variables. That's how I always handle my secrets. (12 factor app) Am I missing a better way?

secrets don't belong in env vars, because many languages and/or frameworks will happily dump all your env vars to users in the event of misconfiguration or some errors.

Re: Dissatisfied with Docker

#203

Post by paulddraper »

fhgsfkcc wrote: post #202
paulddraper wrote: post #200

Earlier quoted context omitted.

> the most serious is the lack of secrets handling. Basically you have to use environment variables. That's how I always handle my secrets. (12 factor app) Am I missing a better way?

secrets don't belong in env vars, because many languages and/or frameworks will happily dump all your env vars to users in the event of misconfiguration or some errors.

I have literally never seen that happen. (Outside a core dump, which has a lot more than env var.)

You have any examples in mind?

Re: Dissatisfied with Docker

#204

Post by djsumdog »

imiric wrote: post #126
djsumdog wrote: post #25

These are all pretty good points. I can understand why Docker allows any base layer OS, but they could have made their own packages or limited a single distro and it would be easier to check for outdated packages and security issues in containers. The cgroups and Linux specific hooks keep Docker from being implemented natively anywhere else. The fact you have to share the entire Docker socket for containers to be abl…

> The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Dock…

I created an ansible role that does this for me:

https://github.com/sumdog/bee2/blob/master/ansible/roles/doc...

It creates client certs and copies them locally too, so I can connect to Docker remotely over a VPN. Still this doesn't solve the original problem I talked about. It's not about securely connecting to the daemon. Even if you connect securely, you still essentially have root access on the host machine.

I've considered writing a proxy that restricts what commands can be forwarded on to the Docker host socket (e.g. allowing for container IPs x,y and z to restart containers, but not to create new ones or pull images). There doesn't seem to be fine grained security or roles built into the docker daemon itself.

Running docker in a docker container would give you a throw-away docker to use for things like Jenkins, Gitlab-CI, and other build tools without giving it access directly to root on the host.

Re: Dissatisfied with Docker

#205

Post by imiric »

djsumdog wrote: post #204
imiric wrote: post #126

Earlier quoted context omitted.

> The fact you have to share the entire Docker socket for containers to be able to control other containers, or that it's not trivial to run Docker-in-Docker, is terrible. FWIW, if you enable the remote API, which, granted, isn't as trivial to do securely as it should be[1], then you can connect from any Docker client by simply setting the `DOCKER_HOST` env var and using the right TLS certs. This makes Docker-in-Dock…

I created an ansible role that does this for me: https://github.com/sumdog/bee2/blob/master/ansible/roles/doc... It creates client certs and copies them locally too, so I can connect to Docker remotely over a VPN. Still this doesn't solve the original problem I talked about. It's not about securely connecting to the daemon. Even if you connect securely, you still essentially have root access on the host machine. I've…

> Even if you connect securely, you still essentially have root access on the host machine.

Your original point was about the pain of sharing the Unix socket to control other containers, so that's why I brought up the API approach.

It's been a while since I used Docker, but have you tried enabling user namespace remapping[1]? I remember it working as documented, and don't see why it wouldn't work remotely or DiD. There's also experimental rootless support since 19.03[2], maybe give that a try. Other than that, make sure you trust the images you run, or preferably, inspect every Dockerfile, ensure that the process runs as an unprivileged user, and build everything from scratch yourself.

I agree with you that this is a major security issue, but we've known that since its introduction, and things seem to be improving, albeit slowly.

Thankfully, nowadays there is other OCI-compatible tooling you can use and sidestep Docker altogether. Podman[3] is growing on me, mostly because of rootless support, though it's not without its issues and limitations.

[1]: https://docs.docker.com/engine/security/userns-remap/

[2]: https://github.com/moby/moby/blob/master/docs/rootless.md

[3]: https://podman.io/

Re: Dissatisfied with Docker

#206

Post by xyzzy_plugh »

chucky_z wrote: post #54
l_t wrote: post #12

Earlier quoted context omitted.

Maybe containerd [0] is an alternative? It's being used in k3s instead of Docker. [0]: https://containerd.io/ edit: I didn't notice that you mentioned this in your comment, my bad. Can you explain why it doesn't work for you? I'm new to the Docker-alternative scene and thought it looked pretty good at first glance.

Docker uses containerd. Here's an image straight from a blog post from last year: https://i1.wp.com/blog.docker.com/wp-content/uploads/2018/09... https://blog.docker.com/2018/09/join-the-beta-for-docker-eng...

It does and it doesn't. The interface is pretty different. Using containerd directly as a binary is pretty rough around the edges, but docker uses it as a library. In particular the CRI implementation works, but leaves a lot to be desired. Their release cycle is also pretty lengthy, such that each minor release has a ton of changes, resulting in a lot of work to integrate into your infra.

Re: Dissatisfied with Docker

#208

Post by k__ »

anordal wrote: post #128

... then I suppose Selfdock is for you. * Does not give or require root. * Fast: Does not write to disk. * Fast: Does not allocate memory. * No daemon. https://github.com/anordal/selfdock

I read podman can be simply aliased to docker and it works. Is this the case for selfdock too?

Re: Dissatisfied with Docker

#209

Post by CameronNemo »

oblio wrote: post #174
Smithalicious wrote: post #160

Earlier quoted context omitted.

Yeah Docker should get with the times and be assimilated into systemd like everything else

You could argue about many things bundled with systemd, but since containers are just souped-up processes, this is actually an use case that make sense for an init system.

I disagree. I would prefer to have a model where the supervisor needs no knowledge of the LSM profile, namespaces, seccomp profile, or cgroups applied to a service. Additionaly, I would prefer a non-init service supervisor.

Re: Dissatisfied with Docker

#210

Post by hbt »

nickjj wrote: post #37

I've been using Docker since 2015ish and the container start up / stop speed is really the only thing that bugs me. Everything else is fine for day to day usage IMO (on Windows and Linux at least) and very much worth the trade offs, but having to wait multiple seconds for your app to start is tedious since it plays such a heavy role in both development and even in production. Each second your app is not running is do…

- start the container with docker run and run sleep 999

- then start your application with docker exec

you will have instant execution.

Only restart your container if the environment changes (new build etc.)

For development, mount your source code in readonly.

Post reply on HN