Question on deployment lifecycle (wait before kill)

Questions / Help
1

Hi folks,

I have a question around the lifecycle of deployments. I’ve only just started using Fly.io so apologies if I’ve missed something in the docs (and I couldn’t find anything after a quick search in the forums either).

I gathered that we can send a kill signal and set a timeout: App Configuration (fly.toml) · Fly Docs

My question is, how exactly does it work during a deployment? i.e. What happens to old and new instances when a kill signal is sent to an instance?

For my use case, I have some background processes that run locally on the instance, and due to the way they work, a Lambda / serverless worker is not a suitable option. So, ideally, I would like the lifecycle to be something along the lines of:

  1. fly deploy
  2. After the successful build, new instances are spun up and added to the cluster and ready for inbound connections
  3. A kill signal is then sent to all old instances, whilst waiting for the kill to complete, the instances are immediately taken out of the cluster so no inbound connections are made to them

From reading the docs on deployment strategies (rolling, canary and immediate), I’m not sure if any of them would do it the way I described?

Any thoughts or suggestions?

Thanks!
Fred

2

You are right. You’d have this behaviour you desire once bluegreen deployments for AppsV2 is implemented: Any update on when bluegreen deploy strategy will be ready? - #2 by kwaw

If you’re up for it, you could accomplish a roughly similar behaviour by flyctl m destroy <old-machine> post successful flyctl m run <new-image> (or using equivalent Fly Machine APIs).

If you’re running the main process as root, it can capture the kill_signal (ex) and gracefully shutdown (if needed) within specified kill_timeout secs (ex).

3

Ah thanks for the info, that makes sense, I’ll investigate more on your suggestions.

1 Like
4

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