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

Docker Considered Harmful (2016)

catern.com

Post reply on HN
Print view View original

71–80 of 188 posts

Re: Docker Considered Harmful (2016)

#71

Post by geggam »

jonnycoder wrote: post #62
ravenstine wrote: post #55

Earlier quoted context omitted.

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

This right here. Can confirm, the #1 benefit of using Docker is that 98% of our "Ops" issues has gone away.

No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent.

Enjoy the learnings...

Re: Docker Considered Harmful (2016)

#72

Post by sebringj »

I find myself using it for development more than anything else and it is very nice for that. For example I have a little universe of very singularly purposed things that work together in a bundle. Come time to actually deploy it in production, I would typically have these individual things broke out into their own clusters of servers or cherry pick managed services that make the most sense for cost/reliability/ease of use etc. but I'm sure I'm just inexperienced with all the different scenarios larger orgs would do. At least for development, it really is beautiful to work with and saves loads of time fiddling to get some monstrosity of permutation settings just right after googling many hours to get there. I don't recall spending a day on setting up an env and thinking that it was worth knowing how to do or time well spent.

Re: Docker Considered Harmful (2016)

#73

Post by ravenstine »

bunderbunder wrote: post #60
ravenstine wrote: post #55

Earlier quoted context omitted.

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

At my work, we've had mixed results using it in production. I'd still prefer to using to avoid Ops, but besides that Docker comes with its own bag of issues even though it eliminates versioning conflicts.

For development, on the other hand, I absolutely love it. Being able to have different docker-compose.yml files for each of my projects and being able to spin up isolated versions of database services(each with their own volumes!) has been a tremendous win for me.

Re: Docker Considered Harmful (2016)

#75

Post by d4l3k »

chx wrote: post #52
ghshephard wrote: post #24

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.

Stack exchange has spent an obscene amount of time optimizing their infrastructure for efficiency on dedicated known hardware. Their DB instances also have 1.5TB of ram. You're not getting that for a few hundred dollars.

https://stackexchange.com/performance

Your average site wouldn't get anywhere near the same performance as them.

Re: Docker Considered Harmful (2016)

#76

Post by TheHydroImpulse »

dom96 wrote: post #51
qqqturing wrote: post #33

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.

when you have to manage a large number of services with a bunch of different devs touching things, Docker is almost required to get a consistent development state.

There's literally nothing wrong with reaching for Docker right away. It allows you to have the same, repeatable development environment. Maybe you deploy to production without Docker, but any project I start I'll reach for Docker right away.

Re: Docker Considered Harmful (2016)

#77

Post by marios »

derefr wrote: post #61

The point of Docker is basically that the container-image developer is specifying the sandbox, instead of the sysadmin specifying the sandbox. None of the things mentioned solve the problem of the sysadmin having to "design" the solution from the top down. Docker does. A Docker image is an appliance. You don't architect it; you just configure it. You don't have to care which OS it's running inside. Docker images runn…

You do have to care which OS it's running inside if only to know when to patch it for $vulnerability_of_the_day. It sure is convenient to consider it as a blackbox that you 'just' need to configure, but that's just pushing responsibility to the developer(s). In my short experience, the latter seldom care about security. When a security breach occurs, who is going to take the fall ? The sysadmins that supposedly run operations, or the developers that failed to provided an updated appliance ?

Re: Docker Considered Harmful (2016)

#78

Post by adrianmonk »

markbnj wrote: post #40

All of these arguments are well-aired, and the tone of the article doesn't make this particular presentation of them more useful than any of the others. I would guess a large portion of the developers actively using containers are well aware that they are built from existing system capabilities that can be utilized without docker or any container runtime. I mean this is from 2015: https://chimeracoder.github.io/docke…

Yeah, their zombie process argument is weak.

In theory, you are vulnerable because you've eliminated the zombie reaping mechanism.

In practice, the fact that you're running only one application allows you to make lots of simplifying assumptions so you can avoid getting into this situation quite easily. Just stick with a model where parents never exit before children (and always reap children). You don't need an adoptive parent if you never create orphans.

And even if it did happen, the resource consumption is tiny. Zombie processes free all their memory, close all their files, etc. The only remainder is a small data structure necessary to support stuff like the wait() call returning the process's exit status.

Re: Docker Considered Harmful (2016)

#80

Post by mayoff »

tgsovlerkhgsel wrote: post #39

This article is ignoring the benefits of standardization. Let's compare it to some other "unnecessary" thing, actual containers: You can put stuff on ships without them, but turns out that once you start using them, just the fact that everything is standardized gives you insane benefits. Of course you could reimplement each part of Docker differently. Of course it's not magic. Nothing is magic about a metal box, and…

Anyone interested in the history and effects of the standard shipping container can read (or listen to) “The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger” by Marc Levinson.

http://a.co/20Ok77s

Post reply on HN