Why can't you run a db server on a container?

Containers are designed to be non-persistent - if an instance of a container goes down you should be able to replace it with another instance with no loss in state. Most people want their databases to be persistent (unless it's just temporary local storage for your process), so containers are a bad idea here. What you want is some sort of external storage to store state. This also enables better horizontal scaling.

I would say this might be a description of Docker or Docker containers specifically, but does not characterize Linux containers generally.

Linux container technology, by which I mean the Linux kernel APIs used by Kubernetes, CoreOS rkt, and Docker, do not have an opinion about whether the processes that run as containers are ephemeral or persistent. Containers can be just as persistent as the host they're running on.

For example, consider a Linux distribution using systemd. Systemd might launch regular processes upon system startup, and it might also launch containers where both types of processes are equally persistent on the parent host. See the documentation for systemd-nspawn [1] and machinectl [2]. The Arch Linux wiki has more details about how to use that distribution with nspawn [3]. Containers managed in this way are just like other system processes aside from being containerized.

[1] https://www.freedesktop.org/software/systemd/man/systemd-nsp...

[2] https://www.freedesktop.org/software/systemd/man/machinectl....

[3] https://wiki.archlinux.org/index.php/Systemd-nspawn

Docker allows you to specify mounting directories on the host system. If you wish to have persistence of the data - it's simply the matter of specifying that mounting option.

Sure, but that's not a database running in Docker, it's "external storage to store state". Which is the right way of doing things if you're ok with your data persisting on the server.

I'm more curious, why would you run a DB in a container?

Containers seem really great for running inside schedulers in order to squeeze every last bit of performance out your servers while also making it easy to move things around as needed. To me this is things like app servers, web servers, load balancers, queue workers, microservices, etc.

I don't think of a database needing to be moved around, and I want its performance profile to have room for growth when needed (in other words, give me the beefiest server and only run the DB on it). Also, a database doesn't generally have 15 dependencies you have to hand compile/install like many apps do.

There seems to be a lot of operational complexity with doing things like "ok, here's our database, but the data is not in the container, and if the DB does move, we have to take the data with it." How long does the move take? Wouldn't it be better to just have another DB standing by to swap in immediately?

I guess my point is (and I'm actually, genuinely asking as someone who hasn't spent much time in the container world): what operational benefit does having a DB in a container give?

> I'm more curious, why would you run a DB in a container?

I develop different PHP apps - some are, uh, fossilized and don't work with MySQL 5.7 or later, some are on a more modern stack and can work with the latest and greatest stuff. Other apps I am working on run on pgsql. Also, I am on OS X.

All of this means it's either a Vagrant VM which I always forget to shut down and breaks every couple of months instead of Docker where I can do a simple docker ps -aq|xargs docker stop, and everything is pretty much reproducible.

And no, running the DBs native on OS X is a pure PITA - good luck getting different versions of MySQL and PHP to peacefully coexist.

On production servers the story is different but I can tailor a production server environment to the exact specs the software requires.

If getting the software you need to actually run is painful enough that you just run linux in a vm with a wrapper how is that easier than running linux in a vm or just run linux natively?

It's not painful by itself - the problem is having to run wildly different environments all at once.