Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

71–80 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#71

It is still early, and it took nearly half a decade to get companies to use cloud services and that has a well defined API for orchestrating resources. It will take similarly long for containers to have well tread paths for discovery, logging, failover, image building etc... etc..

it took nearly half a decade to get companies to use cloud services and that has a well defined API for orchestrating resources

There's lots of stragglers; sometimes it's a struggle to get people to even consider AWS for development boxes.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#73
post #16

Earlier quoted context omitted.

Kubernetes solves this by mounting external volumes (say NFS or iSCSI) on the host and then exposing them to one or more docker containers. This seems like a pretty ideal solution for any Docker user.

Are you suggesting that a person with a total of 3 nodes use a system like Kubernetes which requires at a minimum (correct me if I'm wrong) 5 nodes just to function? If you really, really want to use Docker with a typical Nginx-App-DB setup just whip up the necessary shell commands to start/stop/log containers and throw that in Ansible or the like. edit: I guess you can cram all of the various Kubernetes master/etcd…

It's the future!

http://blog.circleci.com/its-the-future/

Re: Why Docker Is Not Yet Succeeding Widely in Production

#74
post #62
post #57

I'd really love to include docker in our puppet testing framework, so we can do actual meaningful tests without deploying to real environments. But, dealing with all of the problems of deploying docker to production doesn't look worth the time investment for a medium sized company IMO(we're at ~1700 vms)

What does vms stand for?

[deleted]

Re: Why Docker Is Not Yet Succeeding Widely in Production

#75

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 will likely be more prevalent in a few years with startups who have built their infrastructure form the ground up.

The opposite seems likely ... Docker will fade and become deprecated as building infrastructure from the ground up locally to feed into the cloud becomes cheaper and cheaper still. AWS is not always so cost-effective when you truly dig in and crunch the numbers.

My guess as to why Docker won't succeed widely in production is because it's a software-based solution trying to glue together slippery pieces that just don't want to be glued together. The core issue of security will never be solved by a Docker-like solution; that problem is best solved by integrated hardware.

This very issue is being addressed in ClearLinux: http://sched.co/3YD5

Re: Why Docker Is Not Yet Succeeding Widely in Production

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

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).

Re: Why Docker Is Not Yet Succeeding Widely in Production

#77
post #36
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.

I have a feeling this is not just a problem with Docker. People tend to choose technologies not because they solve their problem, but because it's hip to be using the newest stuff, even if it's far too big and complicated for their simple usecase.

In this regard I think the remarks of McKinley's "Choose Boring Technology" [1,2] is quite relevant.

[1]: http://mcfunley.com/choose-boring-technology-slides [2]: http://mcfunley.com/choose-boring-technology

Re: Why Docker Is Not Yet Succeeding Widely in Production

#78

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 will likely be more prevalent in a few years with startups who have built their infrastructure form the ground up. The opposite seems likely ... Docker will fade and become deprecated as building infrastructure from the ground up locally to feed into the cloud becomes cheaper and cheaper still. AWS is not always so cost-effective when you truly dig in and crunch the numbers. My guess as to why Docker won't suc…

DevOps/infra guy here rolling out Docker startup-wide at the moment. You and minimaxir are both correct.

With regards to docker/lxc/container security, you're right. Some of the biggest players haven't solved the lxc/docker/container security issues yet; its a really hard problem to solve. Breaking out of container will always be easier than breaking out of deeper levels of virtualization (Xen/KVM).

Re: Why Docker Is Not Yet Succeeding Widely in Production

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

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 run them

4) That only works if the container is running. What if it died? Also, docker logs is a fool's game

5) bingo, that's right at least

6) ....

Re: Why Docker Is Not Yet Succeeding Widely in Production

#80
post #41
post #7

The security question (it's possible to break out of containers) isn't solved, and the workaround (use VMs) eliminates many of the advantages of containers and adds a massive burden.

> 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?
Post reply on HN