Live data from Hacker News

Dissatisfied with Docker

robert.ocallahan.org

151–160 of 229 posts

Re: Dissatisfied with Docker

#151

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 basic problem with Docker is the use of a daemon that is not init.

Access control is at best problematic.

Upgrading the daemon without losing state is tricky.

Requiring daemon access to build images is insane.

Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.

Re: Dissatisfied with Docker

#153
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…

Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(

Re: Dissatisfied with Docker

#154
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...

Nonsense. Applications have a lot of complexity and therefore code around initialization. Adding a little script to deploy them is harmless.

It's also the approach used by various FAANGs operating at a large scale.

Re: Dissatisfied with Docker

#155

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/

One reason it's not very popular (from my experience): Docker Desktop for macs, which makes Docker experience on mac os feel somewhat close to native. Meanwhile, to use LXC you'd have to work inside VM (Virtualbox or similar). Last 3 companies I worked for (in London) were almost 100% mac os (which is a little sad).

Re: Dissatisfied with Docker

#156
post #42

There are two kinds of software: software no one uses, and software people complain about.

Also feature complete software that is regularly used by lots of people, but nobody complains about, because devs don't mess with it anymore. Think ls, grep, yes, ...

Re: Dissatisfied with Docker

#157
post #153
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…

Few seconds are my dream coming true. Try working on an application where every deploy is a coffee break... :(

Starting the process probably isn't what's taking so long though.

Re: Dissatisfied with Docker

#158

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/

How do you create an image for LXC? With docker, they have the docker.io service with all types of distros you can chose from.

You can use the following:

    lxc image import metadata.tar.gz rootfs.tar.gz --alias hello
Not sure which part of the process are you referring to though.

Re: Dissatisfied with Docker

#159
Beside technical considerations, the main point of Docker, to me, is its diffusion. Just like the actual physical containers it gets inspiration from, you can find Docker almost everywhere. It has become a Lingua Franca for devops, even in enterprise environments, and it will be very difficult to get rid of it.

Re: Dissatisfied with Docker

#160

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 basic problem with Docker is the use of a daemon that is not init. Access control is at best problematic. Upgrading the daemon without losing state is tricky. Requiring daemon access to build images is insane. Building this functionality into something like systemd would be more robust but it's way harder to sell as a product.

Yeah Docker should get with the times and be assimilated into systemd like everything else
Post reply on HN