Cloud deployment of Node-RED flow

Node-RED is a widely used tool for building Industrial IoT applications to collect, analyze and visualize sensor or image data on the browser user interface. In the general way of using the Node-RED dashboard, there are two user interfaces in the same Node-RED. The first is the Flow Editor, which is used to define the flow. The other is the Node-RED Dashboard, which is used to visualize data for users. Both UIs are provided from the different HTTP endpoints running on the same development environment.

Development environment vs production environment

In the proof-of-concept phase, the single environment on a local PC may be more useful than the separate environment because developers can quickly fix the flow if they find a bug in the flow or come up with a new improvement idea. But after the developed application is released to the production environment, the single environment becomes a problem because the flow does not need to be changed. Especially in the cloud environment, the default Node-RED settings sometimes lead to a loss of flow because, when the application is restarted or crashed, the cloud-native application’s file system is initialized to the state when the application was deployed. To prevent this situation, I often see the flow editor protection through user authentication or read-only settings of the flow editor settings.

Ideally, it’s the best way to disable the flow editor and provide only the dashboard UI in the production environment. In addition, this flow should be deployable and scalable to multiple instances, just like the general cloud-native applications. To achieve this, this article explains how to modify the Node-RED project to run as a single application. Once the application is uploaded to the Git repository, the flow developers can easily adapt it by making a few settings on the GitHub website. For ease of explanation, I used the GitHub Codespases environment to run the Node-RED application instead of the PaaS environments.

Importing the GitHub repository

First, you need to create a GitHub repository and upload the flow to it. See the previous article for these instructions. This time, we will use the import page in GitHub to copy and use the uploaded repository for the flow of the image recognition application.

Import page: https://github.com/new/import

After opening the import page from the above URL, fill in the dialog as follows.

• Your old repository’s clone URL: https://github.com/kazuhitoyokoi/tensorflowjs-app.git
• Repository name: tensorflowjs-app-deploy
• Type: Private

The old repository has the Node-RED flow of the image recognition application. This application captures the image from the web camera and then outputs the recognized object name to the dashboard user interface. The repository contains not only the Node-RED flow but also the package.json and README.md files that are uploaded by the flow editor.

The repository name is the new name to import the repository. I typed tensorlfowjs-app-deploy, but another name is also accepted for the repository name. The last one is the repository type. Private is recommended in the Git integration functionality because the Node-RED flow sometimes contains credentials in it. After entering all the items, click the Begin import button to copy the original repository to the new repository under your GitHub account.

On the imported repository, the next step is to edit the package.json file among these files.

Changing the application settings

The package.json file is the common file used to define Node.js application information such as application name, description, and version number. The dependencies section of the imported package.json file contains the dependent node modules which are used in the flow. For example, the node-red-contrib-tensorflow module is used to classify image data using the TensorFlow.js engine. The node-red-node-ui-webcam and node-red-dashboard modules are dashboard UI components for taking a photo with a connected web camera and displaying the result of image recognition. Since these modules are defined with version numbers in the dependencies section of the package.json file, flow can use the exact node modules in both production and development environments without any version mismatch between flow and used nodes.

To enable a single application, click the pencil button with the Edit this file tooltip on the package.json page.

Next, we need to add the following lines highlighted by the red rectangles on the text editor.

The first one is the following line, which contains the node-red npm module with the version number that the flow will run.

"node-red": "3.0.2",

With this definition, a single application can use the Node-RED execution runtime inside the application.

The second rectangle highlighted the following three lines for the startup definition of the application in the scripts section.

"scripts": {
    "start": "node-red -D httpAdminRoot=false -D ui.path=/"
},

By adding the start setting, Node.js can run the Node.js application using the npm start command after the dependency modules have been installed using the npm install command. As you can see in the screenshot above, the node-red command is defined with the two command line options, -D httpAdminRoot=false and -D ui.path=/. The -D option is used to override definitions in the Node-RED configuration file, known as the settings.js file. The httpAdminRoot is used to specify whether or not to provide the flow editor endpoint. For the single application case, the setting is false to prevent access to the flow editor in the production environment. Another setting, ui.path, is the HTTP endpoint path for the dashboard. Since the dashboard UI path is /ui by default, the setting is / to replace the flow editor path with the dashboard UI path. After starting Node-RED with these configurations, users can access the dashboard UI from the root path of the application.

The final action after editing the package.json file is to click the green Commit changes... button located in the top right corner.

Configuring to launch on GitHub Codespaces

The GitHub Codespaces is the cloud-hosted environment for developing software code using a browser-based editor. If you have a GitHub account, you can use the environment for up to 60 hours per month for free. In addition to Visual Studio Code, the service provides a Node.js execution environment for testing applications.

To automatically run the application when accessing the GitHub Codespaces, the devcontainer.json file should be added under the .devcontainer directory inside the GitHub repository. First, click the Add file button on the repository page, and then, select the Create new file item.

After opening the following text editor for the new file, you need to enter two things in the browser.

First, add the following file path to the path area described by the upper red rectangle.

.devcontainer/devcontainer.json

Then add the following JSON data as the file content.

{
  "postAttachCommand": {
    "server": "npm start"
  }
}

As you can see, this is the configuration file to run the npm start command on the GitHub Codespases environment.

Launching the application on GitHub Codespaces

All settings are done. Let’s run the image recognition application on the GitHub Codespaces. To open the GitHub Codespaces, click the Code button on the repository page, and then, click the Create codespace on main button on the pop-up menu.

After a few minutes, the GitHub Codespace environment will automatically install the dependency node modules, and display the following dialog which says Your application running on port 1880 is available..

If the dialog does not appear automatically, please type the npm start command in the terminal area to start the application manually. Finally, click the green Open in Browser button on the dialog to open the dashboard interface.

The dashboard UI above contains two user interfaces, the capturing photo area, and the result area. After clicking the camera button, the UI displays the object name in the image and the image annotation with a transparent orange rectangle.

Deleting a workspace on GitHub Codespaces

The free period of the GitHub Codespaces is limited to a maximum of 60 hours per month. Therefore, it is better to delete the application when you no longer need it.

You can delete the workspace from the pop-up menu of the green Code button in the repository.

Conclusion

In this article, I introduced the procedures for modifying the Node-RED application as a single application. I then explained how to launch the application on GitHub Codespaces as an example of the execution environment. By following these guidelines, flow developers can effectively deploy and manage their Node-RED flows in a cloud-native and scalable manner. You can now also deploy your Node-RED flow as a single application in the PaaS environments such as AWS Elastic Beanstalk and Azure Web Apps. Please try this method on the production environment for your applications.