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

121–130 of 184 posts

Re: Why Databases Are Not for Docker Containers

#121

Post by throwawayish »

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…

Unix has process groups.

Unix has access control (ie. memory protection, FS access protection, FS root aka chroot).

Containers are process groups with access control.

The actual entity has a different name pretty much everywhere, eg. Solaris Zone, Linux namespace and Linux cgroups. Usually the OS throws in a wider bunch of stuff that is only loosely related to access control in the classic sense, eg. CPU and memory limiting, I/O rate limiting and such (so rusage access control, in a sense).

Re: Why Databases Are Not for Docker Containers

#122

Post by Kudos »

user5994461 wrote: post #39
fabian2k wrote: post #4

This article mentions offhand that the storage drivers are unreliable, even for data volumes. Is that actually the case? Is there a serious risk that a database will be corrupted by a container crash, as the article claims? A regular crash of the computer should not be able to corrupt a database, is a container more dangerous in this regard?

You'll want to read this, the links at the end and the comments: https://thehftguy.com/2016/11/01/docker-in-production-an-his... There are major issues registered with AUFS, Overlay, Overlay2 and BTRFS. It's ridiculous.

But if you're bind mounting the data dir to the host you're not using any docker FS driver.

Re: Why Databases Are Not for Docker Containers

#123

Post by audleman »

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…

> 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 other "servers" I have running.

SaltStack, Ansible, Chef are all configuration management tools that serve this purpose. They let you configure a standalone box any way you want.

The only use case I see for Docker over one of them is if you want to run multiple, independent services on one server. But why would you want to do that when you're running in the cloud? I don't see the benefit over separate instances, each tailored to be the exact size you need.

Re: Why Databases Are Not for Docker Containers

#124

Post by donarb »

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…

One use that I love is pre-packaged containers. I'm designing a system for a client that does headless web automation. I spent a couple of weeks trying to get various separate versions of selenium/Firefox/Chrome running along with Xvfb without much luck. The selenium project has fully tested and functioning container images that work every time.

Re: Why Databases Are Not for Docker Containers

#125

Post by state_less »

brianwawok wrote: post #109
state_less wrote: post #87

Earlier quoted context omitted.

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.

> I've run Oracle in a container Danger, danger https://www.theregister.co.uk/2016/02/24/oracle_vmware_licen...

Relax, nothing is fucked here dude...

https://blogs.oracle.com/developer/entry/creating_and_oracle...

https://github.com/oracle/docker-images/tree/master/OracleDa...

Re: Why Databases Are Not for Docker Containers

#126

Post by jcahill84 »

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…

Didn't mean you Bombthecat :-) I was referring the article.

Re: Why Databases Are Not for Docker Containers

#127

Post by gjkood »

In the ancient times of databases we had to make sure that we wrote to 'raw' disk devices bypassing any possibility of the operating system file caching/buffering failing to 'flush' our writes all the way to the disk. There was an implied guarantee that what we thought we wrote was actually written to disk.

In today's world of 'virtual' everything which may sometimes be many levels removed from the raw disk devices, how do we still ensure that a write to a database is still a write to a physical device as opposed to an incomplete write that looks like a completed write to a higher level virtual disk? Is there a guarantee that everything is flushed to a physical disk?

Re: Why Databases Are Not for Docker Containers

#128

Post by mondoshawan »

jdc0589 wrote: post #85
alexnewman wrote: post #81

Earlier quoted context omitted.

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.

Google runs MySQL on Borg internally.

Re: Why Databases Are Not for Docker Containers

#129

Post by kondro »

electrum wrote: post #113
alexnewman wrote: post #81

Earlier quoted context omitted.

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/

They aren't containers, these are VMs.

Re: Why Databases Are Not for Docker Containers

#130

Post by sqldba »

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…

This sounds right to me. As a DBA containers appear to be a nightmare. I'm employed as an absolute expert in my product. A developer may know how to use Docker but are they an expert? Now...

* Who is going to look after the middle ground when the database is in the container?

* Who is going to be responsible for rewriting enterprise tools to discover those instances to gather metrics? Because none of the traditional methods (WMI, registry keys, etc) are going to work. You've just broken SCCM, ServiceNow, and everything else under the sun.

* Who owns the patching? Because WSUS can't discover it and isn't going to be able to patch inside a container.

* Who owns the backups? You know backups are complicated right and not just an on/off switch? You have to schedule the backup, but also make sure you're scheduling the backups in a standard way across your hundreds of hosts (now containers), and then validate those backups are actually being taken, and test those backups regularly. Developers couldn't care less about this stuff - it's someone else's problem - my problem - until it's in a container and then nobody is going to do it.

* And when something breaks in between, and the business suffers a massive loss of data, who are they going to sue? A liability-free open source project? I don't think so.

There's more to being a DBA than just stuffing it in a container and saying, "she'll be right mate".

Post reply on HN