Live data from Hacker News

Why Docker Is Not Yet Succeeding Widely in Production

sirupsen.com

61–70 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#61
post #47
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…

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 inspect app

`docker exec -it [ container id ] bash` ("ssh" into container)

`docker logs`

`docker -f logs` (follow logs)

> How to measure performance

Probably same way you measure system performance

> How to manage security

Everything of mine is in a VPN; some services can talk to certain services over certain ports... Personally, I don't really understand all this talk about security. Protect your systems and that should protect your containers. Why is it that isolated processes are causing people to throw up their arms like security is an unimaginable in such a world? There are ways..

> Consistency across docker containers

This can be a pain if you need this, yea. They see to be adding better & better support to allow containers to talk to one another (and ONLY to one another).

> Ain't nobody got time for that.

Hmm, personally I don't have time to go thru what Puppet, Chef, and even Ansible require to get your systems coordinated. I see this as far more work than creating a system specification within a file and finding a way to run it on some system.

All comes down to requirements though and where your technical stack currently is at. To any newcomers who are also plowing into the uncertain fields of a dockerized stack, fear not! You are in good company and if I can make it work, you can too.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#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?

Re: Why Docker Is Not Yet Succeeding Widely in Production

#63

I think the reason is because the tooling and the companies (CoreOS, Joyent, Weave, etc.) building all of the tools, are only focusing on grabbing Fortune 500 customers. Nobody is building Docker tools for the "Blue Collar Apps" of the world. And those companies might be completely justified because the benefits of Docker versus Amazon AMIs/RPMs/DEBs/etc. aren't that big enough to make us go crazy for Docker and swit…

Disclaimer: I'm the CTO at Joyent.

For whatever it's worth, we completely agree with the sentiment (and I like your "blue collar apps" term) -- and we deliberately have designed Triton[1] for ease of use by virtualizing the notion of a Docker host. I think that the direction you are pointing to (namely, ease of management for very small deployments) is one that the industry needs to pay close attention to; the history of technology is littered with the corpses of overcomplicated systems that failed because they could not scale down to simpler use cases!

[1] https://www.joyent.com/blog/triton-docker-and-the-best-of-al...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#64

I'm confused by this paragraph > Every major deployment of Docker ends up writing a garbage collector to remove old images from hosts. Various heuristics are used, such as removing images older than x days, and enforcing at most y images present on the host. ... More specifically, I'm confused by this sentence, from the above paragraph in TFA: > Most people discover their need by accident when their production boxes…

"The time for Dockers and containers isn't quite today, but it's very close." Hmmm ... tell that to AirBnb ( http://nerds.airbnb.com/future-app-deployment/ ), New Relic ( https://blog.newrelic.com/2014/08/12/docker-centurion/ ) and Spotify ( https://blog.docker.com/2014/06/dockercon-video-docket-at-sp... ) It is a young technology, but moving quickly. Just 10 years ago, YouTube wasn't owned by Google yet and we didn'…

[deleted]

Re: Why Docker Is Not Yet Succeeding Widely in Production

#65

I'm confused by this paragraph > Every major deployment of Docker ends up writing a garbage collector to remove old images from hosts. Various heuristics are used, such as removing images older than x days, and enforcing at most y images present on the host. ... More specifically, I'm confused by this sentence, from the above paragraph in TFA: > Most people discover their need by accident when their production boxes…

"The time for Dockers and containers isn't quite today, but it's very close." Hmmm ... tell that to AirBnb ( http://nerds.airbnb.com/future-app-deployment/ ), New Relic ( https://blog.newrelic.com/2014/08/12/docker-centurion/ ) and Spotify ( https://blog.docker.com/2014/06/dockercon-video-docket-at-sp... ) It is a young technology, but moving quickly. Just 10 years ago, YouTube wasn't owned by Google yet and we didn'…

I don't understand how "Companies are using containers." suddenly translates to containers being ready for prime time.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#66
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?

Virtual Machines

Re: Why Docker Is Not Yet Succeeding Widely in Production

#67

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…

Ultimately I'd say Cloud Foundry solves the problem but requires a lot of "support" VMs to make it work such that it might be overkill for your situation.

For example:

- What underlying OS? CF provides a minimal Ubuntu Linux "stemcell" and then has a standard "rootfs" for Linux containers

- a Python buildpack to assemble the container on top of this OS for your Flask server

- a built-in proxy/LB so you don't need one, if you want a static web server there's a static buildpack for Nginx

- an on demand MariaDB Galera cluster for your database if you want HA; PostgreSQL is there too but non-HA I think

- A standard environment variable based service marketplace & discovery system for connecting the containers to each other or to the database

- high availability (with load balancer awareness) for your containers at the container, VM or rack level

- reliable log aggregation of your containers (which you can divert to a syslog server).

As I said the only trouble is when you want to make this "bulletproof" is that there are a dozen "support VMs" are all there to make your app bulletproof and secure, e.g. an OAuth2 server, the load balancer, an etcd cluster, Consul cluster, and the log aggregator, etc. So it's overkill for one app, but good if you have several apps.

For single tenants and experimental apps, there's http://lattice.cf which runs on 3 or 4 VMs and is a subset of the above, but not what I'd call "production ready".

Re: Why Docker Is Not Yet Succeeding Widely in Production

#68
post #64

Earlier quoted context omitted.

"The time for Dockers and containers isn't quite today, but it's very close." Hmmm ... tell that to AirBnb ( http://nerds.airbnb.com/future-app-deployment/ ), New Relic ( https://blog.newrelic.com/2014/08/12/docker-centurion/ ) and Spotify ( https://blog.docker.com/2014/06/dockercon-video-docket-at-sp... ) It is a young technology, but moving quickly. Just 10 years ago, YouTube wasn't owned by Google yet and we didn'…

[deleted]

Can we please stop sounding the trumpet of "progress"? Containers have been around for nearly a couple of decades (possibly more if you extend the definition), since IBM i had LPARs.

There's nothing fast-moving or technologically novel about, especially, Linux containers.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#69
post #27

Earlier quoted context omitted.

Because "running things just fine" across production, continuous integration and on dev machines is actually quite a hard thing to do. But then, if you don't feel like you need it, that's probably because you don't need it. (If people are downvoting your question, it's probably because you're giving off a bit of a "I don't understand Docker so it must be crap" vibe, which is not helpful.)

OK, now we're getting somewhere. What is difficult about getting things right across production and CI? What are the pain points? What are the exact problems we're being asked to solve here? I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems. Sorry if my initial question came across with a weird vibe. I'm…

> I don't think dev environments need to be harmonized the same as production. If your tests are good, you should catch most of the "it worked on my laptop" problems.

That's true until something break in production: then you want to replicate the same situation in the dev environment, as close as possible.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#70
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..
Post reply on HN