Do we need process monitors in docker containers running .net or node?

There has been some really interesting debate of late recently over the use of process monitors within docker containers, (particularly over on reddit here and here. Some responses even went as far as to call it an anti-pattern. Whilst I don't agree with a blanket sentiment like that (there are always other factors to consider if something really is an anti-pattern), it's worth us exploring the problem...

The old way

Before containerization really took hold, .net and node.js apps would generally run on bare metal, where servers were self administered. In the .net world, we would "publish" our applications in release mode (basically a distribution build) and would ship our compiled code onto our servers where we'd generally let IIS do the job of running our application. Fatal crashes were less of a concern in this world because of the type safety, and the application pool management of IIS.

In the node.js world, fatal crashes were more of a concern. Without typesafety, runtime crashes can be more of a risk. Out of the box, if a node.js application crashes, it will exit and will not serve any further requests.

Process monitoring in node.js

This is where process monitors came in and provided a vital job in node.js apps running in production. A process monitor is an application that wraps your application and attempts to keep it healthy. Some of these process monitors also include logging and some metrics.

Two popular node.js process monitors are

• nodemon (used more in development, although it is not unheard of for people to be running it in production)
• pm2 - or Process Monitor 2

pm2 is a bit more feature rich, which we'll come to later, and is more or less the defacto standard process monitor in node.

Both at their core, will attempt to re-start your node.js app if it crashes, so that it continues to serve requests. Both can also be configured to watch for any file system changes, so that the application is restarted if there is a source code change.

Process monitoring in .net

Process monitoring in .net seemed to become more of a concern when containerization took off, which co-incided with .net core becoming available and opening the door to cross platform .net development.

Out in the wild, I remember seeing several containerized .net core apps that were deployed into linux containers.

As a result of this, they were not built containing IIS, and instead internally ran .net's lightweight Kestral webserver, with the intention being that a more hardened webserver would sit infront of it (e.g. IIS or NGINX).

These containers typically ran supervisord to keep the .net core application alive. It's worth mentioning now that the .net's teams tutorials seem to lean towards using systemd instead.

So, do we need it in the containerised world?

It's possible to deploy a containerised app and totally separate our your keep alive and monitoring concerns to outside of the container.

Much of this relies on the docker flag --restart. For example:

docker run --restart=always -p 8081:8080 -p 81:80 -d --name myapp myapp

With the restart flag set to always, docker will continually restart the container if it exits - so you just need to make sure you have bound the ENTRYPOINT or CMD command directly to the node.js or .net process.

node.js:

CMD npm start -- --no-daemon --watch

.net:

ENTRYPOINT ["dotnet", "DotNet.Docker.dll"]

It's worth mentioning here that pm2 doesn't just deal with keeping a node.js process alive, but that it also deals with the clustering of node.js applications, which is absolutely essential in production when running on a multi-core environment.

So, if you're letting go of pm2, you need to do your clustering elsewhere. This is where we start getting into "other" considerations - especially budget, anticipated load and skillset. Clustering in the containerised world generally means using Docker Swarm, or Kubernetes to manage and monitor app instances. These are technologies that will do the job, but require their own infrastructure (and investment associated with that infrastructure) and skillset.

So generally, no, we do not need a process monitor in our containerized apps as long as we have set Docker up to restart our containers for us.

However, doing so is not an anti-pattern. If you haven't got the luxury of a budget, skills and time to invest into clustering your containers, it wont do you any harm to cluster inside of the container.