[mdk754]

> We might not want to run our production database in Docker (perhaps we'll just use Amazon RDS for example), but we can spin up a clean MySQL database in no time as a Docker container for development - leaving our development machine clean and keeping everything we do controlled and repeatable.

Curious why you wouldn't want to run it in docker in production? Wouldn't running the same container in dev/prod be helpful?

[yacn]

AFAIK (last I looked into this was ~6ish months ago), scaling databases in docker containers is a hard problem that currently doesn't have a clean solution. Vitess[0] is a solution, but it didn't seem quite ready for production last I looked at it.

[0] http://vitess.io/

[Veratyr]

From the Vitess overview page: "Vitess has been serving all YouTube database traffic since 2011".

Given that, it seems production ready.

[tayo42]

What is there to gain by putting your database in a container? A database probably has its own dedicated server so, your probably not deploying databases often and there's the added complexity of making your data persistent.

[mdk754]

Your point stands, and obviously makes more sense.

My curiosity was more in whether there were performance (or other) bottlenecks which made it technically infeasible.

[imaginology]

I run my production database in a container, even if it has its own dedicated server. It's nice being able to install, start and initialize the database with a simple docker command or two to get a consistent build, instead of manually setting it up (copying/editing configuration files, deploying schemas, initializing data, setting permissions, etc.) And it makes upgrading the database very easy. Having this process automated and in source control is great. I also have the awesome ability to bundle cron in my database container to schedule regular backups. Persisting data is as simple as mounting a data volume.