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

161–170 of 184 posts

Re: Why Databases Are Not for Docker Containers

#161

Post by brazzledazzle »

state_less wrote: post #125
brianwawok wrote: post #109

Earlier quoted context omitted.

> 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...

I'm going to have to agree with the other reply. One hand doesn't know what the other is doing and the team that does audits to prop up revenue isn't going to care about that blog post unless it has legal language in the license that allows you to bypass licensing restrictions. That said, there's free versions of Oracle's databases for development and they may have exceptions for development purposes so if that's what someone is using containers for it might not be the end of the world.

Re: Why Databases Are Not for Docker Containers

#162

Post by brazzledazzle »

subway wrote: post #120
user5994461 wrote: post #115

Earlier quoted context omitted.

> 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 inhere…

Also worth noting that the timeout is a configurable parameter with `docker stop`.

Re: Why Databases Are Not for Docker Containers

#163

Post by mstump »

carterehsmith wrote: post #149
mstump wrote: post #36

Earlier quoted context omitted.

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.

It's a mix. I'm a consultant that specializes in large scale distributed systems. I have some customers that have >100k production database nodes. I manage probably >50PB of data. I have designed large distributed systems for more than 100 customers.

Re: Why Databases Are Not for Docker Containers

#164

Post by derekperkins »

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.

YouTube runs MySQL on Borg too, and they open sourced their management solution. - http://vitess.io

Re: Why Databases Are Not for Docker Containers

#165

Post by kiallmacinnes »

sqldba wrote: post #130
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…

These are all valid concerns, but, none seem specific to databases and - for companies who have moved even parts of their infrastructure to containers - have been deemed acceptable.

(Also, while you mentioned all Microsoft tools here, the same issues apply to Linux based containers)

Re: Why Databases Are Not for Docker Containers

#166

Post by n3m8tz »

Hyper converged scale out object storage with docker engine on the same nodes could be your solution. Docker volumes support native NFS , rather stable IMO, there is no magic with docker volumes at all, your NAS, SAS, or distributed storage already implements all sorts of redundancy. And if you don't want to deal with anything just pay for DBaaS.

Re: Why Databases Are Not for Docker Containers

#167

Post by state_less »

brazzledazzle wrote: post #161
state_less wrote: post #125

Earlier quoted context omitted.

Relax, nothing is fucked here dude... https://blogs.oracle.com/developer/entry/creating_and_oracle... https://github.com/oracle/docker-images/tree/master/OracleDa...

I'm going to have to agree with the other reply. One hand doesn't know what the other is doing and the team that does audits to prop up revenue isn't going to care about that blog post unless it has legal language in the license that allows you to bypass licensing restrictions. That said, there's free versions of Oracle's databases for development and they may have exceptions for development purposes so if that's wha…

Yep, licensed Oracle instance for production and docker for developers. If you're the sort to run Oracle, the expectation is that you're going to be paying.

Re: Why Databases Are Not for Docker Containers

#168

Post by user5994461 »

mstump wrote: post #163
carterehsmith wrote: post #149

Earlier quoted context omitted.

>> 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.

It's a mix. I'm a consultant that specializes in large scale distributed systems. I have some customers that have >100k production database nodes. I manage probably >50PB of data. I have designed large distributed systems for more than 100 customers.

consultant = charge > £600 a day to bring Docker to the company. Yet doesn't care when shit hits the fan 3 months later because he's already gone. In fact, he will never known about it.

By the way, How to have 100 customers => leave right after the design phase every single time. Clients add up quickly.

Re: Why Databases Are Not for Docker Containers

#169

Post by user5994461 »

ec109685 wrote: post #141
user5994461 wrote: post #80

Earlier quoted context omitted.

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.

The hypervisor has processes inside the VMs. It has limited control but it is far from blind.

Re: Why Databases Are Not for Docker Containers

#170

Post by user5994461 »

ec109685 wrote: post #147
user5994461 wrote: post #86

Earlier quoted context omitted.

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.

Meaning it's not done, it's work in progress, that will take a while.
Post reply on HN