KEEP CALM & run Node.js

Hope my last article was informative and helped you guys gain some insights on using Node.js for your developments. Since my previous article, I got some queries regarding security, deployment and operational maintenance of services written in Node.js[they are actually common across the tech stack]. I will try to put out some of my learning below,

Security:

Encourage and evolve secure programming techniques, I suggest all my team members and colleagues to understand the OWASP top 10 vulnerabilities and ensure safe coding practices to avoid them.

npm audit early in the development stage and build pipelines. This will ensure you have a clean package dependency. Watch out for any security threats in specific to a package you use. In the pipeline, this will exit with a return code 0 only if no vulnerabilities are found in your dependency packages, else you will have a broken build and have to go back to fix the same either through npm audit fix, npm audit fix --force or replacing the vulnerable package.

look out for snyk as well, it helps you detect and fix vulnerabilities in your package dependencies.

Code quality:

use a linter, I preferably use eslint with airbnb/google config styles.

SonarQube is also a great option to ensure code quality and finding bugs in code with an automated static code analysis rule-set.

Containers:

It is needless to say that today Docker is synonymous to containers[package code, dependencies, system tools and libraries together]. Use Docker to containerize your application if you are not doing so yet. As a practice, all my projects have a Dockerfile in the root project structure which is used to create a docker image for the service. Use Docker repository or a private docker registry or any other artifactory like Nexus or JFrog to store your images which will used to further deploy in your runtime environment.

Here is a sample Dockerfile for Node.js.

Runtime:

If you are running on bare metals/ VM's without a container or service orchestrator then consider PM2. It is a process manager for Node.js applications and can be used for monitoring and keeping your applications alive forever and offers a lot of built-in features for production.

docker swarm mode/ kubernetes[k8s]:

It is important to understand the memory and CPU requirements of your service. Define requests and limits for these resources accordingly in your deployments. Use the horizontal pod autoscaler to scale out the number of replicas, e.g. in case CPU goes beyond 70% [just a baseline, may vary based on the service requirement].

There is no feature in docker swarm presently to autoscale, you will have to probably write up a script to poll, read the metrics and scale up your service manually or check your application metrics and manually scale up.

In case of large production runtime deployments, k8s is the preferred runtime. I have seen smaller runtimes being managed through a Docker Swarm as well. If you are early into your journey, you can start small with a swarm and then move to k8s depending on your requirement to scale and orchestrate.

APM:

You can use elastic APM to instrument your Node.js application and gather performance metrics[it just takes 4 lines of code]. Since it uses the Elastic Stack's Elastic Common Schema you can combine it with Logs, up-time and system metrics to have a centralized analysis and monitoring through kibana.

In case you have a prometheus server setup, then you can use prom-client to hook up your metrics.

Logging:

There are multiple options available for logging, you can go ahead and build your own logging strategy. I typically write logs to the STDOUT and STDERR through the console api. These logs can then be configured to be pushed to elastic through filebeat & logstash or fluentd.

The above are just some of the components, there are quite a few other variants or tools that will serve the above purpose. These are easy to wire-up into your development, build and release strategies.

Have a great day.

Disclaimer: the views and opinions expressed above are solely derived from my personal experiences and does not represent my employers or anyone else’s.