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.
I use a single centralized database running directly on the host (postgres) and make it accessible to the docker clusters.
Pros: It’s all in one place to backup all important data for every service, I find this a much easier and more reliable way to backup all services, and I’m confident if you tried it you would too. The application data becomes a first-class citizen instead of hiding inside some nameless docker volume. Significantly less database overhead. Consistent database version and tools.
Cons: Lots. You need to manage and backup the database. You need to manage the database users and passwords too. Making the DB accessible to the docker clusters is nontrivial and can be fragile. You can no longer use the default “official” docker compose files, since they will almost never support an actual database service without several modifications, they’re always built for spinning up their own docker container database. So you’re going to be doing a bunch of work setting up users and passwords and performing extensive surgery on the docker-compose before you even start up the application, which adds a lot of friction, with lots of opportunity for error. All things considered, it’s actually quite painful. Technically if one application abuses your database hard enough and exhausts its memory to crash it or something it would affect other applications too, but that’s true of any services running on shared hardware abusing anything on that hardware, so it’s not a realistically concerning con.
I consider it worthwhile, but I might be wrong. Also I hate docker in general. I understand why people use it. It’s the same reason I use it. But I still hate it. I think system installations are so much easier to manage in the long run, but initially more work, and you need to invest that work at a time when you’re not even sure if you really want to run this application or if it’s going to be compatible with the rest of your environment. So docker is the easy solution. But then you’re basically trapped in dockerland. It’s not that bad, I just hate it in principle. I wish there were a better way.
Same, exactly what I do. For the part about backups, there are tools that make it really easy. I’m using databasus for instance. Once I had set up a couple applications, adding a new db, user, and backup config took just a few minutes every time really. In the end figuring out how to backup every docker stack’s individual DB sounds more complicated to me.
Edit: plus my first service hosted in this lab was my own matrix instance so I needed a solid DB, then it was already there so might as well use it.
That’s a good perspective.
I am the same. But many services offer docker as the main installation method and many times, the bare metal method is poorly documented.
So docker it is. And it’s a good skill to have no matter what since it is so widespread.
I never thought about the issues of setting a docker service with an external database. I don’t mind dealing with the users and tables of a database, but having to dig deep in docker compose settings is always a bad time.