Scribd
Upload
17 views

10 Tips Node Js Applications Red Hat Developer

The document provides 10 tips for running Node.js applications on Red Hat OpenShift. The tips include running as a non-root user, using UBI containers, using two-stage builds for minimal images, implementing health checks, logging to stdout, exporting metrics, externalizing secrets, avoiding privileged ports, and setting memory limits to match container resources. Following these tips helps improve security, portability, and observability of Node.js applications on OpenShift.

Uploaded by

Aa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
17 views

10 Tips Node Js Applications Red Hat Developer

The document provides 10 tips for running Node.js applications on Red Hat OpenShift. The tips include running as a non-root user, using UBI containers, using two-stage builds for minimal images, implementing health checks, logging to stdout, exporting metrics, externalizing secrets, avoiding privileged ports, and setting memory limits to match container resources. Following these tips helps improve security, portability, and observability of Node.js applications on OpenShift.

Uploaded by

Aa
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

CHEAT SHEET

Ten Tips For Running Node.js Applications on Red Hat OpenShift

To run your Node.js applications on Red Hat OpenShift e ectively, try these tips.

1. DON’T RUN AS ROOT

Running processes as root, even in containers, can be a security risk, particularly if external resources are mapped into the container.
When using Docker or Podman, you can change the user with the USER command. Well-designed base containers already do this, but you
should always check which user is used by default.

2. USE UBI CONTAINERS

UBI-based containers are already built into OpenShift, which bene ts your application because it doesn’t need to rely on an outside service
such as Docker Hub.
UBI-based container images run as non-root, which ties in nicely with Tip 1.

3. TRY TO USE THE MOST MINIMAL IMAGE YOU CAN THROUGH TWO-STAGE BUILDS

Best practice is to use a two-stage build, where a larger build image is used to build an application and then the resulting artifacts are copied
to a more minimal run image. The build image includes all of the tools needed to build the application (compilers, etc.), whereas the run image
includes only what’s necessary for the application to run. The size di erence between the build and run images can often be signi cant.

4. DON’T USE NPM START

Although you will often see CMD ["npm", "start"] in Docker les used to build Node.js applications, you should use a command like CMD
["node","index.js"] instead. There are a number of good reasons to avoid npm start:
One less component. You generally don’t need npm to start your application. If you avoid using this command in the container, you will
not be exposed to any security vulnerabilities that might exist in that component or its dependencies.
One less process. Instead of running two processes (npm and node) you run only one.

'npm' can lead to issues with signals and child processes. You can read more about those problems in the Docker best practices
documentation.

Build here. Go anywhere. developers.redhat.com | @RHDevelopers


CHEAT SHEET

5. USE HEALTH CHECKS

The rst thing you need to build into your application is support for liveness and readiness endpoints. OpenShift has built-in functionality to
check these endpoints:
Liveness: Restart the container when the liveness endpoint does not respond to indicate that the application is alive.
Readiness: Defer sending tra c until the application is ready to accept tra c, or step sending tra c if the application is no longer able to
accept tra c.

6. LOGGING

Node.js developers need to know how to do logging in a cloud-native environment. In container development, writing logs out to disk does
not generally make sense because of the extra steps needed to make the logs available outside the container—and they will be lost once the
container is stopped.
Logging to standard out (stdout) is more appropriate for the cloud, and structured logging (for example, using JSON) is the current trend. One
excellent module is pino, a fast, structured logger for Node.js that is easy to use.

7. METRICS

In an OpenShift deployment, your application is running in containers. There may be multiple copies of each container, and it is not
necessarily easy to nd or query those containers to gather information about how your application is running. For these reasons, it is
important for your container to export the key metrics you need for understanding and tracking your application’s health.
Prometheus is the de facto standard for this task. It de nes a set of metrics that you should export and gives you the ability to add additional
application-speci c metrics that are important to your business.

8. EXTERNALIZE SECRETS

Secrets should be externalized and made available to the application at runtime through secure means.
Using a Con gMap can help externalize Secrets.

9. DON’T USE PRIVILEGED PORTS

Ports below 1024 are considered trusted, and a process must have additional privileges to be able to bind to them.
If you follow Tip 1 and build your containers as non-root, your process can’t bind to the privileged ports.

Build here. Go anywhere. developers.redhat.com | @RHDevelopers


CHEAT SHEET

10. SETTING MEMORY LIMITS

The Node.js runtime sets default memory limits for the heap that might not match what you want to use in production.
Use an environment variable in your start scripts so that you can tell the Node.js runtime in the container to use a limit high enough to
accommodate the memory you provide to the container when it runs.
The following setting is an example of such an environment variable in the start script within package.json:

"start": "if [ -z \"$MAX_NODE_MEMORY\" ]; then export MAX_NODE_MEMORY=2048; fi; node --max-old-space-size=$MAX_NODE_MEMORY bin/app.js",

This practice allows you to con gure the max-old-space-size to align with what you de ne in your Kubernetes deployment les or set with the --
memory option in docker run commands.

Build here. Go anywhere. developers.redhat.com | @RHDevelopers

You might also like