some of them, and supports multiple architectures (amd64, arm32v6, arm32v7, arm64v8 and s390x).
Starting with Node-RED 1.0, the repository on Docker Hub has been renamed nodered/node-red.
quick start
To run it in Docker in its simplest form, just run:
docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red
Let’s dissect this command:
docker run – run this container, initially building locally if necessary
-it – attach a terminal session so we can see what is going on
-p 1880:1880 – connect local port 1880 to the exposed internal port 1880
-v node_red_data:/data – mount a docker named volume called `node_red_data` to the container /data directory so any changes made to flows are persisted
–name mynodered – give this machine a friendly local name
nodered/node-red – the image to base it on – currently Node-RED v1.2.0
Running this command should give you a terminal window with a running instance of Node-RED.
Welcome to Node-RED
===================
10 Oct 12:57:10 – [info] Node-RED version: v1.2.0
10 Oct 12:57:10 – [info] Node.js version: v10.22.1
10 Oct 12:57:10 – [info] Linux 4.19.76-linuxkit x64 LE
10 Oct 12:57:11 – [info] Loading palette nodes
10 Oct 12:57:16 – [info] Settings file : /data/settings.js
10 Oct 12:57:16 – [info] Context store : ‘default’ [module=memory]
10 Oct 12:57:16 – [info] User directory : /data
10 Oct 12:57:16 – [warn] Projects disabled : editorTheme.projects.enabled=false
10 Oct 12:57:16 – [info] Flows file : /data/flows.json
10 Oct 12:57:16 – [info] Creating new flow file
10 Oct 12:57:17 – [warn]
————————————————– ——————-
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the ‘credentialSecret’ option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
————————————————– ——————-
10 Oct 12:57:17 – [info] Starting flows
10 Oct 12:57:17 – [info] Started flows
10 Oct 12:57:17 – [info] Server now running at http://127.0.0.1:1880/
[…]
You can then browse to http://{host-ip}:1880 to get the familiar Node-RED desktop.
The advantage of this is that by giving it a name (mynodered) we can more easily manipulate it, and by fixing we know the host port we are familiar with. Of course, this does mean we can only run one instance at a time… but only one step at a time.
If we are satisfied with what we see, we can change the terminal with Ctrl-p Ctrl-q- and the container will continue to run in the background.
To reconnect to the terminal (view logging), run:
docker attach mynodered
If you need to restart the container (for example after restarting or restarting the Docker daemon):
docker start mynodered
and stop again if needed:
docker stop mynodered
Image changes
Node-RED images are based on official Node JS Alpine Linux images to keep them as small as possible. Using Alpine Linux reduces the built image size but removes the standard dependencies required for native module compilation. If you want to add dependencies with native dependencies, extend the Node-RED image with the missing packages on the running container or build a new image, see docker -custom which is in the README.md in the Node-RED Docker project expanded on.
For detailed images, tags, and manifest information, see the Github project readme.
For example: Assume you are running on a Raspberry PI 3B with arm32v7as architecture. Then just run the following command to pull the image (tagged by 1.2.0-10-arm32v7) and run the container.
docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red:latest
The same command can be used to run on an amd64 system, as Docker discovers that it is running on an amd64 host and pulls the image with the matching label (1.2.0-10-amd64).
The benefit of this is that you don’t need to know/specify the architecture you are running on, and makes the docker run command and docker compose files more flexible and interchangeable across systems.
Note: There is currently a bug in Docker’s architecture detection for arm32v6 such as Raspberry Pi zero or one. For these devices, you currently need to specify the full image tag, for example:
docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red:1.2.0-10-arm32v6
Manage user data
After running Node-RED with Docker, we need to ensure that any added nodes or streams are not lost if the container is destroyed. This user data can be saved by mounting the data directory to a volume outside the container. This can be done using bind mounts or named data volumes.
Node-RED uses the directory within the /data container to store user configuration data.
Using host directory for persistence (bind mount)
To save the Node-RED user directory inside the container to the host directory outside the container, you can use the following command. To allow access to this host directory, the node-red user within the container (default uid=1000) must have the same uid as the owner of the host directory.
docker run -it -p 1880:1880 -v /home/pi/.node-red:/data –name mynodered nodered/node-red
In this example, the host /home/pi/.node-red directory is bound to the container /data directory.
Note: Users migrating from version 0.20 to version 1.0 need to ensure that any existing /data directories have correct ownership. As of 1.0 this needs to be 1000:1000. This can be forced with the command sudo chown -R 1000:1000 path/to/your/node-red/data
See the wiki for details about permissions.
Use named data volumes
Docker also supports the use of named data volumes to store persistent or shared data outside the container.
Create a new named data volume to hold our user data and run a new container using this volume.
$ docker volume create –name node_red_data
$ docker volume ls
DRIVER VOLUME NAME
local node_red_data
$ docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red
If you need to back up data from a mounted volume, you can access it while the container is running.
$ docker cpmynodered:/data/your/backup/directory
Using Node-RED to create and deploy some sample processes, we can now destroy the container and start a new instance without losing our user data.
$ docker stop mynodered
$ docker rm mynodered
$ docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red
renew
Since /data is now kept outside the container, updating the base container image is now like
$ docker pull nodered/node-red
$ docker stop mynodered
$ docker rm mynodered
$ docker run -it -p 1880:1880 -v node_red_data:/data –name mynodered nodered/node-red
Docker Stack/Docker Written
Below is an example Docker Compose file that can be run by docker stack or docker-compose. For more information about the Docker stack and Docker compose, see the official Docker page.
################################################ ############################### Node-RED Stack or Compose############# ################################################ ################## docker stack deploy node-red –compose-file docker-compose-node-red.yml# docker-compose -f docker-compose-node- red.yml -p myNoderedProject up########################################## ####################################version: “3.7”services:
node-red:
image: nodered/node-red:latest
environment:
– TZ=Europe/Amsterdam
ports:
– “1880:1880”
networks:
-node-red-net
volumes:
– node-red-data:/datavolumes:
node-red-data:networks:
node-red-net:
Compose file above:
Create node red service
Pull the latest node red image
Set time zone to Europe/Amsterdam
Map container port 1880 to host port 1880
Create a node-red-net network and attach the container to it
/data persists the directory within the container to a volume in node-red-dataDocker
Dockerfile copied in local resources
It is sometimes useful to populate the Node-RED Docker image with files from a local directory (for example, if you want to keep the entire project in a git repository). For this you need a local directory like this:
Dockerfile
README.md
package.json # add any extra nodes your flow needs into your own package.json.
flows.json # the normal place Node-RED store your flows
flows_cred.json # credentials your flows may need
settings.js # your settings file
Note: This method is not suitable if you want to mount the /data volume externally. If you need to use an external volume for persistence, copy your settings and flow files to that volume.
The following Dockerfile builds on the base Node-RED Docker image, but additionally moves your own files into the image:
FROM nodered/node-red
# Copy package.json to the WORKDIR so npm builds all
# of your added nodes modules for Node-RED
COPY package.json .
RUN npm install –unsafe-perm –no-update-notifier –no-fund –only=production
# Copy _your_ Node-RED project files into place
# NOTE: This will only work if you DO NOT later mount /data as an external volume.
# If you need to use an external volume for persistence then
# copy your settings and flows files to that volume instead.
COPY settings.js /data/settings.js
COPY flows_cred.json /data/flows_cred.json
COPY flows.json /data/flows.json
# You should add extra nodes via your package.json file but you can also add them here:
#WORKDIR /usr/src/node-red
#RUN npm install node-red-node-smooth
NOTE: The package.json file must contain a launch option in the script section. For example, the default container looks like this:
“scripts”: {
“start”: “node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS”,
…
Dockerfile order and build speed
Although not necessary, it’s a good idea to COPY package… npm install… to do these steps early, because while flows.json changes often when working in Node-RED, package.json only changes when modules in the project are changed. will change. And because the steps you need to perform when changing npm install package.json can sometimes be time-consuming, it’s a good idea to perform time-consuming, often unchanged steps earlier in the Dockerfile so that these build images can be reused, making subsequent The overall build is faster.
Credentials, secrets, and environment variables
Of course, you never want to hardcode credentials anywhere, so if you need to use credentials in a Node-RED project, the above Dockerfile will let you do that in your settings.js…
module.exports = {
credentialSecret: process.env.NODE_RED_CREDENTIAL_SECRET // add exactly this
}
…and then when you run in Docker, you add an environment variable to your run command…
docker run -e “NODE_RED_CREDENTIAL_SECRET=your_secret_goes_here”
Build and run
You typically build this Dockerfile:
docker build -t your-image-name:your-tag .
To run locally for development, where changes are written immediately and only cd to the project directory from the local directory you are working with, then run:
docker run –rm -e “NODE_RED_CREDENTIAL_SECRET=your_secret_goes_here” -p 1880:1880 -v `pwd`:/data –name a-container-name your-image-name
start up
Environment variables can be passed into the container to configure Node-RED’s runtime.
The flow configuration file is set using the environment parameter ( FLOWS ), which defaults to ‘flows.json’. This can be changed at runtime using the following command line flags.
docker run -it -p 1880:1880 -v node_red_data:/data -e FLOWS=my_flows.json nodered/node-red
Note: If you set -e FLOWS=””, you can set the flow via the flowFile property in the file settings.js file.
Other useful environment variables include
-e NODE_RED_ENABLE_SAFE_MODE=false# Set to true to start Node-RED in safe (non-running) mode
-e NODE_RED_ENABLE_PROJECTS=false # Set to true to start Node-RED and enable project functions
Node.js runtime parameters can be passed to the container using environment parameters (NODE_OPTIONS). For example, to fix the heap size used by the Node.js garbage collector, you can use the following command.
docker run -it -p 1880:1880 -v node_red_data:/data -e NODE_OPTIONS=”–max_old_space_size=128″ nodered/node-red
Keywords: industrial gateway