Node-RED - Flow-based programming for the Internet of Things
-
@staypath Usually, we keep the code in Cloudron read-only. As a convention, the code is placed in
/app/code. The data the app generates is put in/app/dataand this is backed up. The idea is when we have an update, we can just throw out the old container, replace it with the new container, keep /app/data alone as-is (it's mounted into the new container) and things will work.If the code itself is in
/app/data, then it's part of the backup and also the update path is not clear. All the operations like backup/clone etc will work. Only update is an issue. Do you have any idea how to solve this?One idea, if it's possible, is to put node-red code and npm install in /app/code in the Dockerfile. For additional plugins, if we can set some node module path which can be picked up from say /app/data/node_modules or something, that would be ideal. Is that possible though?
-
@girish Ok, I understand a bit more about the Cloudron build process now. I have updated my Dockerfile.cloudron and moved the repo here:
https://github.com/jsonsmth/node-red-docker-cloudron
The updated build process stores all app code in /app/code and only the user-specific data (including user node_modules) in /app/data.
-
I have updated the repo here with built-in LDAP auth:
-
Repo has been updated to include the following:
- split the Dockerfile into
Dockerfile.cloudronandstart.shto match Cloudron app standards - built-in LDAP auth
I've tested backup,restore and package upgrade.
https://github.com/jsonsmth/node-red-docker-cloudron
Thanks!
- split the Dockerfile into
-
I've been working on a Cloudron-app for Node-RED as well. Using node-red-docker and adapting it to Cloudron felt too complicated to me. So, as opposed to the app package that @staypath has been working on, I started with a Cloudron package from scratch.
You can find my repo here: https://git.vereint-digital.de/hendrik/node-red-app
Node-RED itself is simply installed through npm, so the code does not come bundled in the repo itself. Since Node-RED does rely on npm quite a lot anyhow, that seemed more straightforward to me. Plus it makes the Dockerfile really simple.
The code of Node-RED itself (including three modules that are installed out of the box) is located in /app/code. The node-red userdir is in /app/data. So updates of node-red should work, but I've not been testing it long enough to tell.
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
I must say though, that I do not feel too confident about my solution to send mails. I initially thought, that it would be easier to utilize a command line mail utility, but it turned out to be quite complex as well. In the end, I had to write my own script to act as mail utility, so that it matches the assumptions of node-red-contrib-sendmail. Writing a custom Node-RED module that uses Nodemailer and accesses the Cloudron environment variables probably would have been a better approach.
For authorization, I currently use Cloudron proxyauth and only leave one route (/public) unprotected. Since custom user authentication can be implemented in Node-RED quite easily, it would be highly beneficial to have the authenticated user as part of the request headers, as discussed here. Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
I hope this is helpful to others, who want to use Node-RED on Cloudron. And maybe we get the discussion on including Node-RED in the app-store going again.
-
@hendrikvl This is awesome! Thanks for working on this.
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
Nice, as expected of any cloudron app email and db are auto-configured.
Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows? When LDAP is implemented, who provides the login page? Is this part of some plugin?
-
@girish said in Node-RED - Flow-based programming for the Internet of Things:
The app package uses the Cloudron sendmail and mongodb addons. Mails can be sent using node-red-contrib-sendmail and the database can be accessed using node-red-contrib-mongodb4. Both modules come preinstalled and are preconfigured using the environment variables that Cloudron exports.
Nice, as expected of any cloudron app email and db are auto-configured.
Both are not required to run Node-RED though. They are optional modules that can be used within flows that one wants to implement, but have no functionality for the core itself. Still, I thought that its useful to be able to access the functionality that Cloudron as a platform provides.Implementing LDAP, as @staypath has done, also has its benefits though. I'm currently a bit indecisive which approach is preferable.
Does node-red have a real concept of users and roles ? Meaning, can individual users create and manage separate flows?
I'm relatively new to Node-RED myself and can't tell with certainty. As far as I understand the documentation, one can differentiate between users and assign specific permissions for different methods of the API (create a flow, enable a module, etc.), but cannot differentiate between flows. Flows seem to be shared between users in any case. So it's not a real multi-user application, where each user can create their own flows. This post proposes to run multiple node-red instances if users shall be able to create independent flows.When LDAP is implemented, who provides the login page? Is this part of some plugin?
The login page seems to be the default one provided by Node-RED. It is only the authentication-scheme which is plugged in through an extra module.The LDAP-module does not seem to support different permissions though. Each user with valid credentials gets full permissions (see this line).
-
-
Been a while since I built the Docker version of Node-RED for Cloudron, but it worked with Cloudron LDAP auth when I built it. My method had a single admin user that can access all Node-RED flows, so there's no concept of permissions. That works fine for me, but might not for others. I'd be willing to revisit and update my method to the latest Node-RED version to make sure everything still functions within Cloudron from a backup/restore perspective and with LDAP auth. I know @hendrikvl recommended using the npm approach vs. Docker approach, so it really depends on your needs.
-
Actually, looking at @hendrikvl version here: https://git.vereint-digital.de/hendrik/node-red-app. This approach seems simpler for sure. @hendrikvl is there any core Node-RED functionality missing using your method?
-
@staypath Yes, I tried to keep things simple with my approach. I am not aware of any Node-RED core functionality that is not working. By using the Cloudron proxy as auth in front of Node-RED, it is single user only though and would be tricky to combine it with auth-mechanisms within Node-RED. This is probably the biggest downside to my approach.
Another thing, that I would do differently is the approach to send out e-mails. I wanted to make use of the per-app smtp settings that Cloudron provides and pre-provision that transparently into Node-RED. That lead to quite some "glue" in between that seemed somewhat disproportionate in the end.
I should update my repository to a newer Node-RED version by the way and will probably remove the e-mail part at that point.
