this post was submitted on 17 Aug 2023
32 points (90.0% liked)

Selfhosted

39435 readers
6 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
32
"Support" containers - centralized or separate per service? (lemmy.reddeth.com)
submitted 1 year ago by [email protected] to c/[email protected]
13 comments fedilink hide all child comments
 

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?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 1 year ago (1 children)
  1. 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.
  2. If I do need a proper RDBMS (because the software I'm using doesn't support sqlite), I'm going to use...
    1. A single Postgres container.
    2. 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.

[–] [email protected] 2 points 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!