-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback before writing: Avoid custom process managers #704
Comments
Doesn't that only apply to environments where a container orchestration solution (such as Nomad or Kubernetes) are used? One popular use-case for pm2 used to be for utilizing multiple cores on a non-virtualized server, as it serves as a load-balancer. How common is it to use container orchestration in non-elastic environments? |
Yes
I would say otherwise - It's very uncommon and controversial to replicate multiple processes inside one docker container. Docker meant to be a platform that orchestrates processes where each container is a single unit of the app (usually one process). Violating this idea when using Docker seems to me like an Anti-pattern. I don't think that it's done in other languages. What do you think? |
I agree with you, my only point is that this article makes an assumption that Kubernetes/Docker are being used, which is not necessarily the case. If that is explicitly stated within the article, it does make perfect sense. |
Good point, I'll take care to specify that |
If you are running a container by itself using the docker runtime (not k8s), it is possible to set the restart policy to always. |
Closing as we merged #715 |
Context: This is used to share my TOC of a new best practice so I can solicit feedback and ideas before start writing. From my experience, this makes the writing experience much easier and shorter. And fun.
Title: Avoid the cluster module and custom process managers
TL&DR: Let the runtime invoke the Node process directly so it can be aware of failures and optimize the process placement and replicas; Many tempt to use custom process managers (PM2, etc) for quick recovery or the cluster module to replicate the Node process. however the runtime platform has much better visibility into what should be done on failures and how to replicate the process (explain why here);
Otherwise: Pod crashes because lack of resources, since K8S (for example) is not aware of the failures - it won't relocate it to a different instance
Simple explanation: About what common runtimes (e.g. Kubernetes) are doing in case of failures; How they replicate and place containers in a thoughtful way that conclude many factors; What happens when a local tool makes these decisions
Advanced tip: Some edge scenarios might justify using 3rd party process managers - old versions of Node couldn't get OS signals (PID1), some apps need ultra-fast recovery
Code example: Docker file with direct instantiation of a Node.js process
Code example Anti-pattern: Instantiating Node.js using PM2
Thoughts? improvement? Help me to make it better
The text was updated successfully, but these errors were encountered: