So I’m in the process of (re-) setting up my homelab and unsure about how to handle databases. Many images require a database, which the docker-compose usually provides inside the stack.
Now my question, shall I have 1 database container which is accessed by all containers? Or shall I have a separate container for each service?
For critical services, which shall have as few dependencies as possible I’m already using sqlite or a similar solution.
Also on a sidenote: I have two docker hosts, can I let the containers of 1 hypervisors use the same internal docker network?
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
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:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
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.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I agree with the posts above. Db per stack/service.
They are cheap, disposable, ring fenced from causing issues with other dB’s, exact version that has been tested on.
The list is endless. We’ll, I’m at my end.
Oo. Typically compose has everything you need prewritten including the db.