Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker in Production: A retort

patrobinson.github.io

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Docker in Production: A retort

#121

Post by user5994461 »

jsz0 wrote: post #85
carapace wrote: post #6

I've never used Docker, or containers, but I read about things like "Breaking changes and regressions ... a well documented problem with Docker" and "Can’t clean old images ... a well known issue" and it just seems to me like a crazy thing to try to use and depend on this thing/company. Bluntly put they seem like children. So nevermind a retort, what I would like to see is a sane, sensible "business value" cost/benef…

> seems to me like a crazy thing to try to use and depend on this thing/company Always beware of perception bias or whatever the right term is for this. When docker was new it got tons of hype and people were talking about how great it was. Now it's no longer the hot new thing so it's just another tool many people are using quietly and successfully. It no longer warrants much positive discussion. The people using doc…

You're taking the wrong assumption here.

There aren't articles about docker in production because barely anyone adopted it for major production environments [yet]. And for the few who are early adopters, there wasn't enough time to write articles.

Re: Docker in Production: A retort

#122

Post by user5994461 »

pmarreck wrote: post #19

Anyone know why Erlang doesn't run well on containerized Docker?

Hello. It was a long time ago and I didn't get all the details.

I think it either came down to a broken version of docker at the time that couldn't run properly.

Or it was because of unstability from Docker. All our Erlang apps are meant to take thousands of requests per second and Erlang have particular ideas about how the system/network should behave. It's very hard on Docker and any unstability or incompatibly would make up for outstanding failures.

Either way, we know for sure now that there were many major critical issues with Docker at the time of the Erlang trial. Not adopting it was the right decision, and it still is.

We only use Erlang for critical applications. We really can't afford to push the limits after a few red flags.

Re: Docker in Production: A retort

#123

Post by pmarreck »

bitwalker wrote: post #116
pmarreck wrote: post #19

Anyone know why Erlang doesn't run well on containerized Docker?

I run several erlang/elixir applications in containers, it works just fine. I'm not sure why someone claimed it doesn't, but I suspect they didn't try very hard if they did have trouble.

Chokes under significant load, perhaps? Do your erl/iex apps receive much traffic?

Re: Docker in Production: A retort

#124

Post by nickthemagicman »

user5994461 wrote: post #21
nickthemagicman wrote: post #9

I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?

> Is there a coffee machine that is ok to use for a docker app somewhere? Most coffee machines are docker ready. To guarantee you the best experience, you will need to setup a pair of coffee machines, plus an orchestration system that will be responsible for swapping them automatically when one ran out of coffee. Note: There are only prototype of orchestration systems. Nothing for sale in the corner shop yet. --- Mor…

Haha a coffee load balancer. I love that idea. I'm sure Amazon will have a coffee machine web service they offer for $2000/month. ACS.

This whole ordeal has actually been a really really good lesson for me about mature vs less than mature apps. It's been really enlightening to read the posts and discussion.

Re: Docker in Production: A retort

#125

Post by nickthemagicman »

sheeshkebab wrote: post #11
nickthemagicman wrote: post #9

I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?

AWS was also considered not a fit for running "core" apps and databases... look where we are now. Docker is certainly having some teething issues - and things like kubernetes are certainly WIP. But I wouldn't be as skeptical - plenty of companies use it in production already, for "core" apps.

Interesting, yeah I truly see the potential of the idea. It's definitely the future. Really glad to see Google and others getting on board and giving them the resources they need.

Re: Docker in Production: A retort

#126

Post by nickthemagicman »

flurdy wrote: post #79
nickthemagicman wrote: post #9

I love how the major issue, that both this article, and the original article warn about is: don't use docker on 'CORE APPS'.... That says all you need to know about the trustworthiness of Docker. EVEN DOCKER PROPONENTS caution against using it in 'important' apps.... What apps are people investing time in that aren't 'important'? Is there a coffee machine that is ok to use for a docker app somewhere?

I interpret that as don't use X (in this case Docker) with your most essential services. Initially. Get your teeth cut, make some mistakes, establish routines, etc with your internal apps, your low traffic services, etc. Be patient, then once comfortable and confident your start to roll it out to your core, heavily integrated services in production. Having just come off a year at large(very large) government departme…

Hmmmm, if you need ton's of workarounds and there's a huge learning curve to learn the weird quirks(bugs), I don't think the tech is necessarily stable...

Re: Docker in Production: A retort

#127

Post by ageofwant »

otterley wrote: post #94
CSDude wrote: post #46

Earlier quoted context omitted.

I really don't understand why you insist. You keep saying "best-practice" like it is a law, but the truth is there is no such thing is best. It fits our cases, worked well, continues to work well. Did I say it cannot be managed with traditional package managers? No. But I do not like upstart nor systemd, and I like the simplicty I get from Docker, and ability to replicate the almost same environment easily. I really…

Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you. Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practi…

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-images

Re: Docker in Production: A retort

#128

Post by otterley »

ageofwant wrote: post #127
otterley wrote: post #94

Earlier quoted context omitted.

Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you. Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practi…

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-i…

If the DB vendor is supplying and supporting the images, then that's a different story, of course. The devil is in the details, and the presence of Docker support shouldn't be interpreted to suggest that other aspects of database administration shouldn't be followed.

At any rate, at least MySQL and its Percona variant have native packages for modern mainstream Linux distributions , so as a practical matter you shouldn't need to run them in a container: they've already worked out the dependencies for you. This means you don't need to bother with the overhead of Docker.

Re: Docker in Production: A retort

#129

Post by [deleted] »

ageofwant wrote: post #127
otterley wrote: post #94

Earlier quoted context omitted.

Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you. Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practi…

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-i…

[deleted]

Re: Docker in Production: A retort

#130

Post by [deleted] »

ageofwant wrote: post #127
otterley wrote: post #94

Earlier quoted context omitted.

Well, for one, because many database vendors won't provide support unless you're using the bits they've precompiled for you. If you think you'll never need outside help for the lifetime of your organization, then more power to you. Another reason is that you're introducing an unnecessary dependency/component that can introduce potential instability. Common sense (since you seem to be offended by the term "best practi…

And this is exactly why you should containerise your db's run environment with docker. Dependency management. You cannot control your host environment to the same degree you can control the docker environment, given the same amount of effort. If Oracle only supports RH6 and you use Ubuntu LTS on your host, you run it in a RH6 based container. Oh look, maybe even use the official one https://github.com/oracle/docker-i…

[deleted]
Post reply on HN