Whenever I read about docker or containers in general, I wonder how it could possibly work in real world applications.
That's what I (think I) understood until now:
- docker encapsulates an application, but not the applications data
- updates are done by completely exchanging the applications container (e.g. remove myApp 1.0.0 and start myApp 1.0.1)
- all non-volatile data is stored outside of the container in volumes (which are basically shared directories between the host and docker's containers)
However, if that's how it's done, how do Update processes / database schema updates / ... work?
A more specific example: If I have an postgres container and I need to update the database version (ergo: install the new container). How do I update the database files to the newer version, when the postgresql installation / updater will be never executed?
Top comments (6)
Hi!
Schema upgrades can be done independent of Docker, by using migration tools. See Testing Your Database Migrations With Flyway and Testcontainers for more details :)
Database upgrades can be done in different ways, I suppose.
A simple and flexible way would be to "lock" the database container and migrate the data over to a new one. If we are talking minor or maintenance version upgrades you might get away with mounting the same data directory. If the storage format changed, you can create a SQL dump and import it again. In both cases you'd first have to stop any changes to the existing DB, perform the backup, start a new container with a new version and include the backup.
If your database supports ways that don't involve a downtime, e.g. running replication across versions, you could upgrade one node at a time. Nevertheless all this can be quite annoying to manage so if possible I'd stick to a managed database.
Hi Frank,
thank you for your in-depth answer. Maybe I should give docker a try again and see, if the problems are as big as I imagined. Your post gives me some hope that it's possible to use it in production.
Thank you very much for your time and effort!
TBH, you should use what works best for you! If you're fine with running a DB installed by ansible scripts on virtual machines, then do it. If you're facing problems that Docker can solve then go for it. But don't use something just because it's available ;)
If you'd like, feel free to share some more details on the setup and the problems you're facing :)
There are a few strategies here but docker is just a vessel. You would perform the same steps as if you didn’t use docker. For example you would create a new image with the latest Postgres and import the database dump from the existing database.Assuming they are compatible and there are no breaking changes you could roll out the new container
Hey,
thank you for your answer.
that basically means I would have to
For every Environment that was deployed?
Isn't that the point where every developer wants to shoot himself, if he ever brought up docker to the table?
I'm coming from IT Service Management (Patch Management, Software deployment and so on) and pretty much every application does something in their update scripts (which is, of course, why they exist), that's why this sounds really shocking to me...
I guess that's the point where you should think about either automating the work or using a managed DB. You could of course also attempt to modify the existing container and save the state but that kind of defeats the purpose of Docker.