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

261–270 of 290 posts

Re: Why Docker Is Not Yet Succeeding Widely in Production

#261

Post by kordless »

toomuchtodo wrote: post #91
kordless wrote: post #84

Earlier quoted context omitted.

> If this is your advice then you shouldn't give advice. Stop with the blaming statements.

Do you have a better way to say "your advice is bad. stop spreading misinformation"?

Yeah, I do. Simply say what you find inaccurate about what they said and let everyone else come to their own conclusions. Saying "stop spreading misinformation" is basically speaking for others. Maybe we want to hear the misinformation because it's interesting or maybe you are wrong about it being informational or not. Either way, it's my choice to listen to him/her or not.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#262

Post by kordless »

chasb wrote: post #258
kosma wrote: post #233

Earlier quoted context omitted.

Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what ha…

We run Docker in production, as a PaaS no less, and this reads like a list of reasons to use a new-generation PaaS.

Thanks for the chocolate again! :)

Re: Why Docker Is Not Yet Succeeding Widely in Production

#263

Post by kordless »

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…

There are reasons other than scale for containerizing your application. Continuous deployments become a bit easier, for example. Reliability, especially during rolling updates, is improved. It's easier to build a zero downtime app that is in continuous deployment with a containerized stack than it is with more traditional instances.

Regarding the outsourcing, that's what we're shooting for at Giant Swarm. We've written a stack that runs containers and manages the metal underneath for you. We run the solution as a shared public cluster at giantswarm.io, but can also do private hosted deployments or managed on-prem deployments. It's a complete solution for running containers that feels like a PaaS, but without all the opinionated crap associated with a PaaS.

We're basically offering to be your little devops team that could - with containers.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#264

Post by vacri »

Nyetan wrote: post #238
kosma wrote: post #233

Earlier quoted context omitted.

Until a few days ago I was a DevOps engineer at a medium-sized tech company. My primary responsibility was dockerizing their applications and infrastructure. I quit the job. The scenario played out just as you said: I ended up single-handedly and poorly re-engineering something that already existed (they did have a working Ansible setup) for no visible gain. "Swimming in containers upon containers" is exactly what ha…

Bother you for a little advice? I'm working at a mid-sized tech company and am evaluating Docker for CI, testing and limited, internal deployment usages. The services in question are built with a hodge-podge of shell scripts and build tools, so getting them all to compile locally is a challenge, let alone deploying them. My hope was that containerizing the builds would isolate any configuration problems, and that con…

Make your build servers match your production environments. Deploying on SuprCoolOS v4? Build on the same. If it then doesn't build on your buildservers, it's a problem for the developers. If your developer can only get it to build on their UltraCoolOS v9 laptop, it's up to them to fix it - after all, their job is to write stuff that works in production, not on their laptop. They can run a VM or change their OS or whatever. Or ask for a change to production :)

As for rollbacks, the exceptionally bad Docker tagging system just adds headaches to rolling back efficiently. If your production OS has a package management system, consider building packages for that - after all, it will have been battle-tested and known to work on that OS. There will be a learning curve for any packaging system, but using a native one means less faffing around later - remember also that docker is changing a lot with each release.

Also, as mentioned in the article, logging with docker is difficult and hasn't been solved properly yet, and if you like production logs for troubleshooting, Docker requires some attention before you can get those logs. My devs just run the app and watch STDOUT... which isn't easy to log in docker. Then, of course, they complain that they don't have production logs to debug, and subsequently complain when I ask them to modify their logging so I can slurp it :)

Anyway, Docker is not a packaging system for use in-house; if you're only using it to package stuff... you will be ripping it out later on down the line (this is what happened to me). On the other hand, if you open-source your stuff and want to provide 'canned images' for random members of the public to use, then there is a point to using docker, since you don't control what those host machines will be running.

In short, Docker is a complex ecosystem with it's own learning curve, and doesn't really save you from learning curves for other things. If you can't articulate the exact problems that using Docker will solve for you in production, I would advise against it.

Edit: If you need a standardised provisioning system, start out with Ansible. It's pretty straight-forward. Admittedly I've only used it and Puppet... and puppet is better aimed at large/complex infrastructure environments.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#265

Post by laichzeit0 »

kordless wrote: post #260
laichzeit0 wrote: post #149

Earlier quoted context omitted.

Sometimes people need to know they're idiots without the person calling them an idiot having to tip-toe around the issue. Just like how some children are smarter than others and could actually benefit from ring labeled as such, put in a separate environment and given advanced problems to work on instead of lumping them with the rest of the herd. Just like fat people should be told they're fat and pay a premium for a…

Without fully knowing what a person is thinking (and I'm talking in whole here), and the context they are thinking it in, it is impossible to always determine if what someone said is "idiotic" or not, much less be capable of determining if they themselves are an idiot. Given this provable fact, that means there exists a possibility someone ends up calling a savant an idiot for saying something that is viewed by them,…

And I'd wager to say that by and far the more likely possibility is that the person is actually an idiot. Just given that savants are an extremely small subset of the general population and if the bell curve is anything to go by, at least 50% of all people are below average intelligence (whether inherently stupid or uneducated doesn't matter, from a pragmatic point of view the result is the same)

Re: Why Docker Is Not Yet Succeeding Widely in Production

#266

Post by siliconc0w »

Just to oppose the pessimism here - we use docker in production and so far it has worked pretty well. We do run into the problems mentioned in article but they aren't insurmountable. We also built a tool around cluster/deploy management just like we had to do with chef.

IMO any tool that does procedural run-time configuration like chef/ansible/puppet will generally be inferior to an image based infra management solution. (unless you're using said tools to build images - which is another ball of wax that will likely end up looking like a reimplemented docker)

The problem with procedural run-time config is that unless you blow away the VM, build from scratch, and run a test suite you don't really have good assurances your infrastructure is in a good state. With images, you have a bit for bit copy of what was built and tested in CI or QA. This is, for us, worth the price of admission.

Re: Why Docker Is Not Yet Succeeding Widely in Production

#268

Post by Rapzid »

filereaper wrote: post #4

I think Simon nailed it with the points under this heading "Reliance on edgy kernel features" Officially Docker is only supported on RHEL 7 and up, and most systems I've seen are still on RHEL6. I think its just a matter of time before Docker goes into Production, where I'm working we're seriously looking at "Dockerizing" lots of things, but OS support keeps popping up.

Most systems I see run debian or a debian based distro(such as Ubuntu). By comparison to RHEL, they are all running with "edgy kernel features".

Re: Why Docker Is Not Yet Succeeding Widely in Production

#270

Post by vacri »

rubiquity wrote: post #5

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…

> If I have less than 50 (maybe even 100) EC2 instances for my applications there is no way in hell I am going to run 3 service discovery instances, a few container scheduler instances and so on and so forth.

You could go "old school" and have some (virtual) servers do more than one thing :)

Post reply on HN