20220708 Node-RED - master branch - PR 1 of 2

Adopts build-argument syntax in the template service definition +
template Dockerfile to pass an image tag plus an optional list of
extra packages to the Dockerfile at build time.

Pinning to a specific base image can now be accomplished in the Compose
file. This places Node-RED on equal footing with containers that do not
use local Dockerfiles (and Mosquitto which already has similar
build-argument syntax).

Together, the changes mean user customisations to the first part of the
Dockerfile are no longer at risk of being overwritten by menu runs to
change the list of add-on nodes.

For any given IOTstack installation, there is some possibility of a
hybrid result, depending on how and when the user runs the menu, or
which techniques each user employs to manage their Compose file and
Node-RED Dockerfile. The intention is to either fail safe or at least
fail sensibly:

* old Compose + old Dockerfile = no change.
* old Compose + new Dockerfile will adopt `latest` so `node.js` *may*
change from 12.x to 14.x on the next `--build` but this will depend on
whether the user ever explicitly set `latest-14` in their old Dockerfile.
* new Compose + old Dockerfile = no change. The service definition build
arguments will be ignored and the user may be confused until consulting
the documentation, but the container will still build as before.
* new Compose + new Dockerfile will behave as per the revised
documentation. Absent any user changes to the service definition, the
resulting container will be based on `latest` (which implies `node.js`
14.x) and there will no packages other than `eudev-dev` (the existing
Dockerfile default).

Worst case is an existing user adopting all-new syntax without realising
the old Dockerfile specified `latest-12`, thereby advancing to `node.js`
14.x unexpectedly, perhaps also losing additional packages along the
way. The fix is to specify `DOCKERHUB_TAG=latest-12`, append any lost
packages to `EXTRA_PACKAGES=`, and rebuild.

Personally, I switched to `-14` a good six months ago. It worked
out-of-the-box with zero migration issues and I've never looked back.
While that's only n=1, I don't feel there's sufficient risk to warrant
IOTstack continuing to default to `-12`. We have to change sometime, or
we'll be back where we were when images based on `-10` were no longer
being offered as Node-RED marched forward.

Using `node.js` version 14 is the implicit recommendation (ie `latest`
and `latest-14` are currently synonyms). Version 16 is available but is
known to throw up some migration issues. IOTstack started defaulting to
version 12 in March 2021 (when version 10 was deprecated).

Signed-off-by: Phill Kelley <[email protected]>

Author: Paraphraser

.templates/nodered/Dockerfile.template

@@ -1,6 +1,25 @@
-FROM nodered/node-red:latest-12
+# 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
+ENV EXTRA_PACKAGES=${EXTRA_PACKAGES}
+
+# default user is node-red - need to be root to install packages
 USER root
-RUN apk update && apk add --no-cache eudev-dev
+
+# install packages
+RUN apk update && apk add --no-cache eudev-dev ${EXTRA_PACKAGES}
+
+# switch back to default user
 USER node-red
 
+# variable not needed inside running container
+ENV EXTRA_PACKAGES=
+
+# add-on nodes follow
+
 %run npm install modules list%

.templates/nodered/service.yml

@@ -1,6 +1,10 @@
 nodered:
   container_name: nodered
-  build: ./services/nodered/.
+  build:
+    context: ./services/nodered/.
+    args:
+    - DOCKERHUB_TAG=latest
+    - EXTRA_PACKAGES=
   restart: unless-stopped
   user: "0"
   environment: