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

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

Post reply on HN
Print view View original

91–100 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#91

Post by toomuchtodo »

kordless wrote: post #84
TheDong wrote: post #79

Earlier quoted context omitted.

If this is your advice then you shouldn't give advice. 1) 'docker logs' relies on using the json logdriver which means the log file is stored in /var/lib/docker/..... and grows forever. No rollover. No trimming. FOREVER . 2) What if your container dies? What if your host dies? Do you have any state at all or have you abstracted that out? Are your systems distributed 3) Always running does not answer finding where to…

> If this is your advice then you shouldn't give advice. Stop with the blaming statements.

Do you have a better way to say "your advice is bad. stop spreading misinformation"?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#92

Post by lloydde »

jgrowl wrote: post #55
amouat wrote: post #41

Earlier quoted context omitted.

> it's possible to break out of containers Prove it. I'm not saying it's impossible, but it's certainly not trivial. Also, take a look at what Joyent are doing with Triton.

I was going to mention Triton/SDC. It does solve the security issues though it does it by running SmartOS. SDC is pretty cool but docker really needs to be secure in its own right. It is also worth mentioning that since Joyent has implemented their own docker client, not all features are there yet. Last time I tried docker-compose didn't really work right yet. There is a full list of divergences on their github page.…

> since Joyent has implemented their own docker client

Not our own docker client, our own Docker engine, https://github.com/joyent/sdc-docker , which was necessary for the whole DC to be the host. For a taste of the details see https://www.joyent.com/developers/videos/bryan-cantrill-virt... .

Your larger point is correct, we're still working hard every day to add increase the support particularly for the newer docker apis and extensions. Now, docker-compose 1.2 is working in the production datacenters with docker-compose 1.3 in the east-3b (beta) dc.

https://www.joyent.com/developers/triton-faq

https://github.com/joyent/sdc-docker/blob/master/docs/api/di...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#93

Post by zaargy »

joslin01 wrote: post #61
zaargy wrote: post #47

Earlier quoted context omitted.

I still love Docker and do think it solves a genuine problem. But yes, where to put your logs, how to manage state, how to schedule containers on machines, how to coordinate processes, how to inspect an app when something goes wrong, how to measure performance, how to manage security, how to keep consistency across your docker containers... are all problems you need to solve from the get go with Docker and they are a…

I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to…

Well I used Docker on top of Mesos so I have quite a bit of experience and the above were all problems I faced. They're not impossible problems obviously but they take time and thought to solve. From your responses, I am not sure you fully appreciate the problem to be honest.

You have to remember that you containers and coming and going all the time, which is one of the biggest challenges. It basically means you have to have everything centralised and that means a lot of additional infrastructure/complexity.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#94

Post by juliangregorian »

ploxiln wrote: post #76
joslin01 wrote: post #61

Earlier quoted context omitted.

I'm not sure how much you know about docker, so to anyone in whom this list scares: > Where to put logs Well, I just throw them aside and use `docker logs [container]` > How to manage state One container should perform one service. I haven't run into a problem here. > How to schedule containers ECS :) But honestly, I subscribe to the approach that containers = services and thus should just always be running. > How to…

The problem(s) with "docker logs" is that, without getting logs out of docker you can't see multiple containers' logs interleaved, and without a separate logrotate setup they're not rotated (the files in /var/lib/docker/containers/ grow indefinitely).

If this is what it takes to get procrastinators onto a real logging stack I'm not sure I see it as a problem.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#95

Post by amouat »

nailer wrote: post #80
amouat wrote: post #41

Earlier quoted context omitted.

> it's possible to break out of containers Prove it. I'm not saying it's impossible, but it's certainly not trivial. Also, take a look at what Joyent are doing with Triton.

I know that 'appeal to authority' is a bad argument technique but the Docker authors themselves have mentioned this repeatedly in the past. IIRC one of the holes was sysfs. Has something changed?

It's more that containers haven't been proven secure than that they are inherently insecure, so I disagree with the blanket statement "it's possible to break out of containers".

VMs have the advantage of shielding the kernel with a hypervisor, but they also have the disadvantage of lots of complicated driver code that can allow exploits such as VENOM.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#97

Post by dasil003 »

inopinatus wrote: post #82
minimaxir wrote: post #2

While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…

Docker solves a problem that most people don't have. It's not a PaaS, rather, it's (some of) the building blocks to create your own PaaS. Most folks don't need that. Most folks want to put files on a server and start a process. For those folks, Docker in the raw ends up being a whole lot of confusing & unnecessary scaffolding.

There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked.

The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time. The problem is that it's not a well-defined problem that can be solved by thinking really hard and coming up with an elegant model—like, for example, version control—it's messy and the effort to make it work isn't worth it most of the time right now.

That's no reason to write off Docker though. Pushing files to manually configured servers or VPSes is messy and leads to all kinds of long-term pain. You can add Chef / Puppet, but it turns into its own hairy mess. There's no easy solution, but from where I stand, the abstraction that Docker/LXC provide is one that has the most unfulfilled promise in front of it.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#98

Post by phunkystuff »

zaargy wrote: post #11

TL;DR It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.

Is it too complicated because people already have complicated set ups? or just in general?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#99

Post by saosebastiao »

I'm pretty disillusioned with docker so far. Haven't put in too much time with it, but the little time I have put into it has produced nothing of value. I'm surprised we're still talking about it to be honest, with so much progress in unikernels like OSv, HalVM, Mirage, and Ling.

In the two hours I've spent with OSv, I've gotten much lighter weight VMs that boot my large scala app extremely quickly (a few seconds, max), with less configuration and more predictable performance.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#100

Post by KirinDave »

minimaxir wrote: post #2

While the article goes into the more technical reasons for not using Docker in production, the practical reason "Why Docker Is Not Yet Succeeding Widely in Production" is that if it ain't broke, don't fix it. The advantages of Docker do not necessarily outweigh the opportunity cost of rewriting the startup's entire infrastructure. Docker will likely be more prevalent in a few years with startups who have built their…

> is that if it ain't broke, don't fix it.

I hate being passive-aggressive so I'll be directly aggresive here: this mentality is a way to say, "I don't want to revisit the operational aspects of my system because I don't like to do that work. Find someone else."

Like any aspect of your system, your ops and deploy components can rot. Pretending otherwise is outright ignoring a consistent lesson offered by those who came before and have failed over and over.

Docker offers to take over as a project many aspects of the system subject to bit-rot and make an explicit and consistent container abstraction for software to compose. While it has many features we do need (I agree wholeheartedly that it'd be great to parallelize layer creation, less so about secret exposure since the environment & volume tooling already can do that), it has also replaced whole categories of software and devops tooling with simple and extensible metaphors.

Post reply on HN