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

221–230 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#221

Post by joshmn »

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 a client, pre-funding but has some revenue, who is hell-bent on using their Rackspace credit for their production environment. "But we have a sysadmin who works for yahoo"

He tries to demo me what they have currently and the damn thing timed out during login. I laughed.

The cost of these headaches is easily avoidable. Get off the ground and running first, pay the kind-of-premium Heroku bill, and when you're ready to really scale, make the switch.

There are few exceptions to managing an infrastructure, such as RackSpace, a cluster of AWS nodes, your own metal, etc. versus something like Heroku.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#222

Post by patsplat »

istvan__ wrote: post #35
Benjamin_Dobell wrote: post #33

Earlier quoted context omitted.

- 1 webserver/proxy, let's say nginx - 1 simple Rest API server, let's say in flask Dokku - https://github.com/progrium/dokku Can't really beat `git push deploy/uat` - 1 database, let's say PostgreSQL I just run PostgreSQL on the host and connect to it from the containers. Sure I could containerise PostgreSQL itself but I don't really see the point. I then run my own Dokku plugin (dokku-graduate: https://github.com/g…

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…

It's useful to "mount" the database to the app process via injected configuration.

Application and database servers are different animals. Not sure why a 'hybrid' approach would be surprising or unappealing.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#223

Post by parasubvert »

kapilvt wrote: post #215
parasubvert wrote: post #67

Earlier quoted context omitted.

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…

spoken like a pivotal employee... cf has almost zero support for data services, and suffers from nih at almost every layer of the stack from routing to mq, to one of the worst ux for installs ever (aka bosh), cf is a great example of commercial opensource primarily controlled (inspite of foundation) by one entity (pivotal/vmware) that figure out how to switch from monetizing virtualization to single processes. you ev…

And where do you work? What does any of the above have to do with the OP's question?

1. Data services, not true. There's MariaDB, Cassandra, Neo4J, Mongo, Postgres, among others. Yes, they're in VMs, but recoverable/reschedule-able persistent volumes in container clusters are at best experimental features anywhere you look.

2. NIH, compared to what? CF reuses etcd, consul, monit, haproxy, nginx, etc. will use runC and appC as those get hammered out.

3. Lots of people love BOSH.

4. If you don't like all the decisions Full CF makes, this is why Lattice exists, it delegates config/install to Vagrant or Terraform (which have their own problems) so anyone can take the core runtime bits with Docker images and use them in new and interesting ways.

5. What container or cloud platform project isn't based on code contributed by one or two vendors? Realistically? None. The CF foundation at least is an honest attempt to give all the IP to a neutral entity (including the trademark soon), has several successful variants (mainline OSS, Pivotal, Bluemix, Helion, Stackato), and has customers and users joining the foundation, not just vendors.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#224

Post by superuser2 »

geggam wrote: post #200
superuser2 wrote: post #188

Earlier quoted context omitted.

>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 yo…

cgroups is docker now ? what does that make systemd-nspawn ?

Docker is a simplified interface for controlling cgroups, yes. (Some people are working on/using alternative backends now, but that was the whole point at the beginning - a nice API for cgroups.)

Re: Why Docker Is Not Yet Succeeding Widely in Production

#225

Post by [deleted] »

Leon wrote: post #219
toomuchtodo wrote: post #192

Earlier quoted context omitted.

If you're in AWS, I wouldn't worry about how many bytes docker image updates take. Our registry is using S3 as its backend, and I can pull images under 100MB in a few seconds.

It's not always an option to host and manage a registry, some parts it's easier for the customers to rely on a registry service like quay, in which case it can make a difference for some images to think about layering. But you are right, s3 is fast and that's one of the reasons I'm glad Deis moved to support s3 out of the box.

[deleted]

Re: Why Docker Is Not Yet Succeeding Widely in Production

#226

Post by oldmanjay »

scurvy wrote: post #30
scurvy wrote: post #17

Earlier quoted context omitted.

But why the need for abstraction and isolation? If I'm a reasonably well run web shop that knows how to run their apps and balance out server load, what does Docker get me? Also, shout out to the fanboys for downvoting my question, which was just a question asking for thoughts and answers and didn't make any statement whatsoever.

@mateuszf can you give actual examples of each? I can upgrade nginx on my servers without affecting memcache or MySQL or redis or....Why the need for isolation there?

Docker is a tool to empower developers to better manage the applications that we currently leave to people who, and I'm trying to be charitable here, seem to think knowing how to type and be rigid in their opinions is some kind of qualification for managing systems.

It has literally nothing to do with the ability to upgrade independent pieces on the sysadmin's schedule and everything to do with abstracting sysadmins clean out of the process. The entire profession has established itself as a roadblock to progress, so like good engineers do, we're busy coding the problem away.

Basically.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#227

Post by iamleppert »

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil.

Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker.

Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll cry! Meanwhile you have 0 rows of data before you've paid them their first month's salary and have spent time on solving problems of scale you'll never have.

Focus on your product, outsource the rest. And leave customized docker setups to mid-stage startups and big corps who already have these problems, or at least the money and people to toil on them. Not everything needs to be a container! And most companies are not and will never be Google!!

Re: Why Docker Is Not Yet Succeeding Widely in Production

#228

Post by eropple »

chucky_z wrote: post #214
eropple wrote: post #164

Earlier quoted context omitted.

Docker doesn't credibly solve the credentials problem and the other problems you outline (which do exist) are as practically solved with something like Packer. And I mean, I'm not a Packer fan--oh look, VirtualBox failed to remove a port mapping for the VM that just shut down, throw away the whole build --but it's built on much, much more battle-tested technology with a much wider base of understanding. (And, later,…

Thanks for pointing me to Racker ( https://github.com/aspring/racker ). I'm currently building Packer and Terraform images with chunked together Python scripts that work, but I wouldn't call them a great solution. I'm actually using Packer specifically so I can start with regular EC2, and then move to a more Docker-based infrastructure.

Packer severely frustrates me, with the maddening regularity in which it fails just for funsies. Or the consistent but completely inane ways that it fails, like refusing to proceed based on not finding a builder for an 'only' or 'except' clause (making it nearly impossible to re-use provisioners and post-provisioners across multiple projects). Racker does help--my shared Racker scripts are in a Ruby gem--though I think that it pretty much removes Packer as anything more than a dummy solution into which you dump directives on a per-builder basis. As a tool that you carefully feed the bare minimum of information to do its job in any specific situation, though, it works okay.

Terraform, on the other hand, I think is a huge, huge mess, and I don't think they're going to fix it. I wrote a Ruby DSL for it the last time I tried to use it in anger, only to encounter that Terraform didn't honor its own promises around the config language it insisted on instead of YAML or a full-featured DSL of its own. Current client uses it, and every point release adds new and exciting bugs and regressions in stuff that should be caught by the most trivial of QA. For AWS, I strongly recommend my friend Sean's Cfer[1] as a better solution; CloudFormation's kind of gross, but Cfer helps.

[1] - https://github.com/seanedwards/cfer

Re: Why Docker Is Not Yet Succeeding Widely in Production

#229

Post by jfroma »

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…

Node has this too : nave, npm and n. But using these tools means that you are not longer using the package manager of the system and this can be a problem sometimes. Eg you need to open your firewall to something else that it is not the standard pkg manager.

I see docker as a valid attempt to fix limitations of existing and broken package system (eg: apt) at a price that I am not yet willing to pay.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#230

Post by [deleted] »

iamleppert wrote: post #227

I've said it before and I'll say it again: pre-mature infrastructure optimization is the root of all evil. Do me a favor and if you got a startup, stay clear of all this. Everyone wants to reinvent their own flavor of heroku and make your deployment and build pipeline god-awful complex. Their tool of choice? Docker. Before you know it you'll be swimming in containers upon containers. Containers will save us, they'll…

[deleted]
Post reply on HN