Create more complete example of using grate in a container (k8s, etc) about grate HOT 9 OPEN

You're on your own here mate, I have no desire to play in the k8s space for this stuff... we run live migrations in k8s, but literally just kubectl run --restart=never an image built like the samples...

from grate.

I have a tiny bit of experience with Service Fabric and i know we have hosted python containers in there. I could have a look how we do it for that and maybe create an exampld based on that?

from grate.

Thanks a lot, @DjKillerMemeStar ! I'd appreciate that. I don't think the main issue is hosting grate in a container, though, but how you should/would actually use it in a Kubernetes setting. Would you create an init container? Would you create a background service that watches a folder for changes? Something totally different?

Do you have any thoughts on this? Maybe the question is too generic, and the use cases will vary a lot depending on each and every one's surrounding bits and bobs?

from grate.

I don't really see a point in hosting grate yourself. It's just install on the build server any way you like and run it. This seems like a way easier way to do it. Ofcourse, people/situations differ so i'm not sure.

Maybe the question could be rephrased to beter explain what you mean. It's more of a "why would you use grate in a container" then a how in my eyes. Could ofcourse be wrong here 😄.

from grate.

I had a project where the build server (AzDo) didn't have access to the Sql Server (firewalled/PrivateLink/something weird???) but the k8s cluster obviously did have access. As noted above, we'd build the container like the sample and just kubectl run a one-off instance from the pipeline.

from grate.

Ow yeah, makes sense, sorry bout that!

We just use our own agents so bypass any firewall restrictions etc, but that is ofcourse not possible for everyone.

From that standpoint i don't see anything wrong with your approach of an one-off instance.

from grate.

I'm just thinking a bit further on this one. It might seem like I'm trying hard to create a use case for something that isn't, but, if you compare to, say EF migrations, where the migration is performed on application startup, would it make sense to create an example where grate is used in an init container, mounting the database scripts in a volume there, and running them on startup, before the actual application container starts?

Or am I beating a dead horse here?

from grate.

I can see the comparison with EF Migrations (which fwiw I don't like for various reasons, hence being here).

A sample for a migration style workflow would obviously be useful if that's a workflow you want to push, via either

• init containers (which I have no experience with), or
• referencing grate via nuget (which I think RH had support for?? I never used it) and running a migration on app start?

from grate.

There is the init container pattern described here: https://andrewlock.net/deploying-asp-net-core-applications-to-kubernetes-part-7-running-database-migrations/#combining-jobs-and-init-containers-to-handle-migrations

from grate.