Node-RED Dockerfile question/optimization

[segaura]

In Node-RED Dockerfile, what is the point of installing apk packages (switching temporarily to root user)?

Isn't it simpler to stay non-root and simply do an npm install like Node-RED docker project suggests to?

Building Custom Image
Creating a new Docker image, using the public Node-RED images as the base image, allows you to install extra nodes during the build process.

This Dockerfile builds a custom Node-RED image with the flightaware module installed from NPM.

FROM nodered/node-red
RUN npm install node-red-contrib-flightaware

docker-compose.yml already has the EXTRA_PACKAGES ARG to work with

args:
- DOCKERHUB_TAG=latest
- EXTRA_PACKAGES=node-red-configurable-ping node-red-contrib-boolean-logic node-red-contrib-influxdb node-red-dashboard node-r...

So Dockerfile only needs

RUN npm install ${EXTRA_PACKAGES}

[Paraphraser]

You need to make a distinction between "packages" and "add-on nodes".

Packages are installed by apk.

Add-on nodes are installed by npm install.

While add-on nodes can, and in fact should be installed by the current user (node-red, user ID 1000, inside the container) , "packages" can only be installed by root.

Normally, you'd use sudo to escalate privileges but that command isn't available inside the container, therefore switching the user to root and back again is the only viable approach.

In your example, node-red-configurable-ping node-red-contrib-boolean-logic node-red-contrib-influxdb node-red-dashboard and so on are add-on nodes, not packages.

My own service definition looks like this:

    build:
      context: ./services/nodered/.
      args:
        - DOCKERHUB_TAG=latest
        - EXTRA_PACKAGES=mosquitto-clients bind-tools tcpdump tree

whereas my Dockerfile looks like this:

# reference argument - omitted defaults to latest
ARG DOCKERHUB_TAG=latest

# Download base image
FROM nodered/node-red:${DOCKERHUB_TAG}

# reference argument - omitted defaults to null
ARG EXTRA_PACKAGES

# default user is node-red - need to be root to install packages
USER root

# install packages
RUN apk add --no-cache eudev-dev ${EXTRA_PACKAGES}

# switch back to default user
USER node-red

# add-on nodes follow

RUN npm install \ 
  node-red-node-pi-gpiod \
  node-red-dashboard \
  node-red-contrib-influxdb \
  node-red-contrib-boolean-logic \
  node-red-node-tail \
  node-red-configurable-ping \
  node-red-node-email \
  node-red-contrib-boolean-logic-ultimate \
  node-red-contrib-chartjs \
  node-red-contrib-md5 \
  node-red-contrib-moment \
  node-red-contrib-pushsafer \
  @node-red-contrib-themes/theme-collection

A standard Dockerfile generated by the menu would use a separate RUN command for each add-on node. Personally, I think that's inefficient because each RUN results in a separate layer, which is why I've customised my own Dockerfile.

The essential distinction between packages and add-on nodes is that the EXTRA_PACKAGES= option is mainly concerned with providing tools that may be used in debugging. In my case:

• mosquitto-clients lets me run mosquitto_sub and mosquitto_pub in the same way as the MQTT-in and -out nodes. If an MQTT node is having trouble, the corresponding mosquitto_ command, run from inside the container, will usually give me insight into what is going wrong.
• bind-tools provides tools like dig for running DNS queries in the same way as Node-RED and add-on nodes do. If there's an inside-the-container vs outside-the-container DNS resolution issue, those tools help nail the sucker.
• tcpdump when all else fails, packet captures are the way to go.
• tree much better than ls -R for exploring directory hierarchies.

The fixed eudev-dev package is there for Bluetooth support on the Pi and is needed if you want to run any Bluetooth nodes.

Insofar as I'm aware, none of the EXTRA_PACKAGES= in my list is called directly from any add-on node. That doesn't mean you might not use EXTRA_PACKAGES= to satisfy dependencies that an add-on node might have, in the same way as eudev-dev is a dependency for Bluetooth nodes on the Pi.

I hope this explanation makes sense and you see that "packages" and "add-on nodes" aren't interchangeable concepts.

That said, the only reason why there isn't also an ADD_ON_NODES= variable to complement EXTRA_PACKAGES= is historical. The menu provides a (limited) list of nodes for users to pick from and it generates one RUN command for each selected node. There is no reason why it could not have been done from the service definition. It would, in fact, solve one conundrum which is peculiar to Node-RED: it is the only container that has its Dockerfile in the services directory, rather than in .templates. That's because, implicitly, that Dockerfile is user-specific so it needs to be editable and excluded from the git scope. All the other Dockerfiles are "factory" (every user gets the same one and there's no need for them to be editable).

On the other hand, if you have a lot of add-on nodes, it'd be a long line in the compose file so, on balance, it's probably right the way it is.