Description

Node.js 20 available as a minimal container is a base platform for running various Node.js 20 applications and frameworks. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. Usage in OpenShift

In this example, we will assume that you are using the ubi9/nodejs-20 image, available via nodejs:20-ubi9 imagestream tag in Openshift to build the application, as well as the ubi9/nodejs-20-minimal image, available via nodejs:18-ubi8-minimal image stream for running the resulting application.

With these two images we can create a chained build in Openshift using two BuildConfigs:

The first BuildConfig defines and builds the builder image, using the source-to-image strategy, and pushes the result into the nodejs-builder-image imagestream.

apiVersion: v1 kind: BuildConfig metadata: name: nodejs-builder-image spec: output: to: kind: ImageStreamTag name: nodejs-builder-image:latest source: git: uri: https://github.com/sclorg/nodejs-ex.git strategy: sourceStrategy: from: kind: ImageStreamTag name: nodejs:20-ubi9 namespace: openshift

The second BuildConfig takes the resulting image from the nodejs-builder-image imagestream, copies the application source (including build artifacts) from the image and creates a new runtime image on top of the nodejs minimal image, with the application copied in and prepared to run. The resulting runtime image is then pushed into the nodejs-runtime-image imagestream.

apiVersion: v1 kind: BuildConfig metadata: name: nodejs-runtime-image spec: output: to: kind: ImageStreamTag name: nodejs-runtime-image:latest source: dockerfile: |- FROM nodejs:20-ubi9-minimal COPY src $HOME CMD /usr/libexec/s2i/run images: - from: kind: ImageStreamTag name: nodejs-builder-image:latest paths: - sourcePath: /opt/app-root/src destinationDir: "." strategy: dockerStrategy: from: kind: ImageStreamTag name: nodejs:20-ubi9-minimal triggers:

imageChange: {} type: ImageChange

Source-to-Image framework and scripts

This image supports the Source-to-Image (S2I) strategy in OpenShift. The Source-to-Image is an OpenShift framework which makes it easy to write images that take application source code as an input, use a builder image like this Node.js container image, and produce a new image that runs the assembled application as an output.

To support the Source-to-Image framework, only the run script is included in this image.

The /usr/libexec/s2i/run script is set as the default command in the resulting container image (the new image with the application artifacts). It runs npm run for production, or nodemon if DEV_MODE is set to true (see the Environment variables section below).

Building an application using a Dockerfile

Compared to the Source-to-Image strategy, using a Dockerfile is a more flexible way to build a Node.js container image with an application. Use a Dockerfile when Source-to-Image is not sufficiently flexible for you or when you build the image outside of the OpenShift environment.

To use the Node.js image in a Dockerfile, follow these steps:

Pull the base builder and minimal runtime images

podman pull ubi9/nodejs-20 podman pull ubi9/nodejs-20-minimal

The UBI images ubi9/nodejs-20 and ubi9/nodejs-20-minimal that are used in this example are both usable and freely redistributable under the terms of the UBI End User License Agreement (EULA). See more about UBI at UBI FAQ. 2. Pull an application code

An example application available at https://github.com/sclorg/nodejs-ex.git is used here. Feel free to clone the repository for further experiments.

git clone https://github.com/sclorg/nodejs-ex.git app-src

Prepare an application inside a container

This step usually consists of at least these parts:

putting the application source into the container
installing the dependencies
setting the default command in the resulting image

For all these three parts, users can either setup all manually and use commands nodejs and npm explicitly in the Dockerfile (3.1.), or users can use the Source-to-Image scripts inside the image (3.2.; see more about these scripts in the section "Source-to-Image framework and scripts" above), that already know how to set-up and run some common Node.js applications. 3.1. To use your own setup, create a Dockerfile with this content:

First stage builds the application

FROM ubi9/nodejs-20 as builder

Add application sources

ADD app-src $HOME

Install the dependencies

RUN npm install

Second stage copies the application to the minimal image

FROM ubi9/nodejs-20-minimal

Copy the application source and build artifacts from the builder image to this one

COPY --from=builder $HOME $HOME

Run script uses standard ways to run the application

CMD npm run -d start

3.2. To use the Source-to-Image scripts and build an image using a Dockerfile, create a Dockerfile with this content:

First stage builds the application

FROM ubi9/nodejs-20 as builder

Add application sources to a directory that the assemble script expects them

and set permissions so that the container runs without root access

USER 0 ADD app-src /tmp/src RUN chown -R 1001:0 /tmp/src USER 1001

Install the dependencies

RUN /usr/libexec/s2i/assemble

Second stage copies the application to the minimal image

FROM ubi9/nodejs-20-minimal

Copy the application source and build artifacts from the builder image to this one

COPY --from=builder $HOME $HOME

Set the default command for the resulting image

CMD /usr/libexec/s2i/run

Build a new image from a Dockerfile prepared in the previous step

podman build -t node-app .

Run the resulting image with the final application

podman run -d node-app

Environment variables for Source-to-Image

Application developers can use the following environment variables to configure the runtime behavior of this image in OpenShift: Used in the minimal image

NODE_ENV NodeJS runtime mode (default: "production")

DEV_MODE When set to "true", nodemon will be used to automatically reload the server while you work (default: "false"). Setting DEV_MODE to "true" will change the NODE_ENV default to "development" (if not explicitly set).

NPM_RUN Select an alternate / custom runtime mode, defined in your package.json file's scripts section (default: npm run "start"). These user-defined run-scripts are unavailable while DEV_MODE is in use. Additional variables used in the full-sized image

HTTP_PROXY Use an npm proxy during assembly

HTTPS_PROXY Use an npm proxy during assembly

NPM_MIRROR Use a custom NPM registry mirror to download packages during the build process

One way to define a set of environment variables is to include them as key value pairs in your repo's .s2i/environment file.

Example: DATABASE_USER=sampleUser NOTE: Define your own "DEV_MODE":

The following package.json example includes a scripts.dev entry. You can define your own custom NPM_RUN scripts in your application's package.json file. Note: Setting logging output verbosity

To alter the level of logs output during an npm install the npm_config_loglevel environment variable can be set. See npm-config. Development Mode

This image supports development mode. This mode can be switched on and off with the environment variable DEV_MODE. DEV_MODE can either be set to true or false. Development mode supports two features:

Hot Deploy
Debugging

The debug port can be specified with the environment variable DEBUG_PORT. DEBUG_PORT is only valid if DEV_MODE=true.

A simple example command for running the container in development mode is:

podman run --env DEV_MODE=true my-image-id

To run the container in development mode with a debug port of 5454, run:

$ podman run --env DEV_MODE=true DEBUG_PORT=5454 my-image-id

To run the container in production mode, run:

$ podman run --env DEV_MODE=false my-image-id

By default, DEV_MODE is set to false, and DEBUG_PORT is set to 5858, however the DEBUG_PORT is only relevant if DEV_MODE=true. Hot deploy

As part of development mode, this image supports hot deploy. If development mode is enabled, any souce code that is changed in the running container will be immediately reflected in the running nodejs application. Using Podman's exec

To change your source code in a running container, use Podman's exec command:

$ podman exec -it /bin/bash

After you Podman exec into the running container, your current directory is set to /opt/app-root/src, where the source code for your application is located. Using OpenShift's rsync

If you have deployed the container to OpenShift, you can use oc rsync to copy local files to a remote container running in an OpenShift pod. Warning:

The default behaviour of the s2i-nodejs container image is to run the Node.js application using the command npm start. This runs the start script in the package.json file. In developer mode, the application is run using the command nodemon. The default behaviour of nodemon is to look for the main attribute in the package.json file, and execute that script. If the main attribute doesn't appear in the package.json file, it executes the start script. So, in order to achieve some sort of uniform functionality between production and development modes, the user should remove the main attribute.

Below is an example package.json file with the main attribute and start script marked appropriately:

{ "name": "node-echo", "version": "0.0.1", "description": "node-echo", "main": "example.js", <--- main attribute "dependencies": { }, "devDependencies": { "nodemon": "" }, "engine": { "node": "", "npm": "*" }, "scripts": { "dev": "nodemon --ignore node_modules/ server.js", "start": "node server.js" <-- start script }, "keywords": [ "Echo" ], "license": "", }

Note:

oc rsync is only available in versions 3.1+ of OpenShift. See also

Dockerfile and other sources are available on https://github.com/sclorg/s2i-nodejs-container. In that repository you also can find another versions of Node.js environment Dockerfiles. Dockerfile for CentOS is called Dockerfile, Dockerfile for RHEL7 is called Dockerfile.rhel7, for RHEL8 it's Dockerfile.rhel8 and the Fedora Dockerfile is called Dockerfile.fedora.

Products using this container

Red Hat Enterprise Linux 9

The leading enterprise operating system to speed application delivery across physical, virtual, and cloud environments.

Containerized application

Node.js

Node.js. is an open source JavaScript runtime environment designed to build modern scalable applications.

Containerized application

Security

Packages

Containerfile

Get this image

Terms & conditionsBefore downloading or using this Container, you must agree to the Red Hat subscription agreement located at redhat.com/licenses. If you do not agree with these terms, do not download or use the Container. If you have an existing Red Hat Enterprise Agreement (or other negotiated agreement with Red Hat) with terms that govern subscription services associated with Containers, then your existing agreement will control.

Using registry tokens

RegistryCopy to Clipboard

RepositoryCopy to Clipboard

Manifest List DigestCopy to Clipboard

Image DigestCopy to Clipboard

Use the following instructions to get images from a Red Hat container registry using registry service account tokens. You will need to create a registry service account to use prior to completing any of the following tasks.

Using OpenShift secrets

First, you will need to add a reference to the appropriate secret and repository to your Kubernetes pod configuration via an imagePullSecrets field.

Copy to Clipboard

Then, use the following from the command line or from the OpenShift Dashboard GUI interface.

Copy to Clipboard

Using podman login

Use the following command(s) from a system with podman installed

Copy to Clipboard

Using docker login

Use the following command(s) from a system with docker service installed and running

Copy to Clipboard

RegistryCopy to Clipboard

RepositoryCopy to Clipboard

Manifest List DigestCopy to Clipboard

Image DigestCopy to Clipboard

Use the following instructions to get images from a Red Hat container registry using your Red Hat login.

Using OpenShift

For best practices, it is recommended to use registry tokens when pulling content for OpenShift deployments.

Using podman login

Use the following command(s) from a system with podman installed

Copy to Clipboard

Using docker login

Use the following command(s) from a system with docker service installed and running

Copy to Clipboard

Get the source

RegistryCopy to Clipboard

RepositoryCopy to Clipboard

Manifest List DigestCopy to Clipboard

Image DigestCopy to Clipboard

Getting source containers

Source code is available for all Red Hat UBI-based images in the form of downloadable containers. Here are a few things you should know about Red Hat source containers.

Although they are packaged as containers, source containers cannot be run. So instead of using podman pull to get them to your system, use the skopeo command.
Source containers are named based on the binary containers they represent. So, for example, to get the source container for a particular standard RHEL UBI 8 container (registry.access.redhat.com/ubi8/ubi8.1-397) you simply append -source to get the source code container for that image (registry.access.redhat.com/ubi8/ubi8.1-397-source).
The skopeo command is recommended for getting source containers. With skopeo, you copy a source container to a directory on your local system for you to examine.
Once a source container is copied to a local directory, you can use a combination of tar,gzip, and rpm commands to work with that content.

Step one

Use skopeo to copy the source image to a local directory

Copy to Clipboard

Step two

Inspect the image

Copy to Clipboard

Step three

Untar the contents

Copy to Clipboard

Step four

Begin examining and using the content.

Nodejs 20 Minimal

Description

First stage builds the application

Add application sources

Install the dependencies

Second stage copies the application to the minimal image

Copy the application source and build artifacts from the builder image to this one

Run script uses standard ways to run the application

First stage builds the application

Add application sources to a directory that the assemble script expects them

and set permissions so that the container runs without root access

Install the dependencies

Second stage copies the application to the minimal image

Copy the application source and build artifacts from the builder image to this one

Set the default command for the resulting image

Products using this container

Red Hat Enterprise Linux 9

Node.js

Published

Release category

Size

Digest

Using OpenShift secrets

Using podman login

Using docker login

Using OpenShift

Using podman login

Using docker login

Getting source containers

Step one

Step two

Step three

Step four

Platforms

Products & services

Try, buy, sell

Help

About Red Hat Ecosystem Catalog

Red Hat legal and privacy links

Red Hat legal and privacy links

Nodejs 20 Minimal

Description

First stage builds the application

Add application sources

Install the dependencies

Second stage copies the application to the minimal image

Copy the application source and build artifacts from the builder image to this one

Run script uses standard ways to run the application

First stage builds the application

Add application sources to a directory that the assemble script expects them

and set permissions so that the container runs without root access

Install the dependencies

Second stage copies the application to the minimal image

Copy the application source and build artifacts from the builder image to this one

Set the default command for the resulting image

Products using this container

Red Hat Enterprise Linux 9

Node.js

Published

Release category

Size

Digest

Using OpenShift secrets

Using podman login

Using docker login

Using OpenShift

Using podman login

Using docker login

Getting source containers

Step one

Step two

Step three

Step four