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

61–70 of 184 posts

Re: Why Databases Are Not for Docker Containers

#61

Post by user5994461 »

derefr wrote: post #25

> But what about Configuration Management systems? They’re designed to solve this kind of routine by running one command. The problem with this for most of the developers you see praising containers, is that with a containerized setup, you've already got the rest of your deployment process down to `docker service update --image myorg/myservice:1.3.0 myservice` (And, in fact, maybe you're even running that code agains…

And what's gonna install CoreOS? And what's gonna install Docker? And what's gonna configure Docker? And what's gonna give a configuration to run the Docker image and how?

Re: Why Databases Are Not for Docker Containers

#62

Post by SFJulie »

metaphorm wrote: post #37
NikolaeVarius wrote: post #19

Earlier quoted context omitted.

There is nothing special about containers to really understand Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. You can run multiple containers on a single VM in the same way you can run multiple VMs on a single host. Ideally a container should be stateless. If a container crashes, you should be able to bring it up again without anything actually caring that it is technically a…

> Containers are a lightweight way of sandboxing a process. Think a level lower than a VM. can you go into a little more depth? my understanding of a VM is that it installs the OS in a dedicated memory partition, and allocates hardware resources separately from that of the host machine, such that resource contention between host and VM never happens. the VM allocated resources just go dark for the host machine while…

old way: one chroot per user and quota (including ulimit) per user

new way: limits handled with cgroups security with namespace related to user's profile.

namespace can do syscall limitations, and also offer unique network access per users.

Roughly simplified.

freebsd jails where known as glass jails that would eventually break, LXC/docker are the same except they hav'nt broke yet at the price of more complexity. They will all dramatically break when people will have figured the trick in 5 years.

Simple solution : understand the problem and fix it.

Actual solution: throw more complexity and obfuscation at the problem claiming users are THE problem.

Companies and devops don't care, they have a future of at least 10 years in fat paychecks and stock options.

Re: Why Databases Are Not for Docker Containers

#63

Post by user5994461 »

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.

Some systems fail more often than others.

Re: Why Databases Are Not for Docker Containers

#64

Post by general_ai »

ender7 wrote: post #17

I still can't really figure out what a container is. Every time I think of a use case for one, I read something like this which says that's a terrible idea. The use-case I need solved most often is the following: Create a standalone "server" that accepts and responds to network traffic, has some way to store data, and whose dependencies (i.e. system packages, frameworks, etc) I can manage independently of any of the…

You're thinking about it incorrectly. Docker is not a VM. Docker is more like a chroot and a set of additional capability restrictions on top. Basically there are several things that are namespaced in Linux. Processes, network, users, IPC, mount, etc. Docker simply manages these namespaces. At a high level, when you fire up a container, a namespace gets created for it. So unless you explicitly tell Docker to expose things from the host, there's only a very limited set of things your container will see. Crucially, everything uses the same kernel, same drivers, etc, and there's zero overhead.

Think of your Linux host as simply a default namespace.

Re: Why Databases Are Not for Docker Containers

#65

Post by navaati »

user5994461 wrote: post #61
derefr wrote: post #25

> But what about Configuration Management systems? They’re designed to solve this kind of routine by running one command. The problem with this for most of the developers you see praising containers, is that with a containerized setup, you've already got the rest of your deployment process down to `docker service update --image myorg/myservice:1.3.0 myservice` (And, in fact, maybe you're even running that code agains…

And what's gonna install CoreOS? And what's gonna install Docker? And what's gonna configure Docker? And what's gonna give a configuration to run the Docker image and how?

Well, it's already done in a CoreOS image, why ?

Re: Why Databases Are Not for Docker Containers

#66

Post by guardiangod »

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…

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?

Re: Why Databases Are Not for Docker Containers

#67

Post by general_ai »

user5994461 wrote: post #44
outside1234 wrote: post #33

Of course the counter example of this is Google, which, as I understand it, runs everything on containers. It seems like if its good enough for Google, then its good enough for the rest of us.

Google runs NOTHING on Docker. They have their internal secret proprietary container technology. The concept of containers is fine. The troubles lies in the implementation that is available.

They don't use Docker outside Cloud, true, but their container technology is the same as what Docker uses: cgroups. Brought to you by a couple of Google dudes a decade ago.

Re: Why Databases Are Not for Docker Containers

#68

Post by nickbauman »

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…

I use Linux containers extensively. They can be rolled over by the container orchestration service at any time so I do not use them for databases except in a dev cluster where we trash and reload test decks constantly.

Re: Why Databases Are Not for Docker Containers

#69

Post by jazoom »

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…

Mount a volume on the host and make sure only one database container runs on that host. Done.

Then it's exactly like a traditional setup except better because if the process crashes or config gets corrupted it can be replaced automatically in a few seconds, good as new.

There's nothing brave about that.

Re: Why Databases Are Not for Docker Containers

#70

Post by XorNot »

eicnix wrote: post #56
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…

Hi XorNot, did you publish your findings anywhere?

Sadly no (and I'd have to clear it with my employer). We're going to be doing some much larger scale testing in the next few months (going from 4-5 nodes to 18) in preparation for the docker rollout on said cluster.
Post reply on HN