Live data from Hacker News

Docker Considered Harmful (2016)

catern.com

51–60 of 188 posts

Re: Docker Considered Harmful (2016)

#51

I think Docker is very useful for beginning developers and for spinning up and trying out services quickly. The barrier for getting started with web development used to be so much higher, even for people on Mac OSX. To setup a rails development environment with a modern JS frontend, you'd have to setup xcode, mysql, redis, a node build pipeline, homebrew, and futz with system ruby vs rails-specific ruby. You'd have t…

The author seems a bit out of touch. I'm a junior dev and starting a db for development is as easy as `docker run redis`. I don't even know half the tools he mentioned and i will not read the linux source documentation like he suggested to get isolation for my services.

Starting redis manually isn't that much harder though:

    brew install redis
    redis-server
I personally feel that people reach for Docker too quickly. It's worthwhile to learn how things actually work so that you know what to do when Docker eventually fails you.

Re: Docker Considered Harmful (2016)

#52

Docker by itself probably doesn't make any sense to an engineer until they get a chance to see kubernetes in action. There is nothing more awesome than seeing, on the fly, your worker pool being scaled out by 100x by nothing more than kubectl --context k8s-uw1a-gcp -n customerx scale deploy someapp_worker --replicas 100 to make you appreciate what docker can do for you.

I am absolutely sure there are usecases for that.

But the truth is, most websites will happily run on a single dedicated machine you rent for a few hundred dollars. (OK, two, so you have a hot spare, if you so fancy.) This fact often gets overlooked despite even Stackexchange tweeted once or twice they could run their site with a single DB server. But: cloud! Kubernetes! Hype. Meh.

Re: Docker Considered Harmful (2016)

#53

Like any hyped up technology, Docker gets pitched as an "easy, works out of the box, secure by default solution" but it is almost anything but. But also like any technology, if you take the time to really understand what it is doing and what problems it can solve for you, it can be really awesome to work with. Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you ca…

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations…

It empowers developers to side step many of the best practices learned in SDLC over the last 20 years and ship code they shouldn't

The code is then running on a fault tolerant platform which masks the bugs and makes ops life hell when it comes to actual debugging.

Additionally upgrades and other assumptions about the base OS and system management are simply swept under the carpet with pretending those issues no longer exist.

Effectively it makes much much more work when things break and is great when it runs well or you run it in GCP where they take care of that part for you.

Re: Docker Considered Harmful (2016)

#54
post #51

Earlier quoted context omitted.

The author seems a bit out of touch. I'm a junior dev and starting a db for development is as easy as `docker run redis`. I don't even know half the tools he mentioned and i will not read the linux source documentation like he suggested to get isolation for my services.

Starting redis manually isn't that much harder though: brew install redis redis-server I personally feel that people reach for Docker too quickly. It's worthwhile to learn how things actually work so that you know what to do when Docker eventually fails you.

For me, it's less about the ease of starting one thing than it is the ease of juggling a lot of things. I've got docker containers on my machine for multiple work projects and a few organizations I do volunteer dev work for. Between them, I'm running two versions each of Ruby and Python and a number of instances of Postgres and MySQL, plus local Redis containers for three separate projects. Shifting between them is as simple as docker-compose down/cd/docker-compose up. When I'm done developing for the day, I just take everything down and bring it back the next morning.

Re: Docker Considered Harmful (2016)

#55

Like any hyped up technology, Docker gets pitched as an "easy, works out of the box, secure by default solution" but it is almost anything but. But also like any technology, if you take the time to really understand what it is doing and what problems it can solve for you, it can be really awesome to work with. Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you ca…

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations…

> Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff.

I think this is one of the biggest reasons people use Docker, although they tend to forget to mention it since it's not exactly a technical advantage of Docker; in many ways, it allows developers to bypass DevOps or sometimes eliminate them all together. No more creating Jira tickets just to have a specific version of Imagemagick installed on a server.

Re: Docker Considered Harmful (2016)

#56

Aside from being a bad argument for the reasons already listed, I'm honestly getting tired of the "X considered harmful" meme, when the author never actually makes an argument that docker is harmful, only superfluous.

An old favorite: “Considered Harmful” Essays Considered Harmful (https://meyerweb.com/eric/comment/chech.html).

Re: Docker Considered Harmful (2016)

#58
Docker wins because it's easy to use and becomes a de-facto standard. The author misses that completely.

I get it, you can do "manually" the same things as docker when you're a good system administrator. You'll come up with your own unique solution to most problems addressed by docker. Regardless of the fact that it'll probably be specific to a single linux distribution, you probably won't have anyone interested in investing time in learning your unique way of doing containers.

I did not waste time when I learned how docker does it.

I login into a server managed by this author, curse him for using all those "standard" techniques in his own unique way. Spend hours figuring out the details.

I login into a server running things with docker: I already know all I need. `docker ps` will tell me what services it runs, `docker inspect` for more info, `docker logs` give me the logs of whatever service I need to check, etc.

Re: Docker Considered Harmful (2016)

#59
post #25

This article could use some work so I thought I'd chime in with my complaints about Docker... * Patching security vulnerabilities in container images (aka "the next Heartbleed problem") and auditing for the same. * docker-compose is installed via a curl to github. Say what? It's like Docker revels in ignoring the system's package manager. Docker does not and should not replace apt-get but people pretend it does. * To…

> Patching security vulnerabilities in container images (aka "the next Heartbleed problem") and auditing for the same.

This is a lot of tooling out there to deal with this, including multiple complimentary (both as in free and tools which compliment each other) implementations of security scanners.

> Too much config delegated to container entrypoint script.

Can you explain what you mean here? Config of what? Also, have you peered into init scripts for any given application? Application initialization often requires a fair amount of setup that is completely dependent on what the application is. This is not really possible to abstract outside of forking and making the image itself less generic, which is perfectly fine.

> Firewall rules get wiped out too easily. More a pet peeve of mine but it'd be nice to solve this without "service docker restart".

Using firewalld helps with this as dockerd can (and does) monitor the firewalld for the need to reload rules.

Watching iptables directly is rather difficult outside of just polling iptables to see if the ruleset matches what's expected. Not sure it's feasible outside of "does the DOCKER chain exist? No -> reload"

> --rm" should probably have been the default and the migration to something better needs to start now.

You can't change the default for something like this. It also isn't necessarily the desired behavior. If you really want this to be default, use swarm services instead.

---

Full disclosure, worked at Docker for 4 years (now recently at MSFT) and am a maintainer on the docker engine.

Re: Docker Considered Harmful (2016)

#60

Earlier quoted context omitted.

> Every "Docker Considered Harmful" post I've read basically boils down to "Why would you use Docker if you can use the 10 technologies it wraps around and manage them yourself instead?" Why would I want to do that if I don't have to? Or if you can't? One feature driving Docker adoption that I think a lot of people miss is that it's got fairly workable (if warty in one case and obnoxious in the other) implementations…

> Sure, your ops team can put together a bunch of stuff manually. And then you can create a bunch of extra stuff that makes it easier for development to handle all of that inside virtual machines, and get the network bridging between those apps and the host machine working properly, and all that fun stuff. I think this is one of the biggest reasons people use Docker, although they tend to forget to mention it since i…

I think it's one of the two biggest reasons. The other, possibly bigger, reason is that it gives you a way to install fairly complex software and have it reasonably configured and running right out of the box.

I use Docker to run stuff like PostgreSQL on my dev box. Not so much because it's a technically superior option (in truth, it's slower and eats more memory than installing it directly on my machine) as much as because it reliably lets me get up and running in a few minutes, just the time it takes to download the image, really. All the other options I've tried invariably require some fiddling, especially if you need an older version.

I suspect that all the other codepoints that have ever been spilled on the subject are mostly just an attempt to get ops on board with it.

(Disclaimer: All above comments are a mix of wild speculation and Freudian projection. I tend to come down against using it in production.)

Post reply on HN