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

Why Databases Are Not for Docker Containers

myopsblog.wordpress.com

Post reply on HN
Print view View original

141–150 of 184 posts

Re: Why Databases Are Not for Docker Containers

#141

Post by ec109685 »

user5994461 wrote: post #80
NikolaeVarius wrote: post #45

Earlier quoted context omitted.

I'm doing a bit of a simplification here so please someone correct me if I'm not saying this correctly Every single instance of a VM has its own Kernel. When a VM boots up, it gets allocated a portion of hardware and boots up a kernel and allocates memory to itself. VMs each are isolated from each other in that they don't share resources and each VM is free to do whatever it wants to do with the hardware it is given.…

VMs share resources from the host: disk, network, memory. Just like a container shares resources from the host. Containers re-use the running Operating System from the host, it saves memory but it can only run a single OS. A VM can run any operating system, and each VM runs its OS independently. VMs are memory intensive, there is a base 100-500MB to pay to run any VM because of the independent OS. (Note that the adva…

Containers give the OS the ability to optimally schedule processes among them. VMs are black boxes to the hypervisor, limiting its ability to optimize.

Re: Why Databases Are Not for Docker Containers

#142

Post by halayli »

isn't that what was said when VMs came out?

But I'd say it's not ripe yet to run a DB in a container for prod use. it's not an architecture issue but rather code maturity. DBs hold our beloved data and are more sensitive to hardware/system glitches which excersises much less frequent code paths in the DB.

Re: Why Databases Are Not for Docker Containers

#143

Post by markbnj »

XorNot wrote: post #54

This article is terrible. It's a lot of wishy-washy explanations devoid of technical detail - because their isn't a technical explanation or justification for this list. I've run extensive benchmarks of Hadoop/HBase in Docker containers, and there is no performance difference. There is no stability difference (oh a node might crash? Welcome to thing which happens every day across a 300 machine cluster). Any clustered…

Exactly, and thank you.

Re: Why Databases Are Not for Docker Containers

#144

Post by takeda »

bborud wrote: post #104

"You may corrupt the data in case of container crash where database didn’t shutdown correctly. And lose the most important part of your service." This is the point in the article where you know you don't need to read the rest. If your data integrity hinges on your database being able to shut down correctly you will be disappointed. The author believes in fairytales.

It's kind of interesting how knowledge works with some subjects.

If you don't know anything, you will agree with the statement. When you know a bit more, you will disagree, but when you learn more than that you will once agree.

It's true that real databases need to guarantee data won't disappear even at power loss, so you would think that container crash should be comparable with power loss, if not more trivial.

The thing is that the database can provide such guarantees (write things in correct order, write to disk when database says so etc), but only if the underlying system provides specific guarantees to the database.

The storage drivers are quite buggy, so reliability of your data is still in hands of these drivers.

Re: Why Databases Are Not for Docker Containers

#145

Post by activatedgeek »

I am so surprised and disappointed that such a shallow article has made it to the top. It provides absolutely no value.

Most of the upvotes (gathering a consensus from comments) are not because they believe that Docker is not the right tool but because they have been frustrated by the ops part of things.

I'm also surprised at how many think that one tool will come and solve all their problems. Guys, it doesn't work that way. Docker had one job and it does it fairly well - process isolation for humans (ok the engine goes crazy sometimes but hey everything does). For all the other things, you need to setup your own workflows, tools and processes.

Tomorrow, another rant article would come at how apt sucks but in fact, apt and friends are just an amazing example of how packaging should be done. It is not ideal, but it works! Everything fails sometimes and that is when new things for it come up.

If every immature developer started adding rants on the internet, we would pretty much be disregarding half of the software. To the OP, if you are not able to achieve something, please don't rant just because you couldn't do it.

Re: Why Databases Are Not for Docker Containers

#146

Post by [deleted] »

activatedgeek wrote: post #145

I am so surprised and disappointed that such a shallow article has made it to the top. It provides absolutely no value. Most of the upvotes (gathering a consensus from comments) are not because they believe that Docker is not the right tool but because they have been frustrated by the ops part of things. I'm also surprised at how many think that one tool will come and solve all their problems. Guys, it doesn't work t…

[deleted]

Re: Why Databases Are Not for Docker Containers

#147

Post by ec109685 »

user5994461 wrote: post #86
gkop wrote: post #74

Earlier quoted context omitted.

Google does publish https://github.com/google/lmctfy at least, though. Edit: did publish

You realize that the first line of the README says that this project is obsolete and they stopped developing it?

The line before that says they working on taking those learnings into libcontainer.

Re: Why Databases Are Not for Docker Containers

#149

Post by carterehsmith »

mstump wrote: post #36
user5994461 wrote: post #31

Earlier quoted context omitted.

There is no tech in the universe that can cope with cascading failures, like ALL instances of a docker container crashing on ALL hosts one by one in quick succession. This usually happen because an app hits an unexpected bug in the docker disk or the docker network stack and this is the major source of concerns I have with Docker.

Some systems cope with failure better than others. Everything you've said is also true of DB running on top of a uniform linux stack. From my experience (500+ large scale production deployments) this doesn't happen very often. Does it solve all problems? No. Does it make the world a little better and is it better than monolithic single points of failure? Yes.

>> 500+ large scale production deployments

This needs to be qualified....

Did you deploy a single system 500 times, or 500 different systems? Or some combination thereof.

Re: Why Databases Are Not for Docker Containers

#150

Post by gourao »

lobster_johnson wrote: post #118
gourao wrote: post #77

Docker is a packaging tool. How you chose to deploy your software package has nothing to do with your operational and DB administration procedures. Mixing the two topics is very confusing.

Well, it's both. It's both packaging and deployment. Which is convenient, but probably a mistake. Docker is decent at being a packager, but rather terrible at deploying stuff, which is why we have better, high-level orchestration systems like Kubernetes that handle deployment the way it should be done, and reduce the Docker runtime to a mere container runner.

That is a fair point, and most of the end users we work with are using k8s and mesos to deploy and run the applications. The issue I have with the article is that it assumes that a packaging tool is what defines the rest of your operational procedures. They are two different things, as they always have been in Linux.
Post reply on HN