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.

  • Consti@lemmy.world
    English
    112·
    12 days 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)
  • irmadlad@lemmy.worldEnglish
    5·
    12 days ago

    I just run whatever db is required in the docker compose stack. I’ve thought about running separate db like mongo, mysql, sqlite and having them as central db services for the containers. I don’t see a downside to doing that. It just seems to me that it’s easier just to run what is required by the compose stack itself. For what I’m doing, they don’t seem to eat up much resources.

    • mertn@lemmy.worldEnglish
      2·
      10 days ago

      I do the same. If the docker container has problems with db I can just shut it down and fix the db from my desktop then start docker again. That has saved me starting again from scratch several times.

  • bacon_pdp@lemmy.worldEnglish
    0·
    12 days ago

    One database service but separate databases running inside of the service. Each database has 3 accounts: table_owner (no remote access), proc_owner (only table specific permissions and the owner of all stored procedures; no remote access) and application_account (no table access and only execute permissions on the proc_owner’s stored procedures).

    Which means that even if the application is compromised, it can not compromise the database. It can only use approved stored procedures that check their inputs and abort on the smallest deviation from expected inputs.