bluegreen deploy strategy for a non-TCP/HTTP service?

According to the docs, the bluegreen deploy strategy requires health checks in order to run. It seems like the only health checks I can run are HTTP or TCP requests, but my service is a worker so it doesn’t listen or respond to TCP requests.

It’s important that I use a “start-first” deploy strategy - I want no downtime on this worker and would like for there to be a brief overlap between the old and new deploy. Are there any options available for me? It seems like the canary strategy can still result in some downtime (especially in multi-region deploys), but please correct me if I’m wrong.

Thanks!

I think your best bet is to add some sort of health check endpoint. As long as you don’t add a public IP to your workers, that endpoint will only be accessible to your 6PN, so you’re all good from a security perspective.

To illustrate the wider point - if your app has no way to report that it’s healthy, then all that the fly.io platform can really determine is whether or not the VM is running. So it’s not so much a problem of not having the right deployment strategy; there simply is no deployment strategy that will work correctly if health cannot be determined.

If the question is more about wanting to do UDP health checks, we don’t support that at the moment, so you’d have to roll your own deployment strategy (perhaps using flyctl’s code for inspiration).

@jfent thanks for the response! That makes perfect sense. Does Fly support running a binary as a health check? If not, is that on the roadmap?

Not directly, but you could setup an endpoint that simply calls out to your binary and returns its result.

I don’t believe it’s on our roadmap given it’s already possible in this slightly more roundabout way.

That’s fair, that’s exactly what I’ve done. Thanks!

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.