3 ms·

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 perfo

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?

mschuster91 9y ago
> 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.
- michaelmrose 9y ago
  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?
  - mschuster91 9y ago
    It's not painful by itself - the problem is having to run wildly different environments all at once.

mschuster91 9y ago

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

michaelmrose 9y ago
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?
- mschuster91 9y ago
  It's not painful by itself - the problem is having to run wildly different environments all at once.