Is there a way to keep old containers running?
So I have a usecase which I am not sure how to solve:
Users can perform imports on my application which last 5-6 hours and are non-resumable. I want a way to keep old containers running until an import is running even when I deploy a new version. Is this possible?
Solution:Jump to solution
I'm not sure, if you want to be sure then you could use
RAILWAY_DEPLOYMENT_DRAINING_SECONDS instead
what this does is Railway will send your container a SIGTERM first, your app can then take that and start finishing jobs and not accept new ones
then once your app finishes all active jobs it can exit by itself (the amount of seconds you specify in this case is how long until Railway forces your app to close with SIGKILL)...21 Replies
Project ID:
N/AN/A
You can extend how long previous containers keep running, but you can't keep them running indefinitely
how would I go about extending them?
I want all old containers to keep running for 12 hrs but dont want requests to be routed to them
you can set a service variable
RAILWAY_DEPLOYMENT_OVERLAP_SECONDS to the amount of additional seconds you want the deployment to be running
I can't remember what the max amount is though, I think it was a few hoursthe docs on this env variable are lacking. what does overlap here mean?
It's how long Railway will keep the previous deployment running when you make a new deployment
typically when you create a new deployment, Railway keeps the previous one running for about 20 seconds just to ensure the new one takes over seamlessly
will requests be routed to this old container?
its not working btw
Solution
I'm not sure, if you want to be sure then you could use
RAILWAY_DEPLOYMENT_DRAINING_SECONDS instead
what this does is Railway will send your container a SIGTERM first, your app can then take that and start finishing jobs and not accept new ones
then once your app finishes all active jobs it can exit by itself (the amount of seconds you specify in this case is how long until Railway forces your app to close with SIGKILL)in what way is it not working? Does the previous container get removed regardless?
yes it does
can you try redeploying again
unfortunately the background job itself is written in a way that it is not resumable. so this is not very helful for me
i did
project id:
6ef7539d-c186-4609-a904-178fd8fa7fa0it wouldn't have to resume because you would never have to pause it
Strange, perhaps it's above the max amount? I completely forgot what the max amount is π
its not mentioned on the docs as well
i set it to 3600, still does not work
you want draining not overlap
this then
yep that seems to be working
is there a max value to this?
can i set it to 20k?
5.5hr should be fine
alright thanks