Self hosted spin on nomad cluster how to achieve 0 downtime deployments

[Jamahl-Carter]

I'm using spin deploy to push app changes to my self hosted nomad cluster and am consistently observing 404 responses for a brief window after the release.

I believe this is while the traffic is being re-routed to consume the new app version, is it possible to configure this to use the old version until the new version is ready ? Or any other method to remove this window of downtime ?

Thanks in advance for your help !

[lann]

Spin doesn't have a mechanism to do this today. You would typically achieve this by combining a load balancer with rolling restarts (or similar) so that both the old and new versions of the app are (briefly) being served at the same time.

[lann]

Spin itself responds on /.well-known/spin/health but doesn't reflect anything about your actual app so you might want your own health endpoint.

[lann]

Nomad supports a number of different zero downtime strategies but the details will depend on your specific infrastructure.

There is also https://www.spinkube.dev/ which handles many of these things in a kubernetes environment.

[Jamahl-Carter]

Thanks for the info, I think k8 runs a little heavy for my use case but I'll look through their docs to see if I can glean some insights.

In the case where I have a "working" http spin trigger with 0 logic issues (lets say it just returns "hello world"), will I be able to use /.well-known/spin/health to inform when my trigger is rout-able (i.e. when I attempt to hit it, it will invoke my handler logic and not 404 etc..) ?

[lann]

will I be able to use /.well-known/spin/health to inform when my trigger is rout-able (i.e. when I attempt to hit it, it will invoke my handler logic and not 404 etc..) ?

Yep. It's really more of a "readiness" check than a health check.

[Jamahl-Carter]

Perfect - this mechanism should work for my use case. Thanks Iann, I'll resolve this thread.