Database migrations in Kubernetes applications with Flyway

In this video I'll show how to migrate databases with Flyway in managed Kubernetes environments.
For more information see blog.sebastian-daschner.com/e...

[@toldwin5194]

Very clear, informative and concise. Thanks for this perfect video !

[@avgalani]

Thanks, this helped me write up results of a spike story I was tasked with; good stuff!

[@aloufin]

well explained solution! However, for a big table change, that seems like a lot of extra java code needed... I hope flyway/kubernetes are working on an easier/automated solution for this process.

[@prashantbhatia7426]

This is great stuff , what happens when flyway migration gives non zero exit code , init- container would always try complete to finish , how do you deal with that scenario ?

[@NeoDaPlaya]

Then you have a failed deployment and do a rollback.

[@nicolal.1171]

@@NeoDaPlaya The rollback of a database migration doesn't seem that trivial to me. Rolling back a container is easy, and I guess K8 does it automatically for you (it pulls the previous version of the container, and it starts it again). I don't see how k8 is able to revert a change already committed in a relational database. I guess a new database migration, that reverts the one previously applied, has to be written and applied separately. During this lapse of time, the rollbacked version of the application is running on the newer version of the database schema. Which could cause quite some issue to the application. Anyone knows how to deal with it?

[@NeoDaPlaya]

@@nicolal.1171 OP says flyway (so the migration itself) exits with a non-zero code. That means that most likely the migration was not applied and a rollback of the container should be sufficient.
As for your other question: Helm for example has pre-/post-rollback hooks. But database rollbacks should be one in a million (hopefully) and can therefore be handled manually. Also, DB rollbacks and App compatability are more of an organizational issue (+/- 1 compat between App DB) than a technical issue.
But lets face the truth: if you are not Google or another FAANG-like company than you are most likely to skip the whole issue of (automated) DB rollbacks and live with a service interruption in case of a failed migration.

[@sergioteixeira910]

initcontainers is a bad idea for migrations, better use a pre install job that runs before the deployment is initialized.

[@dane2565]

@Bhisham Bajaj it is possible for the migration to be triggered every time a new pod is created if the init container is designed to perform the migration on every startup