create an init container image for applying migrations on kubernetes

[tirumaraiselvan]

This would be the k8s native way of applying migrations.

[GavinRay97]

Actually ran into this issue today.

Attempting to figure out how to auto-apply migrations on k8s and keep them in sync.

I can't pass the migrations directory argument to the environment because the filesystems are independent, so obviously trying to reference /migrations will point to something that does not exist inside of the k8s pod.

One way might be to write a bash script to post-deploy curl and apply the migrations, but that is not particularly clean.

Also, how is the best way to sync schema/metadata changes made from a Hasura Engine inside of k8s to the parent directory that launched the container?

[GavinRay97]

Okay, I have a working solution.

The Dockerfile for the Hasura engine that gets deployed to my k8s looks like this:

FROM hasura/graphql-engine:v1.0.0.cli-migrations
COPY migrations /migrations

And in my Hasura config:

HASURA_GRAPHQL_MIGRATIONS_DIR: "/migrations"

The directory structure is so:

Credits to @edvald for assisting here 🙏

[jjlakis]

It would be nice if we could apply migrations directly to database without having graphql engine server running. Thanks to this, we could use initContainer with migrations before Hasura server has started, and we don't need to create custom image.

[anhpngt]

Is there anyway to use the JSON metadata file for the cli-migrations image instead of the metadata directory?
With the JSON, I can simply create a ConfigMap.

[kevinbevers]

Whats the status of this?

[jflambert]

oh, we've been using Hasura as a kubernetes initContainer for a long time. It's quite simple.

just provide args: ["true"] to stop Hasura from running beyond the migration part.

And you load migrations through volumes/volumemounts

It would be nice if we could apply migrations directly to database without having graphql engine server running. Thanks to this, we could use initContainer with migrations before Hasura server has started, and we don't need to create custom image.

I suggested something like this in #8061 and actually closed it myself. The hasura-cli binary itself is "dumb", as in it depends on a hasura server being present to make API calls.

Is there anyway to use the JSON metadata file for the cli-migrations image instead of the metadata directory? With the JSON, I can simply create a ConfigMap.

sadly no. So! we ended up creating a hasura-operator based on operator-sdk that looks for a CRD which consists of the JSON metadata converted to yaml ;)

We didn't just want to perform an initial load of the metadata, we also wanted the hasura-operator to scan for changes to the metadata CRD.

[iosifnicolae2]

@jflambert are you planning on open sourcing hasura-operator? :)