S6-Overlay Supervisor

[RaymondMouthaan]

Add S6-Overlay process supervisor to the NR Docker images. This allows Node-RED to run as a daemon and adds more control of environment vars, permissions, uid / gid etc etc.

[dceejay]

Why do we want this ?

[knolleary]

The question is why do we want this? I've never heard of it before and we need to fully understand what it is and what benefits it brings. What is wrong with the current image that requires adopting something like this?

I am instantly wary of adding additional complexity and external dependencies without a full understanding of why.

[RaymondMouthaan]

S6-Overlay can be compared to Linux systemd, however Alpine doesn't supply systemd in their images. With S6-Overlay installed (+/- 2 MB) in the Node-RED images it's easy to check environment variables like NODE_RED_ENABLE_SAFE_MODE, NODE_RED_ENABLE_PROJECTS and possibly up coming NODE_DEBUG, and others that might come, before they are applied to Node-RED.
Also using S6 makes it possible to fix attribute / permissions inside the container and allows to let the user decide which uid / gid Node-RED runs on. Another ability S6 can give is to let users install additional Alpine packages inside the container without logging into the container with docker exec, instead they can give a list of packages they like to install and they get installed before Node-RED starts. This list can be provide via an environment variable in the docker run command or docker compose / stack file.
Since Node-RED runs as a service with S6, another feature could be to allow users to restart Node-RED from within the Node-RED editor with a button, without restarting the whole container.

S6 uses a simple folder structure and stages to add scripts to control the container and the application(s) it is hosting. All these files will be kept in /root in the GitHub repo. Docker projects like hassio-addons and docker-homebridge use S6.

More details can be found here, hope this gives you guys an idea of the advanced to add S6 :)

[rcarmo]

Hello there.

I'd like to add my vote for this, or something similar. I've been maintaining my own Node-RED docker images because I need two things:

• Control of the UID/GID the Node-RED process runs under, so that /data can have sane permissions outside the container
• Control of where nodes are installed (I want them installed inside /data and not under /usr/src/node-red, and owned by that PID/GID)

I am currently using a rather gauche approach of chowning a bunch of things as the container is deployed (which slows down startup time), but am not really happy with it and would like a cleaner (preferably upstream) solution.

Allow me also to add that S6-overlay is the "golden standard" for packaging configurable services, IMHO. All the linuxserver container images use it, and it makes for very flexible service configurations all-around (I can configure everything I need for their containers under docker-compose without fiddling with external files, for instance).

[janvda]

I am also a little bit reluctant to base node-red docker images to S6-overlay. I understand it provides several good features that might be of interest for several people but is it mature enough to integrate it in node-red docker build, is it actively supported / maintained (now and also in the near future).

Also on the feature side - I am just wondering which of all those features you have mentioned that I would really use. I am not a big fan of the deployment of a docker container that is changing the UID/GID of all files on a shared volume mounted to the docker container. If there are issues with that then I think it is better that the node-red user created by the container has the proper UID/GID OR belongs to the proper group so he can read/write/delete the relevant files on the shared volume.

[rcarmo]

Two simple comebacks, since I think you’re misunderstanding both the issues you are discussing:

1. s6-overlay is used by hundreds of container images, and a very mature thing. Do check out what linuxserver.io does and how.

2. my having to change the UID/GID of files is a workaround because NPM and Yarn insist on having write access to /usr/local or similar (it is a pain to get them to install things where I want to) and also because Node-RED does not apparently (other than for projects) allow you to set where to install modules when managing the palette.

Palette operations in older versions (or without projects enabled) would fail due to permissions issues in /usr/local since the UID I set for node would be unable to write to that, even though I have a data volume for the configuration and would expect Node-RED to install any modules there. This is a separate thing that I think needs addressing/checking.

S6-overlay does not do that-it merely provides a uniform way to set UID/GIDs to run your processes inside the container, which is exactly you agree to be useful, as well as proper supervising and hooks to set up the container environment in various ways.

[janvda]

@rcarmo thanks for your feedback. I also think your problem is a valid problem so would it not be better to report your problem as a separate github issue to this repository (or maybe it is already covered in #146 ).

In the newly created issue (or #146 ) you can always refer to this issue as a potential solution for your problem.

[PrivatePuffin]

Please just don't.
S6_overlay makes it rather hard (and sometimes impossible) to apply some/most of the common-best practices for docker hardening, makes it impossible to use sane Kubernetes securityContext settings and makes it impossible to use the docker-included user settings.

It's one of the reasons k8s-at-home (the equivalent of linuxserver.io when it comes to Helm Charts) even started building their own images.

Combined with the fact that there are already great solutions (such as k8s) that already supply all the features of s6_overlay without addon layers inside of the container (hence: more securely), I think it's not a great pick for an official image.

[S-S-X]

Don't mess with or add unnecessary complexity to basic image.

Custom image with whatever service manager and extra stuff could be easily built straight from official Node-RED image.
This stuff belongs to custom flavor images.

So have like nodered/node-red:s6-overlay based on current official image instead of messing with basic Node-RED specific stuff.

Quote from s6-overlay:

The project has the following goals:

• Be usable on top of any Docker image
• Make it easy to create new images, that will operate like any other images
• Provide users with a turnkey s6 installation that will give them a stable pid 1, a fast and orderly init sequence and shutdown sequence, and the power of process supervision and automatically rotated logs.

From this it seems like s6-overlay also supports, or at least aims to support, adding it on top of any existing image.
So automated builds for s6-overlay tagged image flavor should be easy to add without affecting current builds.