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

81–90 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#81

Post by superuser2 »

rubiquity wrote: post #28
pat2man wrote: 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…

Well, yes, because for one thing, Kubernetes (if done correctly) provides HA/failover that did not previously exist.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#82

Post by inopinatus »

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.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#83

Post by superuser2 »

benjaminwootton wrote: post #31

"However, for many production users today, the pros do not outweigh the cons. Docker has done fantastically well at making containers appeal to developers for development, testing and CI environments—however, it has yet to disrupt production." I keep hearing about people putting Docker in dev and test environments and not production. This use case makes no sense to me as you would throw away the entire point of conta…

Not necessarily. If you're in a microservice architecture, it can be very attractive to "docker run" all the services you're developing against on your development VM.

Relying on Puppet (as with prod) means development VM setup/change time is measured in hours. My company's Puppet catalog takes 15 minutes to compile, 6 hours to run. Entire days of developer productivity are lost trying to get development VMs working. Docker would make that instantaneous. It's also very hard to manage and synchronize data (i.e. test fixtures) across all those services. With Docker you could have a consistent set of data in the actual images and revert to it at will.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#84

Post by kordless »

TheDong wrote: post #79
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…

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.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#88

Post by exelius »

zaargy wrote: post #47
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.

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…

As far as logs go, you should just be doing network logging with Docker to either a syslog server or something like LogStash or Splunk. If you are big enough to have a genuine need for containers, you also are big enough for a centralized logging system.

At the end of the day, you have to view it as building a reliable system that performs a function. Docker is one tool you can use to do that. Virtual machines are another tool. They don't solve all the problems you describe, nor are they intended to. If you're a tiny startup, you can just go the AWS route, but that leaves you beholden to AWS and their pricing. That's fine early on, but eventually you'll want to go full-stack for one reason or another.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#89

Post by toomuchtodo »

eropple wrote: post #39
nailer wrote: post #12

Earlier quoted context omitted.

Even if you're building brand new infrastructure from scratch right now many issues (discussed elsewhere in these comments and the article) are still unsolved.

Yup. At my last gig we built out a Mesos cluster and were deploying Docker containers, but we couldn't answer "how do we practically secure this to the same level as independent virtual machines?" and, finding no good answer, we went back to auto-scaling groups and baked AMIs.

Yes, doing the same thing here as well. Still using docker to streamline deployments though, but one docker container/role per instance, no "orchestration" for containers (baked AMIs, ASGs).

Re: Why Docker Is Not Yet Succeeding Widely in Production

#90

Post by teraflop »

rubiquity wrote: post #54
xkarga00 wrote: post #44

Earlier quoted context omitted.

How did you come up with that number of nodes?

Sorry I was wrong. I assumed based on Kubernetes' use of etcd it would be 3+ nodes. It turns out Kubernetes master is a single node currently which means they haven't built high availability into the master at all... which is a pretty scary way to run a thing that manages your entire infrastructure. There's already a few topics on the mailing list about etcd losing its data and Kubernetes doesn't know how to recover.…

The Kubernetes master does support high availability.

https://github.com/GoogleCloudPlatform/kubernetes/blob/relea...

Post reply on HN