Why Databases Are Not for Docker Containers

the "stateless" bit precludes a whole bunch of use cases, for example databases as per the post. For me the issue with containers is that they don't feel very "contained" when you have files ("images") all over the shop that don't get eliminated easily, or when attached volumes have storage in some location, and compose files elsewhere, and having to inject all sorts of environment variables. In other words, files and details scattered around everywhere. It's not nearly as clean as a VM, even though I do get it that for scaling tons of identical web servers, for example, they would be great.

While it is true that Docker has a variety of storage drivers for the overlay file system, some unreliable, if you are doing DB then you'd be using a host volume mount which is a bind mount. There should be no issues with the bind mount as it is not a part of Docker.

If you limit your understanding of "containers" by not advancing past single-page tutorials produced by content marketing folks at orchestration startups, you may _feel_ like the author is right. But as it almost always the case with damn computers and generalized topics, there's no right or wrong. The world is boring and full of "it depends" but that was conveniently left out of the article because the goal, I suspect, was to back a sensationalist title and produce clicks/views. But I'll bite:

> 1. Data insecurity

The author is mixing up Docker image store with database's own data. It is true that Docker graph drivers have issues, but they don't store any data, those are binaries you distribute and you're welcome to start docker containers from a plain old directory on disk. Layers are sexy but optional and they have nothing to do with your database data.

> 2. Specific resource requirements

The author talks about running additional processes on a database machine. Why is this an argument against containers? Maybe because containers make it somehow easier? I dunno... Yeah, don't overload your database servers with other stuff, containers aren't forcing you to do it.

> 3. Network problems

This one is the most bizarre, with statements from all over the map, basically saying "networks are hard". Riding unicycles is also hard, but that's not used as an argument against containers. Here's an obvious conclusion: if you don't feel like learning software-defined networks (or don't need the benefits they provide), then don't use them and run containers with native host networking.

> 4. State in computing environment

This port is just rambling, I do not see anything specific to reply to. If the point to make was that containers don't play nice with state, it's like saying "processes do not play nice with state" because that's what a container is: a Linux process. You have full control over where (pin it to DB machines only) and how it runs, use features you need (and understand) and don't use others.

> 5. They just don’t fit major Docker features

In this part the author is basically saying that it's easy (or easier) to install a database using configuration management tools instead of using something like Docker. True, there is more than one way to skin a cat and frankly you can use both a configuration management system and the containers. I just can't see how this can be used as an argument AGAINST anything.

> 6. Extra isolation is critical at the database layer

The author again claims the containers bring in significant overhead. That's simply not true. I would recommend to mentally replacing "container" with "process" when you read the orchestration blogs to see right through FUD. Again, you can run a container from a directory on your filesystem using host networking and it will be no different from any other process on the box. Using a network namespace does not add any measurable difference to performance. [1]

> 7. Cloud platform incompatibility

The title doesn't match the paragraph of the text that follows. The author basically claims that being provider-agnostic (one of the benefits of containers) is not valuable. Well, he's a database administrator and it's not valuable to _him_. But there's a huge business value of being able to run on different infrastructures: selling $100/mo SaaS subscriptions is nice, but when the stream of early adopters dries up and you set your aim at those nice six-figure enterprise license contracts, you may find out that you will need to be able to run on a VMware cluster in a corporate colo. And containers can help.

Containers are big not because they make developers happy, they're big because they let sophisticated companies significantly consolidate their workloads (via dynamic scheduling) and shrink their infrastructure footprints. I constantly get shocked by AWS bills people share with me and something like Kubernetes provide quite significant material value of shrinking them. But another less obvious advantage is the ability to run [1] the same SaaS stack on public and private infrastructure, opening up entirely new markets for your company. What's your revenue from China? Ever thought about containers being the perfect tool to penetrate The Firewall and run on your Chinese customer's servers? Anyway, those are good reasons to finally learn and use containers. And the reason not to? Well, not this blog post.

[1] We are https://gravitational.com and some of our customers ARE database vendors, happily running their mission critical (everyone is mission critical in our biz) workloads on containers / Kubernetes and deploying them into behind-firewall corporate clouds. So yes I am biased but I'm also qualified to respond.

I'd argue that the stateless bit is more of a Docker idiom than something intrinsic to containers. LXC/LXD, for example, treats containers as machines instead of processes.

I am still on the journey to wholesale container acceptance, but I have been finding more and more use-cases that are delightfully solved by them. My favorite so far is a WordPress hosting platform with some shared infrastructure (web server, caching reverse proxy, and database) but each PHP-FPM instance jailed in its own container. This lets me:

* easily chroot PHP (this is surprisingly difficult otherwise)

* restrict MariaDB access by IP address

* constrain the resource consumption of each application as necessary (i.e. to prevent an out-of-control PHP script from swamping the box)

* independently determine each application's PHP version

And because each managed application is (basically) a Docker image and a Caddyfile, it's easily extensible to non-PHP things. I can feel the lightbulb flickering but I'm not yet at full k8s awareness. The shared infrastructure isn't containerized, but it could easily be, and it's all running on one VM, but it could be distributed across multiple.

Containers don't solve the common problems, they just give you more tools to work with. With databases, for example, you still need to figure out whether each application gets its own database instance? schema? user?, a replication strategy, a failover strategy, a backup strategy, etc. You can use either a bind-mounted host directory or a shared-storage volume for the backing store, just like always, or a newfangled data volume container.

I am more comfortable sharing a database instance between multiple schemas and users because I can do IP-specific grants, but if I wanted to do one per application, I could do that too!