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

111–120 of 184 posts

Re: Why Databases Are Not for Docker Containers

#111

Post by alsadi »

Since you mentioned union fs then you are not using upstream kernel, most likely you are blaming your non-enterprise distribution choices on containers technology.

Fact #1 redhat do have enterprise docker container based solutions. Check project atomic and openshift

Fact #2 cloud providers like google, azure and amazon do have container basef solutions

Fact #3 coreos do have production grade docker based solutions

Fact #4 kubernetes do support pet pods aka stateful pods and can get data volume from reliable ebs or ceph

Re: Why Databases Are Not for Docker Containers

#112

Post by hyperknot »

memracom wrote: post #110
hyperknot wrote: post #107

Why is running a DB in Docker so different from running in an OpenVZ VPS? There are millions of Wordpress websites and other PHP CMS-es hosted in OpenVZ VPS-es, running MySQL reliably. Also, Discourse.org's default setup is PostgreSQL hosted in a Docker container, it also has probably 1-10 thousand live forums and is a reliable platform.

Because OpenVZ has a philosophy of the container as a simple VM running many processes just like a server does, but Docker is being developed as a container which runs one process which only communicated with other processes through defined interfaces which you configure when you create the container. Docker makes it easier to scale up and down, and to move stuff bewteen servers, but you need to do more work up front…

You can use Docker as a VM. Discourse is doing so, and Baseimage Docker is the #1 unofficial image on Docker Hub, so it means a lot of people believe it makes sense to use Docker like this.

Re: Why Databases Are Not for Docker Containers

#113

Post by electrum »

alexnewman wrote: post #81
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…

Yeah volumes skip unionfs. This article is full of FUD. The author demonstrates they don't really have enough experience to make these claims. I wonder if google has database nodes in containers? Kubernetes is adding the features for containers now. I think it is stable now.

Amazon has fully managed database containers: https://aws.amazon.com/rds/

Re: Why Databases Are Not for Docker Containers

#114

Post by user5994461 »

subway wrote: post #101
guardiangod wrote: post #96

Earlier quoted context omitted.

Leaving aside there's now yet another abstraction layer to have bugs, it is not a straw-man to imply that current container technology is not as reliable as bare metal. Or do you mean that Docker etc. are as reliable as bare metal? Heck, you can go on Docker's webpage ( https://www.docker.com/what-docker ). Notice that while they make the claims that Docker is- 1. More lightweight 2. 'Open'/run anywhere 3. Secure The…

At no time was the claim made that containers were more reliable than any other method of running a process, only that running a process within a container is not inherently less reliable than un-contained. Unless you've gone out of your way, Docker (as well as other Linux container systems) are just namespacing your process. There's no extra abstraction layer, it's just a more restricted execution environment.

FYI: The networks and the disks are entirely abstracted, with multiple extremely complex abstraction layers.

Re: Why Databases Are Not for Docker Containers

#115

Post by user5994461 »

subway wrote: post #78
guardiangod wrote: post #66

Earlier quoted context omitted.

Are you telling me that you'd trust MySQL auto replication failover enough to have it activates multiple times per day (even with Percona)? On a busy cluster with, say, 300GB?

Seems like a straw-man. Why is a process running within a container failing over more frequently than a process running directly on bare metal -- seems like more of a resource/process scheduling issue than anything to do with containers.

> Why is a process running within a container failing over more frequently than a process running directly on bare metal

Because the way to change anything in a container is to kill it and restart it. That's a fundamental difference compared to managing/maintaining a database not in a container.

Re: Why Databases Are Not for Docker Containers

#116

Post by lobster_johnson »

raarts wrote: post #43

Alright, all you brave people who run databases in docker: where do you store the actual data? - Host mounts? So what happens when a container gets rescheduled to another node? - Docker volumes? What happens when a container gets rescheduled to another node? - External SAN? Congratulations on your budget. That's not easily doable in public cloud I guess? - Shared filesystem like NFS, or Ceph? How's the performance fo…

Kubernetes lets you do whatever you want. For example, if you tell it to mount an AWS EBS volume into the container, if the container is rescheduled on another host, the volume will be automatically remounted there.

Kubernetes supports a whole range of volume types that all travel with the container, fully managed. You can even ask it to carve out pieces from a larger volume, so you don't have to create one volume per container.

You can pin containers to individual hosts and use host volumes, but of course that rather defeats the purpose of using containers in the first place.

Re: Why Databases Are Not for Docker Containers

#117

Post by eeZah7Ux »

tinco wrote: post #21
Bombthecat wrote: post #14

Earlier quoted context omitted.

Wow, three years ago? Balls of steel!

People make it seem as if Docker is some bleeding edge magical technology, but in reality its most useful features are just thin wrappers around stable linux kernel features and some nice automation. We have also been running databases in Docker (on the tb scale though) for around 3 years, we had the odd issue here and there, but nothing terrible and certainly nothing fundamental or resulting in data loss. If your da…

> People make it seem as if Docker is some bleeding edge magical technology, but in reality its most useful features are just thin wrappers around stable linux kernel features and some nice automation.

That's one of the things to dislike. The company and the community are trying to sell it as the best thing since sliced bread and usually forget to assign merit to the kernel developers.

On top of that, its 180k lines of code are unwarranted for a "thin" layer.

Re: Why Databases Are Not for Docker Containers

#118

Post by lobster_johnson »

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.

Re: Why Databases Are Not for Docker Containers

#119

Post by throwawayish »

subway wrote: post #101
guardiangod wrote: post #96

Earlier quoted context omitted.

Leaving aside there's now yet another abstraction layer to have bugs, it is not a straw-man to imply that current container technology is not as reliable as bare metal. Or do you mean that Docker etc. are as reliable as bare metal? Heck, you can go on Docker's webpage ( https://www.docker.com/what-docker ). Notice that while they make the claims that Docker is- 1. More lightweight 2. 'Open'/run anywhere 3. Secure The…

At no time was the claim made that containers were more reliable than any other method of running a process, only that running a process within a container is not inherently less reliable than un-contained. Unless you've gone out of your way, Docker (as well as other Linux container systems) are just namespacing your process. There's no extra abstraction layer, it's just a more restricted execution environment.

The numerous performance and stability issues (not just in the containers, but also affecting the main cgroup / "host" rather badly) I had with Docker, but never with LXC, which, according to you would be pretty much the same thing - "just namespacing your process". But it isn't.

Docker is ok when it works, hell when it doesn't, has lots of bugs and regularly regresses. I don't understand why you'd run production infrastructure on that and not on any of the alternatives.

Re: Why Databases Are Not for Docker Containers

#120

Post by subway »

user5994461 wrote: post #115
subway wrote: post #78

Earlier quoted context omitted.

Seems like a straw-man. Why is a process running within a container failing over more frequently than a process running directly on bare metal -- seems like more of a resource/process scheduling issue than anything to do with containers.

> Why is a process running within a container failing over more frequently than a process running directly on bare metal Because the way to change anything in a container is to kill it and restart it. That's a fundamental difference compared to managing/maintaining a database not in a container.

Unless you've written very poorly behaving software, you kill it by sending it a SIGTERM, and waiting for it to exit. This is true of software both within and outside of containers.

The fact `docker kill` defaults to using SIGKILL instead of SIGTERM is unfortunate, and something one should be aware of before deploying a process with docker, but again, this does not make the process running within the container inherently less reliable.

edit: Looks like `docker stop` does the right-ish thing -- sends a SIGTERM, then only resorts to SIGKILL after a timeout has expired.

Post reply on HN