Skip to content

Commit 5ead4c0

Browse files
author
Dave Conway-Jones
committedOct 7, 2019
Update docker.md to match project README
versio 1.0.1 and latest dock updates
1 parent c041069 commit 5ead4c0

File tree

1 file changed

+142
-197
lines changed

1 file changed

+142
-197
lines changed
 

‎docs/getting-started/docker.md

+142-197
Original file line numberDiff line numberDiff line change
@@ -16,35 +16,35 @@ As of Node-RED 1.0 this project provides the build for the `nodered/node-red` co
1616
Previous 0.20.x versions are still available at https://hub.docker.com/r/nodered/node-red-docker.
1717

1818
### Quick Start
19-
To run this directly in Docker in its simplest form just run:
19+
To run in Docker in its simplest form just run:
2020

2121
docker run -it -p 1880:1880 --name mynodered nodered/node-red
2222

2323
Let's dissect that command:
2424

25-
docker run - run this container... and build locally if necessary first.
25+
docker run - run this container... initially building locally if necessary
2626
-it - attach a terminal session so we can see what is going on
2727
-p 1880:1880 - connect local port 1880 to the exposed internal port 1880
2828
--name mynodered - give this machine a friendly local name
29-
nodered/node-red - the image to base it on - currently Node-RED v1.0.0
29+
nodered/node-red - the image to base it on - currently Node-RED v1.0.1
3030

3131

3232
Running that command should give a terminal window with a running instance of Node-RED.
3333

3434
Welcome to Node-RED
3535
===================
3636

37-
10 Aug 12:57:10 - [info] Node-RED version: v1.0.0
38-
10 Aug 12:57:10 - [info] Node.js version: v10.16.2
39-
10 Aug 12:57:10 - [info] Linux 4.19.58-v7+ arm LE
40-
10 Aug 12:57:11 - [info] Loading palette nodes
41-
10 Aug 12:57:16 - [info] Settings file : /data/settings.js
42-
10 Aug 12:57:16 - [info] Context store : 'default' [module=memory]
43-
10 Aug 12:57:16 - [info] User directory : /data
44-
10 Aug 12:57:16 - [warn] Projects disabled : editorTheme.projects.enabled=false
45-
10 Aug 12:57:16 - [info] Flows file : /data/flows.json
46-
10 Aug 12:57:16 - [info] Creating new flow file
47-
10 Aug 12:57:17 - [warn]
37+
03 Oct 12:57:10 - [info] Node-RED version: v1.0.1
38+
03 Oct 12:57:10 - [info] Node.js version: v10.16.3
39+
03 Oct 12:57:10 - [info] Linux 4.9.184-linuxkit x64 LE
40+
03 Oct 12:57:11 - [info] Loading palette nodes
41+
03 Oct 12:57:16 - [info] Settings file : /data/settings.js
42+
03 Oct 12:57:16 - [info] Context store : 'default' [module=memory]
43+
03 Oct 12:57:16 - [info] User directory : /data
44+
03 Oct 12:57:16 - [warn] Projects disabled : editorTheme.projects.enabled=false
45+
03 Oct 12:57:16 - [info] Flows file : /data/flows.json
46+
03 Oct 12:57:16 - [info] Creating new flow file
47+
03 Oct 12:57:17 - [warn]
4848

4949
---------------------------------------------------------------------
5050
Your flow credentials file is encrypted using a system-generated key.
@@ -58,17 +58,20 @@ Running that command should give a terminal window with a running instance of No
5858
file using your chosen key the next time you deploy a change.
5959
---------------------------------------------------------------------
6060

61-
10 Aug 12:57:17 - [info] Server now running at http://127.0.0.1:1880/
61+
03 Oct 12:57:17 - [info] Starting flows
62+
03 Oct 12:57:17 - [info] Started flows
63+
03 Oct 12:57:17 - [info] Server now running at http://127.0.0.1:1880/
6264

6365
[...]
6466

6567
You can then browse to `http://{host-ip}:1880` to get the familiar Node-RED desktop.
6668

67-
The advantage of doing this is that by giving it a name we can manipulate it
69+
The advantage of doing this is that by giving it a name (mynodered) we can manipulate it
6870
more easily, and by fixing the host port we know we are on familiar ground.
69-
(Of course this does mean we can only run one instance at a time... but one step at a time folks...)
71+
Of course this does mean we can only run one instance at a time... but one step at a time folks...
7072

71-
If we are happy with what we see we can detach the terminal with `Ctrl-p` `Ctrl-q` - the container will keep running in the background.
73+
If we are happy with what we see, we can detach the terminal with `Ctrl-p` `Ctrl-q` - the
74+
container will keep running in the background.
7275

7376
To reattach to the terminal (to see logging) run:
7477

@@ -82,10 +85,6 @@ and stop it again when required:
8285

8386
$ docker stop mynodered
8487

85-
_**Note**: this Dockerfile is configured to store the flows.json file and any
86-
extra nodes you install "outside" of the container. We do this so that you may rebuild the underlying
87-
container without permanently losing all of your customisations._
88-
8988
### Image Variations
9089
The Node-RED images come in different variations and are supported by manifest lists (auto-detect architecture).
9190
This makes it more easy to deploy in a multi architecture Docker environment. E.g. a Docker Swarm with mix of Raspberry Pi's and amd64 nodes.
@@ -100,163 +99,160 @@ The tag naming convention is `<node-red-version>-<node-version>-<image-type>-<ar
10099

101100
The minimal versions (without python and build tools) are not able to install nodes that require any locally compiled native code.
102101

102+
For example - to run the latest minimal version, you would run
103+
```
104+
docker run -it -p 1880:1880 --name mynodered nodered/node-red:latest-minimal
105+
```
106+
103107
The Node-RED images are based on [official Node JS Alpine Linux](https://hub.docker.com/_/node/) images to keep them as small as possible.
104108
Using Alpine Linux reduces the built image size, but removes standard dependencies that are required for native module compilation. If you want to add dependencies with native dependencies, extend the Node-RED image with the missing packages on running containers or build new images see [docker-custom](docker-custom/README.md).
105109

106110
The following table shows the variety of provided Node-RED images.
107111

108112
| **Tag** |**Node**| **Arch** | **Python** |**Dev**| **Base Image** |
109113
|----------------------------|--------|----------|------------|-------|------------------------|
110-
| 1.0.0-10-amd64 | 10 | amd64 | 2.x 3.x | yes | amd64/node:10-alpine |
111-
| 1.0.0-10-arm32v6 | 10 | arm32v6 | 2.x 3.x | yes | arm32v6/node:10-alpine |
112-
| 1.0.0-10-arm32v7 | 10 | arm32v7 | 2.x 3.x | yes | arm32v7/node:10-alpine |
113-
| 1.0.0-10-arm64v8 | 10 | arm64v8 | 2.x 3.x | yes | arm64v8/node:10-alpine |
114+
| 1.0.1-10-amd64 | 10 | amd64 | 2.x 3.x | yes | amd64/node:10-alpine |
115+
| 1.0.1-10-arm32v6 | 10 | arm32v6 | 2.x 3.x | yes | arm32v6/node:10-alpine |
116+
| 1.0.1-10-arm32v7 | 10 | arm32v7 | 2.x 3.x | yes | arm32v7/node:10-alpine |
117+
| 1.0.1-10-arm64v8 | 10 | arm64v8 | 2.x 3.x | yes | arm64v8/node:10-alpine |
114118
| | | | | | |
115-
| 1.0.0-10-minimal-amd64 | 10 | amd64 | no | no | amd64/node:10-alpine |
116-
| 1.0.0-10-minimal-arm32v6 | 10 | arm32v6 | no | no | arm32v6/node:10-alpine |
117-
| 1.0.0-10-minimal-arm32v7 | 10 | arm32v7 | no | no | arm32v7/node:10-alpine |
118-
| 1.0.0-10-minimal-arm64v8 | 10 | arm64v8 | no | no | arm64v8/node:10-alpine |
119+
| 1.0.1-10-minimal-amd64 | 10 | amd64 | no | no | amd64/node:10-alpine |
120+
| 1.0.1-10-minimal-arm32v6 | 10 | arm32v6 | no | no | arm32v6/node:10-alpine |
121+
| 1.0.1-10-minimal-arm32v7 | 10 | arm32v7 | no | no | arm32v7/node:10-alpine |
122+
| 1.0.1-10-minimal-arm64v8 | 10 | arm64v8 | no | no | arm64v8/node:10-alpine |
119123

120124

121125
| **Tag** |**Node**| **Arch** | **Python** |**Dev**| **Base Image** |
122126
|----------------------------|--------|----------|------------|-------|------------------------|
123-
| 1.0.0-12-amd64 | 12 | amd64 | 2.x 3.x | yes | amd64/node:12-alpine |
124-
| 1.0.0-12-arm32v6 | 12 | arm32v6 | 2.x 3.x | yes | arm32v6/node:12-alpine |
125-
| 1.0.0-12-arm32v7 | 12 | arm32v7 | 2.x 3.x | yes | arm32v7/node:12-alpine |
126-
| 1.0.0-12-arm64v8 | 12 | arm64v8 | 2.x 3.x | yes | arm64v8/node:12-alpine |
127+
| 1.0.1-12-amd64 | 12 | amd64 | 2.x 3.x | yes | amd64/node:12-alpine |
128+
| 1.0.1-12-arm32v6 | 12 | arm32v6 | 2.x 3.x | yes | arm32v6/node:12-alpine |
129+
| 1.0.1-12-arm32v7 | 12 | arm32v7 | 2.x 3.x | yes | arm32v7/node:12-alpine |
130+
| 1.0.1-12-arm64v8 | 12 | arm64v8 | 2.x 3.x | yes | arm64v8/node:12-alpine |
127131
| | | | | | |
128-
| 1.0.0-12-minimal-amd64 | 12 | amd64 | no | no | amd64/node:12-alpine |
129-
| 1.0.0-12-minimal-arm32v6 | 12 | arm32v6 | no | no | arm32v6/node:12-alpine |
130-
| 1.0.0-12-minimal-arm32v7 | 12 | arm32v7 | no | no | arm32v7/node:12-alpine |
131-
| 1.0.0-12-minimal-arm64v8 | 12 | arm64v8 | no | no | arm64v8/node:12-alpine |
132+
| 1.0.1-12-minimal-amd64 | 12 | amd64 | no | no | amd64/node:12-alpine |
133+
| 1.0.1-12-minimal-arm32v6 | 12 | arm32v6 | no | no | arm32v6/node:12-alpine |
134+
| 1.0.1-12-minimal-arm32v7 | 12 | arm32v7 | no | no | arm32v7/node:12-alpine |
135+
| 1.0.1-12-minimal-arm64v8 | 12 | arm64v8 | no | no | arm64v8/node:12-alpine |
132136

133-
- All images have bash, tzdata, nano, curl git and openssl tools pre-installed to support Node-REDs Projects feature.
137+
- All images have bash, tzdata, nano, curl git and openssl tools pre-installed to support Node-RED's Projects feature.
134138

135139
### Manifest Lists
136140
The following table shows the provided Manifest Lists.
137141

138142
| **Tag** | **Node-RED Base Image** |
139143
|----------------------------------------|--------------------------------------------|
140-
| latest, 1.0.0, | nodered/node-red:1.0.0-10-amd64 |
141-
| latest-10, 1.0.0-10 | nodered/node-red:1.0.0-10-arm32v6 |
142-
| | nodered/node-red:1.0.0-10-arm32v7 |
143-
| | nodered/node-red:1.0.0-10-arm64v8 |
144+
| latest, 1.0.1, | nodered/node-red:1.0.1-10-amd64 |
145+
| latest-10, 1.0.1-10 | nodered/node-red:1.0.1-10-arm32v6 |
146+
| | nodered/node-red:1.0.1-10-arm32v7 |
147+
| | nodered/node-red:1.0.1-10-arm64v8 |
144148
| | |
145-
| latest-minimal, 1.0.0-minimal, | nodered/node-red:1.0.0-10-amd64-minimal |
146-
| latest-10-minimal, 1.0.0-10-minimal | nodered/node-red:1.0.0-10-arm32v6-minimal |
147-
| | nodered/node-red:1.0.0-10-arm32v7-minimal |
148-
| | nodered/node-red:1.0.0-10-arm64v8-minimal |
149+
| latest-minimal, 1.0.1-minimal, | nodered/node-red:1.0.1-10-amd64-minimal |
150+
| latest-10-minimal, 1.0.1-10-minimal | nodered/node-red:1.0.1-10-arm32v6-minimal |
151+
| | nodered/node-red:1.0.1-10-arm32v7-minimal |
152+
| | nodered/node-red:1.0.1-10-arm64v8-minimal |
149153

150154
| **Tag** | **Node-RED Base Image** |
151155
|----------------------------------------|--------------------------------------------|
152-
| latest-12, 1.0.0-12 | nodered/node-red:1.0.0-12-amd64 |
153-
| | nodered/node-red:1.0.0-12-arm32v6 |
154-
| | nodered/node-red:1.0.0-12-arm32v7 |
155-
| | nodered/node-red:1.0.0-12-arm64v8 |
156+
| latest-12, 1.0.1-12 | nodered/node-red:1.0.1-12-amd64 |
157+
| | nodered/node-red:1.0.1-12-arm32v6 |
158+
| | nodered/node-red:1.0.1-12-arm32v7 |
159+
| | nodered/node-red:1.0.1-12-arm64v8 |
156160
| | |
157-
| latest-12-minimal, 1.0.0-12-minimal | nodered/node-red:1.0.0-12-amd64-minimal |
158-
| | nodered/node-red:1.0.0-12-arm32v6-minimal |
159-
| | nodered/node-red:1.0.0-12-arm32v7-minimal |
160-
| | nodered/node-red:1.0.0-12-arm64v8-minimal |
161+
| latest-12-minimal, 1.0.1-12-minimal | nodered/node-red:1.0.1-12-amd64-minimal |
162+
| | nodered/node-red:1.0.1-12-arm32v6-minimal |
163+
| | nodered/node-red:1.0.1-12-arm32v7-minimal |
164+
| | nodered/node-red:1.0.1-12-arm64v8-minimal |
161165

162166
With the support of Docker manifest list, there is no need to explicitly add the tag for the architecture to use.
163167
When a docker run command or docker service command or docker stack command is executed, docker checks which architecture is required and verifies if it is available in the docker repository. If it does, docker pulls the matching image for it.
164168

165169
Therefore all tags regarding Raspberry PI's are dropped.
166170

167-
For example: suppose you are running on a Raspberry PI 3B, which has arm32v7 as architecture. Then just run the following command to pull the image (tagged by `1.0.0-10-arm32v7`), and run the container.
171+
For example: suppose you are running on a Raspberry PI 3B, which has arm32v7 as architecture. Then just run the following command to pull the image (tagged by `1.0.1-10-arm32v7`), and run the container.
168172
```
169173
docker run -it -p 1880:1880 --name mynodered nodered/node-red:latest
170174
```
171175

172-
The same command can be used for running on an amd64 system, since docker discovers its running on a amd64 host and pulls the image with the matching tag (`1.0.0-10-amd64`).
176+
The same command can be used for running on an amd64 system, since docker discovers its running on a amd64 host and pulls the image with the matching tag (`1.0.1-10-amd64`).
173177

174178
This gives the advantage that you don't need to know/specify which architecture you are running on and makes docker run commands and docker compose files more flexible and exchangeable across systems.
175179

176180
### Raspberry PI - native GPIO support
177-
| BREAKING: Native GPIO support for Raspberry PI has been dropped! |
181+
| v1.0 - BREAKING: Native GPIO support for Raspberry PI has been dropped |
178182
| --- |
179183
The replacement for native GPIO is [node-red-node-pi-gpiod](https://github.com/node-red/node-red-nodes/tree/master/hardware/pigpiod).
180184

181185
Disadvantages of the native GPIO support are:
182186
- Your Docker container needs to be deployed on the same Docker node/host on which you want to control the gpio.
183-
- Gain access to /dev/mem of your Docker node/host
187+
- Gain access to `/dev/mem` of your Docker node/host
184188
- privileged=true is not supported for `docker stack` command
185189

186-
`node-red-node-pi-gpiod` solves all these disadvantages. With `node-red-node-pi-gpiod` it is possible to interact with gpio of multiple Raspberry Pi's from a single Node-RED container, and for multiple containers to access different gpio on the same Pi.
190+
`node-red-node-pi-gpiod` fixes all these disadvantages. With `node-red-node-pi-gpiod` it is possible to interact with gpio of multiple Raspberry Pi's from a single Node-RED container, and for multiple containers to access different gpio on the same Pi.
187191

188192
#### Quick Migration steps to `node-red-node-pi-gpiod`
189-
1. Install `node-red-node-pi-gpiod` through the Node-RED pallette
193+
1. Install `node-red-node-pi-gpiod` through the Node-RED palette
190194
2. Install and run `PiGPIOd daemon` on the host Pi.
191195
3. Replace all native gpio nodes with `pi gpiod` nodes.
192-
4. Configure `pi gpiod` nodes to connect to `PiGPIOd daemon`
196+
4. Configure `pi gpiod` nodes to connect to `PiGPIOd daemon`. Often the host machine will have an IP 172.17.0.1 port 8888 - but not always. You can use `docker exec -it mynodered ip route show default | awk '/default/ {print $3}'` to check.
193197

194-
For install instruction details please refer to the `node-red-node-pi-gpiod` [README](https://github.com/node-red/node-red-nodes/tree/master/hardware/pigpiod#node-red-node-pi-gpiod)
198+
For detailed install instruction please refer to the `node-red-node-pi-gpiod` [README](https://github.com/node-red/node-red-nodes/tree/master/hardware/pigpiod#node-red-node-pi-gpiod)
195199

196-
### Host Directory As Volume (Persistent)
197-
To save your Node-RED user directory inside the container to a host directory outside the container, you can use the command below.
198-
But to allow access to this host directory, the node-red user (default uid=1000) inside the container must have the same uid as the owner of the host directory.
199-
To override the default uid and gid of the node-red user inside the the container you can use the option `--user="<my_host_uid>:<my_host_gid>"`:
200200

201-
```
202-
$ docker run -it --user="<my_host_uid>:<my_host_gid>" -p 1880:1880 -v <host_directory>:/data --name mynodered nodered/node-red
203-
```
201+
### Managing User Data
204202

205-
Example:
206-
- Suppose you are running on a Raspberry PI with a user named 'pi' and group 'pi'.
207-
```
208-
$ whoami
209-
```
210-
- With this user create a directory '~/.node-red'.
211-
```
212-
$ mkdir ~/.node-red
213-
```
214-
- Verify newly created directory with:
215-
```
216-
$ ls -al ~/.node-red
217-
```
218-
This shows that user pi is owner of this directory:
219-
```
220-
ls -al ~/.node-red
221-
total 8
222-
drwxr-xr-x 2 pi pi 4096 May 7 20:55 .
223-
drwxr-xr-x 8 pi pi 4096 May 7 20:42 ..
224-
```
203+
Once you have Node-RED running with Docker, we need to
204+
ensure any added nodes or flows are not lost if the container is destroyed.
205+
This user data can be persisted by mounting a data directory to a volume outside the container.
206+
This can either be done using a bind mount or a named data volume.
225207

226-
- Now we want to have access to this '~/.node-red' directory with the container so that Node-RED can save user data to it.
227-
As we know we need to override the default uid (1000) of the node-red user inside the container with the uid of the pi user.
228-
For that we need to know the uid of user pi:
229-
```
230-
$ id pi
231-
```
232-
- The uid and gid of user pi are:
233-
```
234-
uid=1000(pi) gid=1000(pi) [...]
235-
```
208+
Node-RED uses the `/data` directory inside the container to store user configuration data.
236209

237-
- So the final command becomes:
210+
#### Using a Host Directory for Persistence (Bind Mount)
211+
To save your Node-RED user directory inside the container to a host directory outside the container, you can use the
212+
command below. To allow access to this host directory, the node-red user (default uid=1000) inside the container must
213+
have the same uid as the owner of the host directory.
238214
```
239-
$ docker run -it --user="1000:1000" -p 1880:1880 -v ~/.node-red:/data --name mynodered nodered/node-red
215+
docker run -it -p 1880:1880 -v /home/pi/.node-red:/data --name mynodered nodered/node-red
240216
```
241217

242-
Running a Node-RED container with a host directory mounted as the data volume,
243-
you can manually run `npm install` within your host directory. Files created in
244-
the host directory will automatically appear in the container's file system.
218+
In this example the host `/home/pi/.node-red` directory is bound to the container `/data` directory.
245219

246-
Adding extra nodes to the container can be accomplished by
247-
running npm install locally.
220+
**Note**: Users migrating from version 0.20 to 1.0 will need to ensure that any existing `/data`
221+
directory has the correct ownership. As of 1.0 this needs to be `1000:1000`. This can be forced by
222+
the command `sudo chown -R 1000:1000 path/to/your/node-red/data`
248223

249-
$ cd ~/.node-red
250-
$ npm install node-red-node-smooth
251-
node-red-node-smooth@0.0.3 node_modules/node-red-node-smooth
224+
See [the wiki](https://github.com/node-red/node-red-docker/wiki/Permissions-and-Persistence) for detailed information
225+
on permissions.
226+
227+
#### Using Named Data Volumes
228+
229+
Docker also supports using named [data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/)
230+
to store persistent or shared data outside the container.
231+
232+
To create a new named data volume to persist our user data and run a new
233+
container using this volume.
234+
235+
$ docker volume create --name node_red_user_data
236+
$ docker volume ls
237+
DRIVER VOLUME NAME
238+
local node_red_user_data
239+
$ docker run -it -p 1880:1880 -v node_red_user_data:/data --name mynodered nodered/node-red
240+
241+
Using Node-RED to create and deploy some sample flows, we can now destroy the
242+
container and start a new instance without losing our user data.
243+
244+
$ docker rm mynodered
245+
$ docker run -it -p 1880:1880 -v node_red_user_data:/data --name mynodered nodered/node-red
246+
247+
### Updating
248+
249+
As the /data is now preserved outside of the container, updating the base container image
250+
is now as simple as
251+
252+
$ docker pull nodered/node-red
252253
$ docker stop mynodered
253254
$ docker start mynodered
254255

255-
_**Note** : Modules with a native dependencies will be compiled on the host
256-
machine's architecture. These modules will not work inside the Node-RED
257-
container unless the architecture matches the container's base image. For native
258-
modules, it is recommended to install using a local shell or update the
259-
project's package.json and re-build._
260256

261257
### Docker Stack / Docker Compose
262258

@@ -265,11 +261,12 @@ Please refer to the official Docker pages for more info about [Docker stack](htt
265261

266262
```
267263
################################################################################
268-
# Node-Red Stack
264+
# Node-RED Stack or Compose
269265
################################################################################
270-
#$ docker stack deploy node-red --compose-file docker-compose-node-red.yml
266+
# docker stack deploy node-red --compose-file docker-compose-node-red.yml
267+
# docker-compose -f docker-compose-node-red.yml -p myNoderedProject up
271268
################################################################################
272-
version: 3.7
269+
version: "3.7"
273270
274271
services:
275272
node-red:
@@ -281,11 +278,13 @@ services:
281278
networks:
282279
- node-red-net
283280
volumes:
284-
- /mnt/docker-cluster/node-red/data:/data
281+
- node-red-data
282+
283+
volumes:
284+
node-red-data:
285285
286286
networks:
287287
node-red-net:
288-
289288
```
290289

291290
The above compose file:
@@ -308,7 +307,7 @@ Docker build process, the dependencies are installed under `/usr/src/node-red`.
308307
The main sections to modify are
309308

310309
"dependencies": {
311-
"node-red": "1.0.0", <-- set the version of Node-RED here
310+
"node-red": "^1.0.1", <-- set the version of Node-RED here
312311
"node-red-dashboard": "*" <-- add any extra npm packages here
313312
},
314313

@@ -321,29 +320,33 @@ by default, and then
321320

322321
This is the command that starts Node-RED when the container is run.
323322

324-
#### startup
323+
#### Startup
325324

326325
Node-RED is started using NPM start from this `/usr/src/node-red`, with the `--userDir`
327326
parameter pointing to the `/data` directory on the container.
328327

329328
The flows configuration file is set using an environment parameter (**FLOWS**),
330329
which defaults to *'flows.json'*. This can be changed at runtime using the
331330
following command-line flag.
331+
```
332+
docker run -it -p 1880:1880 -e FLOWS=my_flows.json nodered/node-red
333+
```
332334

333-
$ docker run -it -p 1880:1880 -e FLOWS=my_flows.json nodered/node-red
335+
**Note**: If you set `-e FLOWS=""` then the flow file can be set via the *flowFile*
336+
property in the `settings.js` file.
334337

335338
Node.js runtime arguments can be passed to the container using an environment
336339
parameter (**NODE_OPTIONS**). For example, to fix the heap size used by
337340
the Node.js garbage collector you would use the following command.
341+
```
342+
docker run -it -p 1880:1880 -e NODE_OPTIONS="--max_old_space_size=128" nodered/node-red
343+
```
338344

339-
$ docker run -it -p 1880:1880 -e NODE_OPTIONS="--max_old_space_size=128" nodered/node-red
345+
Other useful environment variables include
340346

341-
### Adding Nodes
347+
- -e NODE_RED_ENABLE_SAFE_MODE=false # setting to true starts Node-RED in safe (not running) mode
348+
- -e NODE_RED_ENABLE_PROJECTS=false # setting to true starts Node-RED with the projects feature enabled
342349

343-
Installing extra Node-RED nodes into an instance running with Docker can be
344-
achieved by manually installing those nodes into the container, using the cli or
345-
running npm commands within a container shell, or mounting a host directory with
346-
those nodes as a data volume.
347350

348351
#### Node-RED Admin Tool
349352

@@ -388,76 +391,18 @@ RUN npm install node-red-contrib-flightaware
388391

389392
Alternatively, you can modify the package.json in this repository and re-build
390393
the images from scratch. This will also allow you to modify the version of
391-
Node-RED that is installed. See [README](docker-custom/README.md) under docker-custom directory.
392-
393-
### Managing User Data
394-
395-
Once you have customised the Node-RED instance running with Docker, we need to
396-
ensure these modifications are not lost if the container is destroyed. Managing
397-
this user data can be handed by persisting container state into a new image or
398-
using named data volumes to handle move this data outside the container.
399-
400-
#### Saving Changes As Custom Image
401-
402-
Modifications to files within the live container, e.g. manually adding nodes or
403-
creating flows, do not exist outside the lifetime of the container. If that
404-
container instance is destroyed, these changes will be lost.
405-
406-
Docker allows you to the current state of a container to a new image. This
407-
means you can persist your changes as a new image that can be shared on other
408-
systems.
409-
410-
$ docker commit mynodered custom-node-red
411-
412-
If we destroy the ```mynodered``` container, the instance can be recovered by
413-
spawning a new container using the ```custom-node-red``` image.
414-
415-
#### Using Named Data Volumes
416-
417-
Docker supports using [data volumes](https://docs.docker.com/engine/tutorials/dockervolumes/) to store
418-
persistent or shared data outside the container. Files and directories within data
419-
volumes exist outside of the lifecycle of containers, i.e. the files still exist
420-
after removing the container.
421-
422-
Node-RED uses the `/data` directory to store user configuration data.
423-
424-
Mounting a data volume inside the container at this directory path means user
425-
configuration data can be saved outside of the container and even shared between
426-
container instances.
427-
428-
Let's create a new named data volume to persist our user data and run a new
429-
container using this volume.
430-
431-
$ docker volume create --name node_red_user_data
432-
$ docker volume ls
433-
DRIVER VOLUME NAME
434-
local node_red_user_data
435-
$ docker run -it -p 1880:1880 -v node_red_user_data:/data --name mynodered nodered/node-red
436-
437-
Using Node-RED to create and deploy some sample flows, we can now destroy the
438-
container and start a new instance without losing our user data.
439-
440-
$ docker rm mynodered
441-
$ docker run -it -p 1880:1880 -v node_red_user_data:/data --name mynodered nodered/node-red
442-
443-
### Updating
444-
445-
Updating the base container image is as simple as
446-
447-
$ docker pull nodered/node-red
448-
$ docker stop mynodered
449-
$ docker start mynodered
394+
Node-RED that is installed. See [README](docker-custom/README.md) in the `docker-custom` directory.
450395

451396
### Running headless
452397

453398
The barest minimum we need to just run Node-RED is
454399

455-
$ docker run -d -p 1880 nodered/node-red
400+
$ docker run -d -p 1880:1880 nodered/node-red
456401

457402
This will create a local running instance of a machine - that will have some
458403
docker id number and be running on a random port... to find out run
459404

460-
$ docker ps -a
405+
$ docker ps
461406
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
462407
4bbeb39dc8dc nodered/node-red:latest "npm start" 4 seconds ago Up 4 seconds 0.0.0.0:49154->1880/tcp furious_yalow
463408
$
@@ -471,7 +416,7 @@ You can link containers "internally" within the docker runtime by using the --li
471416

472417
For example I have a simple MQTT broker container available as
473418

474-
docker run -it --name mybroker nodered/node-red
419+
docker run -it --name mybroker eclipse-mosquitto
475420

476421
(no need to expose the port 1883 globally unless you want to... as we do magic below)
477422

@@ -480,7 +425,7 @@ Then run nodered docker - but this time with a link parameter (name:alias)
480425
docker run -it -p 1880:1880 --name mynodered --link mybroker:broker nodered/node-red
481426

482427
the magic here being the `--link` that inserts a entry into the node-red instance
483-
hosts file called *broker* that links to the mybroker instance.... but we do
428+
hosts file called *broker* that links to the external mybroker instance.... but we do
484429
expose the 1880 port so we can use an external browser to do the node-red editing.
485430

486431
Then a simple flow like below should work - using the alias *broker* we just set up a second ago.
@@ -490,20 +435,20 @@ Then a simple flow like below should work - using the alias *broker* we just set
490435
This way the internal broker is not exposed outside of the docker host - of course
491436
you may add `-p 1883:1883` etc to the broker run command if you want to see it...
492437

493-
### Further Information
494438

495-
The Node-RED-Docker [project wiki](https://github.com/node-red/node-red-docker/wiki) has extra information on these and other topics.
496-
497-
### Issues
439+
### Common Issues and Hints
498440

499441
Here is a list of common issues users have reported with possible solutions.
500442

501443
#### User Permission Errors
502444

445+
See [the wiki](https://github.com/node-red/node-red-docker/wiki/Permissions-and-Persistence) for detailed information
446+
on permissions.
447+
503448
If you are seeing *permission denied* errors opening files or accessing host devices, try running the container as the root user.
504449

505450
```
506-
docker run -it -p 1880:1880 --name mynodered --user=root nodered/node-red
451+
docker run -it -p 1880:1880 --name mynodered -u root nodered/node-red
507452
```
508453

509454
References:

0 commit comments

Comments
 (0)
Please sign in to comment.