loading...

re: Blue/Green Node.js Deploys with NGINX VIEW POST

FULL DISCUSSION
 

Jordan already provided a list of tools that can improve the process. I just want to add about several moments in your process:

  • if there is a daemon manager (service or systemctl), it's better to use it instead of nginx -s SIGNAL because the manager won't know anything about such reloads and won't be able to interact with the running process anymore.
  • checking when to remove the old code directory - since you know the old port, why don't just check if there are open connections to them? No connections - remove the code
  • the 1-second delay - when you do the switch, are you sure the new deploy is ready to be served? Perhaps it makes sense to make a readiness request before the switch? Anyway, you can use tcpdump (or anything similar) to record network traffic, with port/protocol filtering, and figure out to which backend (old or new port) is was made and failed to complete.
  • to run tasks in parallel, you can use parallel-ssh
  • speaking about one failed host - there are basically only two options if your scripts remove the old code and do it in parallel on several hosts. You can re-deploy for all or just for the failed host. Even rollback here is a re-deploy. By the way, you can keep several old release folders to stop worrying about the right time to remove the previous release and to be able to revert your deployment (however you would need to track which is the previous one, but it is solvable)
 

Thanks for taking the time to read this post and to share your recommendations for improvements. They're helpful.

Code of Conduct Report abuse