Hasura - How to define migrations?

[flobaader]

Hi @shakahl,

thank you for the nice helm chart of Hasura. I was wondering how I could define the db migrations for the chart?

I am currently building a custom image from the CLI image with my migrations. I have also seen another helm chart which makes use of ConfigMaps for migrations. Which way do you prefer?

[shakahl]

Hi @flobaader,

Thanks, I hope it will be useful for you! :)

I thing the migration handling is out of the chart's scope when Hasura is running in production environment although there is a migration job but that is not the best solution for this. Yes, I missed to implement the ability to attach ConfigMaps to the CLI migrations job :) I will fix that.

Usually the migration is a separate CI job which is running the hasura cli migrations Docker container. Anyway if there is any need to implement migrations in scope of the chart, then I would prefer the ConfigMap attached to a sidecar which is running before the main container.

Is this solution could work for you?

[flobaader]

Hello @shakahl,

thanks for the quick reply.
I also thought about running migrations in a separate CI process, however I think they are part of the application package that a Helm Chart is supposed to represent. They could be implemented with Helm Hooks (as far as I know).

I found this helm chart that uses ConfigMaps for migrations.

However, I did some research and found that k8s has a limit for ConfigMaps of 1MB (see this issue, which might not be suitable for large Hasura migrations.
So perhaps the best approach could be to use a Helm hook with a custom image (with migrations added) that inherits, for example, from hasura/graphql-engine:v1.3.3.cli-migrations-v2.

Another interesting aspect would be how to handle rollbacks to old migration states, since this task also requires the new migrations.

[shakahl]

Hi @flobaader,

I think I will make the docker image configurable for migration and seed jobs to open the possibility to use custom docker image for them (instead of hardcoded cli-migrations image) for migration and seeding process. It seems to be a quite usable possible solution for the problem.

What do you think @flobaader ?

Btw, sorry for my slow responses, I had quite busy days :S

[flobaader]

Hi @shakahl,

I think we should allow a custom-built migration image as an init container or as a helm upgrade hook. The main container can still be hardcoded as the "clean" image is much faster at the startup - So IMO the migration container should only run once.

One thing to consider is that the cli-migration image does not exit after doing the migrations. So maybe we need to overwrite the entrypoint 🤔