Why Docker Is Not Yet Succeeding Widely in Production • Hacker News Board

Re: Why Docker Is Not Yet Succeeding Widely in Production

#171

Post by fosk » Tue, Jul 28, 2015, 7:53 PM UTC

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…

While I do agree it's not as easy as it should be, connecting containers it's actually doable (https://docs.docker.com/userguide/dockerlinks/), while logs are still a big mess because there is no unified strategy.

Databases are also tricky to run in containers, because even those with the best replication strategies can afford losing nodes but at a high cost (like re-balancing nodes, etc), and containers still don't have the stability to provide an acceptable uptime that's worth the risk.

On a side note, since you mentioned nginx and RESTful APIs, I would check out Kong (https://github.com/Mashape/kong) which is built on top of nginx, and provides plugins to alleviate some of these problems (http://getkong.org/plugins/).

Re: Why Docker Is Not Yet Succeeding Widely in Production

#172

Post by tracker1 » Tue, Jul 28, 2015, 7:56 PM UTC

batou wrote: post #133

dasil003 wrote: post #97

Earlier quoted context omitted.

There was also a time when most people thought they didn't need version control. Back in the 80s and 90s it was a justifiable viewpoint because existing version control systems sucked . The problem with Docker is not that it doesn't solve (or attempt to solve) widespread problems. At its best, Docker gives you dev/production parity, and dependency isolation which is useful even for solo developers working part-time.…

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

With docker, you can run them all... given, you can do the same with virtualization, but that has a lot more overhead. It's about maximum utilization with minimal overhead... For many systems, you only need 2-3 servers for redundancy, but a lot can run on a single server (or very small cluster/set)

I have to agree on ansible, systemd and go... I haven't done much with go, but the single executible is a really nice artifact that's very portable... and ansible is just nice. I haven't had the chance to work with systemd, but it's at least interesting.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#173

Post by davexunit » Tue, Jul 28, 2015, 7:59 PM UTC

api wrote: post #136

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…

I have mixed feelings about Docker. I've found three major use cases so far: (1) Testing. (2) Build environments -- it's helpful to build distribution Linux binaries in older Linux versions like CentOS 6 so that they'll work on a wider range of production systems. (3) Installing and running "big ball of mud" applications that want to drag in forty libraries, three different databases, memcached, and require a custom…

>Docker might still be nice for perfect reproducibility

Docker actually doesn't help reproducibility at all, because the underlying reproducibility problems present in the distro and build systems are used are still present. See GNU Guix, Nix, and Debian's Reproducible Builds project for efforts to make build truly reproducible.

I had a good laugh when I read "the Rube Goldberg Machine development anti-pattern". This describes the situation of "modern" web development perfectly. I'll add that such software typically requires 3 or more different package managers in order to get all of the necessary software. And yes, Omnibus is an abomination and Docker is much better.

I think Docker is papering over issues with another abstraction layer. It's like static linking an entire operating system for each application. Rather than solving the problem with traditional package management, Docker masks the problem by allowing you to make a disk image per application. That's great and all, but now you have an application that can only reasonably be run from within a Linux container managed by Docker. Solving this problem at the systems level, which tools like GNU Guix do, allows even complex, big ball of mud software to run in any environment, whether that is unvirtualized "bare metal", a virtual machine, or a container.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#174

Post by lyschoening » Tue, Jul 28, 2015, 8:07 PM UTC

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…

That's all really easy with Docker Compose. Preserving state is just a matter of mounting a volume.

https://docs.docker.com/compose/ https://docs.docker.com/reference/run/#logging-drivers-log-d...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#175

Post by exarch » Tue, Jul 28, 2015, 8:17 PM UTC

kentonv wrote: post #147

inopinatus wrote: post #82

Earlier quoted context omitted.

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.

Moreover, Docker / Kubernetes aims to solve the problem of building services that can easily scale to hundreds of machines and hundreds of millions of users, "Google-style". That's great, if that's what you need. But most people aren't building a service like that. HN, I believe, runs on one machine, with a second for failover purposes. And HN still has many, many more users than typical company-internal services, co…

"But the industry sure wants to convince us that scalability is the most important property of infrastructure, because then they can sell us complicated tech we don't need and support contracts to help us use it."

And lets not forget: replace any and all efforts at code optimization with "just throw another rack of blades at it".

Re: Why Docker Is Not Yet Succeeding Widely in Production

#176

Post by limaoscarjuliet » Tue, Jul 28, 2015, 8:22 PM UTC

I work in a place which, in order to solve the dependency nightmares, had some highly paid people do magic tricks manually in order to save the day... every day. Every upgrade was hell. Yes, we have Director of Upgrades.

Simple tools (rpm + yum + docker) allowed us to replace these people with a simple shell script. Literally.

I agree with the article Docker is missing some things. Two that I would like to see: - Auto cleanup - Clean and easy proxying

Re: Why Docker Is Not Yet Succeeding Widely in Production

#177

Post by eropple » Tue, Jul 28, 2015, 8:27 PM UTC

dehora wrote: post #155

eropple wrote: post #39

Earlier quoted context omitted.

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.

I was wondering, what did you think of the production readiness of Mesos independent of Docker?

Seems reasonable, if you want to be running lots of things on the same boxes without isolation (I'm not comfortable with that, but you might be). If you're sharing those resources for stuff like Spark, ElasticSearch, etc. I think it makes sense as a work scheduler, but there are a lot of other options to consider too.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#178

Post by digi_owl » Tue, Jul 28, 2015, 8:36 PM UTC

exarch wrote: post #175

kentonv wrote: post #147

Earlier quoted context omitted.

Moreover, Docker / Kubernetes aims to solve the problem of building services that can easily scale to hundreds of machines and hundreds of millions of users, "Google-style". That's great, if that's what you need. But most people aren't building a service like that. HN, I believe, runs on one machine, with a second for failover purposes. And HN still has many, many more users than typical company-internal services, co…

"But the industry sure wants to convince us that scalability is the most important property of infrastructure, because then they can sell us complicated tech we don't need and support contracts to help us use it." And lets not forget: replace any and all efforts at code optimization with "just throw another rack of blades at it".

http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...

Re: Why Docker Is Not Yet Succeeding Widely in Production

#179

Post by Leon » Tue, Jul 28, 2015, 8:42 PM UTC

eropple wrote: post #170

toomuchtodo wrote: post #165

Earlier quoted context omitted.

We bake the container into the AMI, so no fetch is necessary at spin up (there is no cost to generate AMIs, only storage fees, so cost is not an issue). Packer is used to build the AMIs with the containers built-in, and Docker is used both in Prod (single container to each AMI) and Dev (Docker Compose to bring up entire dev env locally). Both used a shared docker registry.

Ahh, gotcha. That's a neat approach, though the double hit of Docker builds + AMI builds feels a little weird to me. Thanks for the insight.

I also do what the other poster does, but we take it a step further and make sure that the layers on the image have smaller and more variable layers near the last layer add. On instance startup we can do a docker pull and bring down only a few k of bytes for docker image updates. This way we can update the ami less often (which it takes longer anyway) and we don't worry too much about pushing updates to the container repo without having to batch ami builds for quicker turn around deployment.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#180

Post by iopq » Tue, Jul 28, 2015, 8:44 PM UTC

maratd wrote: post #167

iopq wrote: post #162

Earlier quoted context omitted.

Yeah, but then there's still the issue of secrets, you need to have testing PayPal credentials, testing mailing service credentials, etc. There's the issue of deploying changes fast without leaving files in an inconsistent state (you don't want half of some file to run). How about installing the required dependencies? I don't use Docker, but those are problems I can think of off the top of my head.

> Yeah, but then there's still the issue of secrets How would Docker help with this? Genuinely curious. I store them in bash scripts outside the repo that populate the relevant data into environment variables and execute the code. The code then references the environment variables. > How about installing the required dependencies? There are two kinds. On the OS level and on the platform level. On the OS level, you ca…

I don't know if Docker helps with this, I don't use Docker. But some kind of solution has to exist.

How AWS does updates is it first downloads the new code into a separate folder and then switches the link to point to the new folder instead.

But AWS has an unsatisfactory feeling because it downloads the entire code instead of doing a git update. These are all issues that could be fixed, and someone has to do them. I have no idea if Docker helps with any of them, but the opportunity is still there.