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

81–90 of 184 posts

Re: Why Databases Are Not for Docker Containers

#81

Post by alexnewman »

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.

Re: Why Databases Are Not for Docker Containers

#82

Post by k2xl »

Bombthecat wrote: post #57
jcahill84 wrote: post #41

Earlier quoted context omitted.

This is one of the biggest problems with people hating on docker... They don't understand what it is and actually does. Great comment!

Oh hell no, not hating docker! I love docker ( I'm the multiplier in my company and teaching docker,and doing presentations) But putting pb of data in docker three years ago is just insane. There are still things not clear right now,which are not stable ( not in unstable destroying data) but unstable in: if something goes wrong with your data you need to dig deep and find out what's going on. If stuff changes every f…

The data wasn't petabytes 3 years ago, it grew to that amount over time.

But with that said, if you have replication and operational workflows set up, you minimize the chance of issues.

If you have mission critical data, you should set up your database to handle failovers of any type, let alone docker.

Re: Why Databases Are Not for Docker Containers

#83

Post by [deleted] »

Bombthecat wrote: post #57
jcahill84 wrote: post #41

Earlier quoted context omitted.

This is one of the biggest problems with people hating on docker... They don't understand what it is and actually does. Great comment!

Oh hell no, not hating docker! I love docker ( I'm the multiplier in my company and teaching docker,and doing presentations) But putting pb of data in docker three years ago is just insane. There are still things not clear right now,which are not stable ( not in unstable destroying data) but unstable in: if something goes wrong with your data you need to dig deep and find out what's going on. If stuff changes every f…

[deleted]

Re: Why Databases Are Not for Docker Containers

#84

Post by twic »

NikolaeVarius wrote: post #19
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…

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.

We tend to use containers and VMs for similar purposes, but i think this the wrong way to explain what they actually are.

A container is like a much thicker-skinned process.

You know how when you run a program as a process, it can't read other processes' memory, and you can control how much CPU it uses with renice, and it can have anonymous files that no other process can read, and you can specifically kill it, and track its resource usage? Containers are like that but more so. With containers, programs can't even read each others' filesystems, and have completely separate network interfaces, and you can measure and control CPU usage for a whole tree of processes, not just one.

Containers are processes beefed up to the level where they compete with running a VM.

Re: Why Databases Are Not for Docker Containers

#85

Post by jdc0589 »

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.

> I wonder if google has database nodes in containers?

I've been wondering this for a while. I'm sure some of the big players do it, but I'd really like to see a case study from one of them.

Re: Why Databases Are Not for Docker Containers

#86

Post by user5994461 »

gkop wrote: post #74
user5994461 wrote: post #44

Earlier quoted context omitted.

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.

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?

Re: Why Databases Are Not for Docker Containers

#87

Post by state_less »

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…

I've run Oracle in a container, ugh what a pig, though it can be done. It's great for development, since you can checkpoint state, pass it around and have 99 containers of bugs on the ground.

At the end of the day, the data and database is run on some production instance that runs on a fully bare hypervisor at TopGuy (TM) cloud provider. This is enough so that everyone feels more or less good about their situation.

Re: Why Databases Are Not for Docker Containers

#88

Post by [deleted] »

Spivak wrote: post #76
user5994461 wrote: post #61

Earlier quoted context omitted.

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?

The ops team that uses some form of config management that the developers never touch.

[deleted]

Re: Why Databases Are Not for Docker Containers

#89

Post by PaulKeeble »

dgfgfdagasdfgfa wrote: post #48
tracker1 wrote: post #38

Earlier quoted context omitted.

This is why I appreciate DBaaS offerings... It makes more sense to run DBs at least closer to the hardware, outside containers, but most developers don't want to be DBAs, so it's better to pay for someone that has all the maint/update scripts written, and not have to deal with many of those issues.

Sure, but then you have other issues with black box databases: 1. Lack of control over configuration and tuning of database. 2. Little control over semantic upgrades, i.e. security updates should be automatic, but one breaking compatibility should not be, but MAY be necessary or desired, so it needs to be possible to upgrade. 3. Failover isn't easy, and the way of handling it is often app- and load-specific. Granted,…

Actually they ought to matter to everyone, or rather at some point they do matter. Data is different, data has to be upgraded in place, its genuinely not immutable but this isn't also true of the software above it, Databases are software like any other and they should have a similar release cycle because if they don't its much harder to test and push updates.

Re: Why Databases Are Not for Docker Containers

#90

Post by justicezyx »

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…

IIRC think Kubernets support pinned deployment.

I.e., you can force scheduler to schedule running on fixed set of machines.

Post reply on HN