which is better running multiple container with mysql in it or running single container of mysql and connecting other containers to that? reddit / selfhosted ---------------------------------------------------------------------- sennje · 2023-10-05 19:46 Hi, I am learning docker and was trying to containerize mysql for personal project. I have multiple sites running in docker containers. This are completely different sites and does not depend on each other in any way. As this are small sites they all are running on single DO droplet. Which would be better? Case 1 : Running multiple containers with each one having their own mysql. (in same container) OR Case 2 : Running single mysql container and connecting other sites container to that.? ---------------------------------------------------------------------- arvigeus · 2023-10-05 19:54 Case 2 is a big hassle to support, especially if you want to try things out ---------------------------------------------------------------------- kongu123 · 2023-10-05 20:05 Case 2 would likely cause lots of problems, since you'd have multiple containers playing around in the same database. One of the big benefits of docker is segregating all of your processes. You lose some of that if they can all interact through one database. ---------------------------------------------------------------------- pyrodorobo · 2023-10-05 20:10 Case 2 only makes sense for services that need to access the same data in mysql. And the benefit would be less storage used. But like others mentioned, you lose the compartmentalization that is one of the main benefits to containers. Container A and container B both need that mysql container up to function, so if container C is testing stuff out and brings it down, A and B also come down. ---------------------------------------------------------------------- phein4242 · 2023-10-05 20:27 Case 2 will consume less resources then case 1, and because of that case 2 is preferred depending on how many apps you run. It will mean that you would need to do additional condiguration per app you run. ---------------------------------------------------------------------- PaulEngineer-89 · 2023-10-05 20:35 See this is what I was thinking but now I disagree. The first reason and answers another post is each app will have its own database unless like you said it’s a stack in which case they all share anyway. So the memory/space footprint is really the same minus a tiny bit of overhead because each app shares nothing. Performance wise databases tend to consume CPU only when they are processing queries or running something like a maintenance function. The rest of the time they do very little. So between queries there is little activity. This low level activity is your only CPU overhead to try to capture. ---------------------------------------------------------------------- thekrautboy · 2023-10-05 20:36 This has been asked so many times already... ---------------------------------------------------------------------- thekrautboy · 2023-10-05 20:38 Case 2 is preferred? Maybe for yourself. But definitely not the best practice. ---------------------------------------------------------------------- SeaNefariousness4835 · 2023-10-05 22:11 How about case 3? Build docker compose files that build separate containers for app and database. One compose file per service (2 containers) ---------------------------------------------------------------------- thekrautboy · 2023-10-05 22:17 Isnt that case 1? ---------------------------------------------------------------------- SeaNefariousness4835 · 2023-10-05 22:25 No case on was everything in a single container... at least that was how I read it. Unless it meant a single compose file then yes it would be... but single container to me means everything in on the app and the SQL database as if it were a VM. ---------------------------------------------------------------------- thekrautboy · 2023-10-05 22:27 Thats not how i understand the OP. Sure, it could be phrased better. ---------------------------------------------------------------------- dhalem · 2023-10-05 22:35 Another downside of option 2 I haven’t seen mentioned is that by sharing a MySQL instance, you lose any query isolation. A long running query from one application can clog up another in ways that can be difficult to trace. ---------------------------------------------------------------------- selfguest · 2023-10-06 00:32 One argument in favor of Case 2: Only one instance to backup or restore. But if you don't have a good backup and that central instance were to crash... ---------------------------------------------------------------------- Majestic-Contract-42 · 2023-10-06 00:52 Is there a use case where Case 2 would ever be desired / make sense? Keep separate stuff separate. ---------------------------------------------------------------------- talent_deprived · 2023-10-06 01:15 Case 2 is the only way I've seen it done in several enterprises doing microservices, it's the only way I do it for my own humble selfhosted services I wrote and I run, and it is the only sane way to accomplish data joins. Joining data, for relational databases, is among the most common things to do. ---------------------------------------------------------------------- ithilelda · 2023-10-06 01:54 homelab wise, there wouldn't be much difference except that: - case1 is easier to maintain because usually docker compose files are used in homelab settings. You have a clear cut concern. - case2 is easier to backup. which one is more suitable depends on your needs. Do your apps' data matter and you want to setup an easy backup? or are you pulling up and down composed apps frequently to test them, so you need to separate them for easier maintenance? enterprise wise, its almost entirely a modified version of case2. They have dedicated storage clusters for horizontal scaling and high availability, but I wouldn't say that you'll ever need it... ---------------------------------------------------------------------- NotTryingToConYou · 2023-10-06 03:04 Yeah but its still the same amount of data either way. At least if its segmented, one single application can't ruin the whole database and let the other applications keep running. And if that does happen, you only have to replace that 1 db which will be quicker than doing all of it. ---------------------------------------------------------------------- NotTryingToConYou · 2023-10-06 03:07 Can you share more about which enterprises have one monolithic database? I was a swe at AWS and can guarantee they dont it that way. My current, smaller company in a similar space has segmented databases, too. They might live together in the data plane cluster, but they are separated because you dont a different teams fuck up bringing down your service. ---------------------------------------------------------------------- talent_deprived · 2023-10-06 03:56 AWS, GCP and Azure do not do things like the majority of enterprises. \> They might live together in the data plane cluster Yup, agreed. I've seen around a 10/1 ratio of microservices to database instances/clusters (in various configurations). My point was, an enterprise with 10K microservices isn't going to have 10K database instances in a 1/1 config. ---------------------------------------------------------------------- CeeMX · 2023-10-06 04:44 Or just spin up a non dockerized db server for all services to access. Maybe even go with the managed on from DO ---------------------------------------------------------------------- Bonsailinse · 2023-10-06 05:28 One service per container is a fundamental design when working with docker and you should not change that for any of the scenarios Op mentioned. ---------------------------------------------------------------------- NobodyRulesPenguins · 2023-10-06 05:47 Depends, if you go by the name they are DBMS. And are build to manage efficently multiples databases. Now with docker being more and more popular, they seem tend for single database management system now. Not sure if there is a right answer since things have evolved so much, but case 2 was the intended way initially. ---------------------------------------------------------------------- ZarehD · 2023-10-06 06:34 Case 1: * Positives * Isolation of app/db pairs from each other * Maintenance/patching on one db doesn't affect other apps * Easy to migrate an app/db pair to another droplet to handle higher load * Negatives * Higher resources (cpu, ram per db) & less efficient use of resources (idle app wastes db resources, while db for another could use more resources) * Increased patching & maintenance time/effort * HA config, patching, maintenance for cluster per app/db pair Case 2: * Positives * Sharing DB resources (cpu, ram) is more efficient (smooths out load peaks/valleys across apps) * Reduced patching & maintenance time/effort * HA config, patching, maintenance for one cluster * Easier to migrate DB (& replicas) to separate droplet(s) to handle increased load * Negatives * Maintenance/patching for db affects all apps In balance, I would opt for case 2 b/c it's a much more efficient use of resources, it reduces maintenance costs, and it allows for sharing an HA implementation, if/when you need it (very likely you will). Add to that the fact that migrating the db (cluster) to separate droplet(s) to handle increased load benefits all the apps, and does so more efficiently. ---------------------------------------------------------------------- gaggina · 2023-10-06 07:21 I usually make a docker-compose file with the app it's self and a database. In this way every app/site has it's own database. I don't know if it's the proper way of doing it. I've always done this way in my projects. I think it's more secure btw. If you're app/site get hacked you do not expose all your data ---------------------------------------------------------------------- sennje · 2023-10-06 10:02 when resources are less. I have single 4GB DO droplet. Mysql consumes like 300-500MB of ram. If I want to run 4 apps on single server and have 1GB of ram dedicated for each container. Around half of ram might be utilize with mysql. ---------------------------------------------------------------------- phein4242 · 2023-10-06 10:29 The more processes you run on a box, the more context switches the box does. Context switches are expensive, resource wise, and these are wasted resources, especially on something like a pi. Note that the easy way is case 1. Case 2 requires more work on the DB to get it right. ---------------------------------------------------------------------- phein4242 · 2023-10-06 10:31 You are right for machines that idle. For machines that run actual workload, you are wasting resources on context switching and scheduling. ---------------------------------------------------------------------- thekrautboy · 2023-10-06 10:42 While technically correct, i still disagree. People here are not running datacenters. Its selfhosting and homelabs. The differences in CPU overhead become meaningless and the advantages in having separate db containers are far better for casual users. Youre also assuming that every project is compatible with a single version of a db, when in reality they often are not. ---------------------------------------------------------------------- phein4242 · 2023-10-06 10:54 In the netherlands, Ive built and operated this model with various top-tier platforms in the public transport, financial and ecommerce sectors. ---------------------------------------------------------------------- phein4242 · 2023-10-06 11:00 Yeah, thats fine. I dont assume anything, Im just here to share knowledge. I treat my home lab like how I treat my professionally managed environments. Do with it as you please. ---------------------------------------------------------------------- atheken · 2023-10-06 11:16 The docker model is generally _one process per container_. There are a few times when you need to break this, but in general, you're not gaining much by combining them in a single container, and you loose some nice features related to observability and management (like, upgrading the app at a different interval than the DB container). There's also minimal actual overhead to running a dedicated mysql container for each app, personally, I would do that to isolate each app from the others anyway. Also, if you're only hosting a single instance of an app, and it supports SQLite, use that instead, that's basically a zero-maintenance option. ---------------------------------------------------------------------- macrowe777 · 2023-10-06 12:00 There's billions of posts on the web. Not being dismissive, theres already plenty good answers here, but there's literally the greatest minds in this space having already written countless articles already about this. If you want "the" answer I'd highly recommend googling it. If googling it isn't worth it, it probably doesn't matter for you. ---------------------------------------------------------------------- krysinello · 2023-10-06 12:46 I just launch separate database containers per app. It's easier. Particularly when I'm assessing something having it all isolated, I can have a working config that I can just use without altering configs, I'm not version locked if I upgrade something that might not support a current big database etc. When you get to scalability and resources, while several database containers will have some overhead, the usage requirements for each app are also different, can be resourced less etc. You can often make up the overhead with proper sizing. Additionally some DB usages may be more olap based while others more transactional. Something needing small quick queries vs something that does large queries with high degrees of parallelism can impact both sides. IMO particularly for self hosting. Easy enough to just have a single docker compose that launches everything that is needed in a working state. As for your option 1. Never have a database in the same container. 1 container for 1 app. If it needs a database, have a separate database container. ---------------------------------------------------------------------- mincinashu · 2023-10-06 13:50 My production looks this: Several DBs, grouped by domain of concern, running in a single SQL instqnce/container. Usually accessed by a single service. Good, bad? Don't know, that's the setup. I wouldn't mix domains of concern inside one instance. ---------------------------------------------------------------------- Butthurtz23 · 2023-10-06 16:25 I would like to add that you should use a lightweight container such as MariaDB with Alpine Tag. ---------------------------------------------------------------------- FabianN · 2023-10-06 16:33 Counter argument on that point: if you're updating apps that also update the DB, if you're using case 2 you need to backup the app and the DB separately. With case 1 you can get the app and the DB with one backup. That's what caused me to switch from case 2 to case 1. I don't backup the DB separately, I just backup the entire container or vm, that gets me everything at once ---------------------------------------------------------------------- sennje · 2023-10-06 21:53 thanks ---------------------------------------------------------------------- ZarehD · 2023-10-06 22:04 y/w ---------------------------------------------------------------------- jstevewhite · 2023-10-06 22:32 In general if you're running them all in containers, there's little overhead cost to giving each app its own database. An idle maridb or postgres doesn't use much in the way of RAM or CPU; e.g. my guacamole postgres shows 0%, my pixelfed mysql shows 1%. ---------------------------------------------------------------------- jstevewhite · 2023-10-06 22:34 This. Combining different tools into the same container is generally frowned upon. :D ---------------------------------------------------------------------- hezden · 2023-10-06 23:42 When in doubt; microservices are best practice.