"Support" containers - centralized or separate per service?

Submitted ⁨⁨1⁩ ⁨year⁩ ago⁩ by ⁨AnAnxiousCorgi@lemmy.reddeth.com⁩ to ⁨selfhosted@lemmy.world⁩

Hello all! Just curious what y’alls typical setup is when it comes to running multiple stacks which require the same “support” containers.

What I mean is, say you want to run two services that both require a connection to a database, would you run two separate DB containers, one for each service and have them connected only to their respective DB “stacks”? Or do you prefer to run a single centralized DB server/service and have your self hosted stacks all communicate with their own databases inside the server?

source

Comments

Sort:hotnew top

morethanevil@lmy.mymte.de ⁨1⁩ ⁨year⁩ ago
One big DB will be a single point of failure. You will not benefit from much more speed, the only thing which is “easier” is backup.

I use different DBs for different stacks. If one hangs up or messed up completly, it won’t affect others

source
MaggiWuerze@feddit.de ⁨1⁩ ⁨year⁩ ago
I don’t wanna go all 90s forum user here, but I think this is the 5th post asking this. Maybe just have a look first if this has been answered already.

On topic: just use a new db with each service.

source
- vegetaaaaaaa@lemmy.world ⁨1⁩ ⁨year⁩ ago
  
  I think this is the 5th post asking this
  
  Agree, there are a few topics like this. Other ones being “backup software recommendation” threads, “look at my dashboard” threads, “what should I self-host” threads… I just post a comment linking to previous threads like this lemmy.world/comment/1761863. Maybe after a while they will learn… On the other hand Lemmy’s search feature is not very pleasant to work with, so I don’t blame OP. Maybe there should be a pinned post about “frequent” questions.
  
  On topic: single DB engine/service, connect each app to this DB service, and let each one have its own database in it. Anything else degrades performance and makes backups more complex.
  
  source
nickwitha_k@lemmy.sdf.org ⁨1⁩ ⁨year⁩ ago
My recommendation, if practical, is a single, potentially containerized DB server that is backed by storage that provides high availability and redundancy. This is supposing that you are using the same sort of DB (ex SQL, NoSQL, etc) and that you are targeting a smallish number of services that are on-premise.

My reasoning here is that you can treat the DB server effectively as a storage API service and run it via some orchestration service like K8S. This lets you offload your DB stability and data integrity to the FS and/or other low-level stuff that is simple to configure once and only dirty about when hardware fails. This in turn greatly reduces DB server configuration and deployment.

Now, if you are using a public cloud provider, my view changes slightly. Generally, I’d suggest offloading the DB to a provided service that is compatible with a FOSS alternative so that you can avoid vendor lock-in. This means that you get the HA, etc without having to worry about maintenance and configuration overhead. Just be aware of cost modeling - it’s easy to run up large bills.

source
redcalcium@lemmy.institute ⁨1⁩ ⁨year⁩ ago
I’ll usually centralized them. Use less resources then running them separately, and makes backup easier.

source
- Valmond@lemmy.mindoki.com ⁨1⁩ ⁨year⁩ ago
  Backups harder(well more if them), restaurations easier right?
  
  source
timespace@sh.itjust.works ⁨1⁩ ⁨year⁩ ago
Separate DB containers for each service. Easier, more secure, and less messy. The overhead impact is trivial.

source
chiisana@lemmy.chiisana.net ⁨1⁩ ⁨year⁩ ago
Multiple. They might need different versions of the database server, they might need to be scaled differently, they might need to be backed up at different cadences, they might need to be moved to different servers…. Etc.

The small marginal resource reduction is just not worth it.

source
PriorProject@lemmy.world ⁨1⁩ ⁨year⁩ ago
If a service supports sqlite, I often will use that option. It provides everything a self-hoster needs from a DB with basically no operational overhead.

If I do need a proper RDBMS (because the software I’m using doesn’t support sqlite), I’m going to use…

A single Postgres container.

Configured with multiple logical “databases” (the container for schemas and tables), one DB for each app connecting.

I do this because I’m always memory constrained and the rdbms is generally the most memory-hungry part of any software stack. By sharing one db-process across all the apps that need it I get the most out of my db cache memory, etc. And by using multiple logical db’s, I get good separation between my apps, and they’re straightforward to migrate to a truly isolated physical DB if needed… but that’s never been needed.
source
- AnAnxiousCorgi@lemmy.reddeth.com ⁨1⁩ ⁨year⁩ ago
  That makes a lot of sense and where I’m leaning towards as well
  
  While my homeserver still has plenty of resources to spare, I see a lot of them going towards multiple DB containers. It’s nice for “segregating” the containers, but backups are also a pain, gotta plan backups/restores for multiple DBs
  
  Same story with an s3 (well, minio) instance running. Seems like it would make more sense to centralize DB and file operations and having different services talk to them. Then if I ever needed to move them into separate servers, it wouldn’t be as big a move.
  
  Thanks!
  
  source
skadden@ctrlaltelite.xyz ⁨1⁩ ⁨year⁩ ago
I do a separate container for each service that requires a db. It’s pretty baked into my backup strategy at this point where the script I wrote references environment variables for dumps in a way that I don’t have to update it for every new service I deploy.

If the container name has -dbm on the end it’s MySQL, -dbp is postgres, and -dbs would be SQLite if it needed its own containers. The suffix triggers the appropriate backup command that pulls the user, password, and db name from environment variables in the container.

I’m not too concerned about system overhead, but I’m debating doing a single container for each db type just to do it, but I also like not having a single point of failure for all my services (I even run different VMs to keep stable services from being impacted by me testing random stuff out.)

source