Selfhosted

60210 readers

946 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:

Detailed Rules Post

Be civil.
No spam.
Posts are to be related to self-hosting.
Don't duplicate the full text of your blog or readme if you're providing a link.
Submission headline should match the article title.
No trolling.
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

selfh.st Newsletter and index of selfhosted software and apps
awesome-selfhosted software
awesome-sysadmin resources
Self-Hosted Podcast from Jupiter Broadcasting

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

Questions? DM the mods!

founded 3 years ago

MODERATORS

curbstickle@anarchist.nexus

curbstickle_lw@lemmy.world

How do you manage you DB in a docker environment? (sh.itjust.works)

submitted 2 weeks ago by Croquette@sh.itjust.works to c/selfhosted@lemmy.world

34 comments fedilink hide all child comments

Hello,

As the title suggests, how do you manage your DBs for docker services.

Do you spin a new DB for every new docker cluster or do you have a centralized DB that is accessible to the docker clusters.

What are the pros and cons of both method?

For the moment, I spin a new DB for every services as I feel it is easier to backup the service in case of a problem.

you are viewing a single comment's thread
view the rest of the comments

[–] p_consti@lemmy.world 28 points 2 weeks ago

I typically have one DB service per app service (not just ler cluster, unless multiple services need the same db).

Advantages:

Simple backup/data organization, each service is self-contained
True isolation: Unless you manually create DB accounts for each service, likely all your services have access to all data, and even with accounts there are data leaks and exploits

Disadvantages:

You have more services running than strictly needed, but this is a minuscule impact on performance (the overhead of the DB service is typically not noticable)