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

181–190 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#181

Post by spoondan »

tracker1 wrote: post #172
batou wrote: post #133

Earlier quoted context omitted.

Ansible, systemd and go is stealing my heart at the moment. Basically pick the tech that doesn't cause the problems to start with. I still reckon that the main reason VMware ESX is as successful as it is comes down to the lack of isolation and sheer deployment hell that windows has been for years. The same can be said for python or ruby on a Linux machine for example. Docker removes some of that pain like ESX does.

That's a bit of my point... If you're building relatively small independent services with Docker you can deploy service A with node 0.10 as it's tested environment and service B with iojs 2.4 on the same server, without them conflicting... when you need to update/enhance/upgrade service A you then can update the runtime. The same can be said for ruby, python and any number of other language environments where you hav…

> The same can be said for ruby, python and any number of other language environments where you have multiple services that were written at different times with differing base targets. I've seen plenty of instances where updating a host server to a new runtime breaks some service that also runs on a given server.

This is a solved problem in Python and Ruby. In Python, use virtual environments. In Ruby, use RVM. You won't have the issue of one tenant breaking another.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#182

Post by patsplat »

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.

More accurate TL;DR: Docker and containerized architectures generally would be improved by solving this list of problems.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#183

Post by peterwwillis »

Am I the only person noticing that these problems only exist because you're using containers, and that maybe by not using a container model you can simplify everything except running 10 different versions of an app at once? Maybe containers provide more headaches than they solve.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#184

Post by tracker1 »

spoondan wrote: post #181
tracker1 wrote: post #172

Earlier quoted context omitted.

That's a bit of my point... If you're building relatively small independent services with Docker you can deploy service A with node 0.10 as it's tested environment and service B with iojs 2.4 on the same server, without them conflicting... when you need to update/enhance/upgrade service A you then can update the runtime. The same can be said for ruby, python and any number of other language environments where you hav…

> The same can be said for ruby, python and any number of other language environments where you have multiple services that were written at different times with differing base targets. I've seen plenty of instances where updating a host server to a new runtime breaks some service that also runs on a given server. This is a solved problem in Python and Ruby. In Python, use virtual environments. In Ruby, use RVM. You w…

And with node, you can use nvm... however there are libraries and references at a broader scope than just Python, Ruby or Node... Say you need an updated version of the system's lib-foo.

A runtime environment for a given service/application can vary a lot, and can break under the most unusual of circumstances. An upgrade of a server for one application can break another. Then you're stuck trying to rollback, and then spend days fixing the other service. With docker (or virtualization) you can segregate them from each other.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#185

Post by acdha »

superuser2 wrote: post #81
rubiquity wrote: post #28

Earlier quoted context omitted.

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.

Is it really more likely to believe that someone who is not otherwise in the PaaS business is going to find it easier to run 5+ nodes of other services instead of, say, two nodes running their application directly for failover/HA?

This is not to say that Kubernetes is bad but … it's a commitment which isn't appropriate for everyone. If you aren't exercising its abilities heavily, that's probably going to be a distraction from more pressing work unless you're scaling up heavily right now.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#186

Post by Leon »

dcosson wrote: post #145

The security point here is something that confuses me about the current state of the ecosystem. The article mentions that "most vendors still run containers in virtual machines", presumably since if someone hacks an app in a container they might be able to break out of the container and access other apps running on that host. But clustering systems like Kubernetes, CoreOS, AWS Container Service, etc. seem to be all t…

Once you've automated the entire process of bringing up a container cluster with monitoring, metrics, logging, etc then it becomes trivial to make as many as you want. The same is done with separate virtual networks for security concerns.

It becomes as simple as asking what name the cluster should have.

It also makes sense from managing resource concerns to some extent, such as a cluster with cheap instances for low priority applications but need HA support or a cluster with beefy instances in a subnet that has fewer hops should be used for edge tier applications.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#187

Post by BraveNewCurency »

collyw wrote: post #154
100k wrote: post #73

Earlier quoted context omitted.

It's the future! http://blog.circleci.com/its-the-future/

Crap like that actually happens. I have a mathematician friend who does a bit of programming ask me about Docker, as someone had told her to use it. She works as a researcher in academia, so probably only needs to run her script a few times to get results. Why the hell would you recommend Docker?

> probably only needs to run her script a few times to get results.

Agreed that she doesn't need to use Docker. But if she is writing a paper on those results, she might want a way to reproduce her findings years down the road (even after she switched Distros), or to collaborate with others who want to reproduce/build on her research (and may not be running her distro).

It's easy to think "oh, this script just requires python 2.7", but most of the time you actually have many more dependencies than that (libxml, graphviz, latex, eggs, etc.) A Dockerfile requires some work to setup, but it tracks your requirements in an automated way.

So I'm not going to say "all researchers should use Docker". But I will say "Docker could be useful to some researchers". Just like Source Control, it's a tool that solves real problems. Source Control has gotten easy enough to use that it's recommended everywhere. Docker (or some other container standard) will get there eventually.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#188

Post by superuser2 »

geggam wrote: post #166
superuser2 wrote: post #140

Earlier quoted context omitted.

For multitenant situations, sure. Still more isolation than running a bunch of services on the same box.

what is the benefit to any isolation of a process for a single tenant ? and why cant you just run cgroups without the overhead of docker ? see : bocker

>what is the benefit to any isolation of a process for a single tenant?

Build, test, and ship the same artifact. Whether it's a Vagrant on your Mac, AWS, or metal in your colo datacenter.

>and why cant you just run cgroups without the overhead of docker ?

If you're running cgroups, you've created your own half-baked implementation of Docker in giving yourself a reasonable API to work with. This might make sense if you're Google but otherwise probably not.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#189

Post by mkulke »

kitwalker12 wrote: post #129
crb wrote: post #122

Earlier quoted context omitted.

Can you share your experiences with Kubernetes setup?

It's pretty complicated with GCE itself. for GCE, I followed this http://kubernetes.io/v1.0/docs/getting-started-guides/gce.ht... guide. I eventually wanted to set it up in Rackspace where my company cloud lives. I used corekube( https://github.com/metral/corekube ) heat templates to set it up but the way to add more minions to the cluster wasn't simple. On top of that there's this complicated networking I have to se…

Corekube is somewhat complex template (and not supported by kubernetes currently). Just attempt to roll your own, it's actually not that hard. You can use the official coreos "getting started" cloud-config files as a starting point. Etcd & flannel are required, the rest is just wiring a set of binaries.

Adding nodes is pretty straightforward, you just create a server with the proper cloud-config, they should auto-register at the master. A serious setup, however, involves using security groups/private networks and load balancers, also cinder is not supported as a volume backend yet.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#190

Post by therealmarv »

mseri wrote: post #77
huskyr wrote: post #36

Earlier quoted context omitted.

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

Big thanks for this links. Actually this is really true for Docker and DevOps. There are proven concepts and known unknown but for Docker the unknown unknown part is really scary especially regarding security for production. Maybe for bigger companies this is no problem but for small dev teams this is very risky and time consuming.

Just one non trivial example: I can secure Ubuntu against sshd attacks pretty good and easy with `sudo apt-get install fail2ban`. Now try to secure CoreOS against sshd attacks. There are guys out there who tried to run fail2ban in a container (without luck) and so far I've only found one hacky script which tries to do the same oO https://github.com/ianblenke/coreos-vagrant-kitchen-sink/blo...

Post reply on HN