Skip to content
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

Closed
goldbergyoni opened this issue Jun 2, 2020 · 6 comments
Closed

Feedback before writing: Avoid custom process managers #704

goldbergyoni opened this issue Jun 2, 2020 · 6 comments

Comments

@goldbergyoni
Copy link
Owner

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

@kibertoad
Copy link

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?

@goldbergyoni
Copy link
Owner Author

Doesn't that only apply to environments where a container orchestration solution (such as Nomad or Kubernetes) are used?

Yes

How common is it to use container orchestration in non-elastic environments?

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?

@kibertoad
Copy link

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.

@goldbergyoni
Copy link
Owner Author

Good point, I'll take care to specify that

@kevynb
Copy link
Collaborator

kevynb commented Jun 27, 2020

If you are running a container by itself using the docker runtime (not k8s), it is possible to set the restart policy to always.
In case of failure, the container will crash but be restarted automatically by docker.

@kevynb
Copy link
Collaborator

kevynb commented Aug 17, 2020

Closing as we merged #715

@kevynb kevynb closed this as completed Aug 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants