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

111–120 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#111

Post by lucaspiller »

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…

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

Even without that issue, I'd prefer my logs to be centralised. So as well as my app should I be running a logging daemon, process monitoring, etc for each docker instance?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#112

Post by feld »

dalyons wrote: post #103
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…

There's a few projects out now that do most of this for you; there's a lot of rapid innovation in higher-level docker tools. eg https://github.com/remind101/empire (built ontop of EC2/ECS) You get a 12 factor compatible PaaS out of it, pretty easy.

The funny part is that Docker was supposed to be higher level.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#114

Post by istvan__ »

Benjamin_Dobell wrote: post #40
istvan__ wrote: post #35

Earlier quoted context omitted.

This is exactly the problem here, just run Postgres on the host means that you have a hybrid setup, some of your services dockerized the rest are not. This is not appealing to some people. There are other services mostly in the heavy disk IO space that is not easy to move to Docker. It might be worth to call these out in the documents and save some time to sysadmins figuring this out the hard way. If you want to dock…

I have zero problem with a hybrid setup. I'm not running Docker just for the sake of running Docker. I'm running Docker (specifically Dokku) because it drastically simplifies deploying new builds, and graduating those builds between environments. I know a large part of this article was that Docker complicates rather than simplifies the situation. I guess if you're trying to be a Docker purist (for no reason) then sur…

I think the deployment is the weakest point of the Docker ecosystem.

The reason why I am using Docker is the forced honesty on the environment side, if your app runs on your laptop it does not mean it will run on the production boxes. If the Docker container runs on your laptop it gives you higher confidence that it will run on the production infra. No missing JARs, environment variables, misconfigured classpaths, etc.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#115

Post by gusfoo »

> Configuration management software like Chef and Puppet is widespread, but feel too heavy handed for image building. I bet such systems will be phased out of existence in their current form within the next decade with containers.

Hmm, I don't think so. My reason is that, in addition to the maturation and feature growth of containers, there will also be feature growth in Puppet et al.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#116

Post by amouat »

toomuchtodo wrote: post #106
amouat wrote: post #101

Earlier quoted context omitted.

There's no need to say that at all. Just address the points and let everyone form their own opinions.

Because opinions are not the same as facts/best practices (nor is everyone's opinion equal). If you want to argue "this is the right way", be prepared to bring data and defend your statements. People here might be making critical decisions based on knowledge shared here, and they deserve the most accurate information possible.

Fully agree.

That's why you should talk to the points and not make personal statements like "you shouldn't give advice".

Re: Why Docker Is Not Yet Succeeding Widely in Production

#119

Post by juliangregorian »

knicholes wrote: post #19
therealmarv wrote: post #15

I would be sold on Docker if that would be easy. I have e.g. this stack: - 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask - 1 database, let's say PostgreSQL and I want to connect all 3 things and I want to preserve logs for the whole time and preserve the state of the database (of course). Also not to forget make all bulletproof for the Internet. And here all sorts of problems arise…

docker-compose comes to save the day when it comes to how to connect containers. Your Dockerfile will specify which underlying OS is used. Preserve state of your database with data volumes.

It doesn't connect containers across nodes though, so it's use in realistic production scenarios is limited.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#120

Post by d23 »

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.

That's what you got from the article? I got the opposite. It works fine until you start to have large, complex images where build time becomes a factor and the fundamental design of Docker starts to get in the way (e.g. how it manages diffing of images, the lack of caching, and the inability to build different parts of the image in parallel). These shouldn't be as big of a deal at smaller scale.

That's not to say you're wrong; containers probably aren't that useful to most small shops. But that summary doesn't make any sense for this article.

Post reply on HN