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

141–150 of 229 posts

Re: Dissatisfied with Docker

#141

Post by FreeHugs »

judge2020 wrote: post #68
neckardt wrote: post #56

I'm surprised nobody is mentioning LXC[1]. I'm by no means a containers expert, but they claim to be more secure since they default to running as non-root. Unlike docker, I had no trouble installing LXC with apt, while with docker I often got an outdated version. I'm now using LXC for all of my basic container applications (self hosting a wiki and a few other sites). [1]: https://linuxcontainers.org/

Docker isn't up to date on the official Ubuntu (and debian too?) repos for some odd reason. A better way is either snap (snapcraft) or adding docker's own apt repository.

Aren't those images provided by Ubuntu and Debian? Then it would not be under the control of Docker which versions are provided.

docker.io provides Debian 10 as far as I can tell.

Re: Dissatisfied with Docker

#143

Post by james_s_tayler »

lmeyerov wrote: post #47
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…

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…

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

Re: Dissatisfied with Docker

#144

Post by nullify88 »

jsilence wrote: post #118
aloknnikhil wrote: post #41

> In fact, a global system daemon should not be needed. Either users should be able to run their own daemons or container management should avoid having a daemon at all, by storing container state in a shared database. Absolutely love Podman. You can even define registries to work with docker hub, easily. https://podman.io

Interesting! Are there management tools like Portainer available? Or would, even better, Portainer work with Podman?

Regarding portainer working with podman, not yet it seems. Here's a gh case for it https://github.com/portainer/portainer/issues/2991

Re: Dissatisfied with Docker

#145

Post by james_s_tayler »

spookthesunset wrote: post #123
bob1029 wrote: post #44

What's wrong with booting a VM off a standardized base image (e.g. an AMI), and then applying simple deployment scripts for each application you need to run? You could probably replicate 90% of the justification for using docker with some basic scripting. git clone https://github.com/myprofile/my-cool-app cd my-cool-app chmod +x deploy.sh ./deploy.sh That's it. The above script would be responsible for getting your a…

Okay so write your own crappy (excuse me, graceful and elegant) pile of shell scripts that nobody in your company but you understands? Sounds good to me. The second you leave, somebody is gonna rip that crap out and replace it with docker. All while mumbling under their breath...

This. Times 100x. This is one of Dockers biggest value adds.

Re: Dissatisfied with Docker

#146

Post by antocv »

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…

What do you consider a secret? What other system do you recommend which has the feature you want?

I cant see how one would inject data into a process without ptracing/gdb-attaching to it, messing with its internal memory, or just use environment variables or argument list. If you put it on a file somewhere, you still have to tell the process where the file is by an argument or env and also manage that "volume" and uid space of that file and process.

Kubernetes secrets have nothing to do with containers - it anyway usually exposes the secret as env var or volume and file.

Re: Dissatisfied with Docker

#147

Post by zaarn »

jsilence wrote: post #134
dvfjsdhgfv wrote: post #127

Earlier quoted context omitted.

Because LXC has no marketing money like Docker. For me it's just one of these cool tools I use every day without giving it a second thought.

How is the tooling compared to Docker? Genuinely interested. Are there platforms like Portainer available? Is something like docker-compose possible?

LXC is a bit more simple than that; the modus-operandi is to unpack the rootfs of your favorite distro (ie, ubuntu, alpine) into the container and it runs /bin/init in that container. It essentially behaves like a full VM without the virtualization part.

Tooling would be things like Ansible to setup the container as if you would a normal linux system. Though to be honest, not many people invested in good tooling around LXC, it should be possible without problem to run a docker rootfs in LXC.

Re: Dissatisfied with Docker

#148

Post by heyoni »

antocv wrote: post #146
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…

What do you consider a secret? What other system do you recommend which has the feature you want? I cant see how one would inject data into a process without ptracing/gdb-attaching to it, messing with its internal memory, or just use environment variables or argument list. If you put it on a file somewhere, you still have to tell the process where the file is by an argument or env and also manage that "volume" and ui…

I smell potential for a fun tutorial with that last part!

Re: Dissatisfied with Docker

#149

Post by TheWizardofOdds »

utopian3 wrote: post #136
TheWizardofOdds wrote: post #119

Earlier quoted context omitted.

The long startup time is somehow what keeps me from really liking Docker. In the end (if I understood correctly), it is supposed to be the go-to tool for serverless architecture. If my serverless function needs more then a second to startup, it's not usable for me. Even the hello-world container, which is only a few kB in size needs roughly a second to startup.

> In the end (if I understood correctly), it is supposed to be the go-to tool for serverless architecture. You misunderstood. No one calls Docker a “serverless” architecture.

And i didn't either, I called it a tool for serverless architecture. In fact some tools for serverless architecture like AWS Fargate require you to use Docker.

Re: Dissatisfied with Docker

#150

Post by KaiserPro »

antocv wrote: post #146
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…

What do you consider a secret? What other system do you recommend which has the feature you want? I cant see how one would inject data into a process without ptracing/gdb-attaching to it, messing with its internal memory, or just use environment variables or argument list. If you put it on a file somewhere, you still have to tell the process where the file is by an argument or env and also manage that "volume" and ui…

A secret is anything that you don't want to be public. normally API keys, or some other similar token.

Its not even a case of stopping people attaching a debugger, there is simply not standard mechanism. Some sort of secret store should be a primitive in any container/VM/unikernel built since 2012.

The "recommended" way is to map a volume in to a container. But thats rubbish, there is no standard place to put it, and crucially no API to fill the volume full of secrets. How do I map the specific volume to a container? you can't its manual.

what would be nice is either a tagged value store, so you can specify a tag when you build a container, so that you have a way to signal which secrets your container wants. Or a lump of the container that you can encrypt, that has a key value store in it.

There are lots of documents telling you that you _shouldn't_ embed secrets in your container, but there are not many howtos that don't involve the engineering equivalent of gaffer tape and wet string.

Most of this has now been solved by better[] orchestration systems.

[] not great though.

Post reply on HN