Node-RED - Flow-based programming for the Internet of Things
-
Another upvote for this app!
-
I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...
-
I'm a long-time Node-RED user. I was able to get a custom app packaged for Cloudron. So far, so good...
@staypath Very cool!
-
-
@robi Cloudron customizations are in the docker-custom folder
https://github.com/jsonsmth/node-red-docker
Feedback is welcome as this is my first foray into Cloudron app customization.
@staypath That's a good start! I haven't used node-red before but does it require "plugins" or arbitrary node modules to be installed to be usable? A quick look into your package suggests that you decided to put everything into
/app/data. Is it because of that? -
@staypath That's a good start! I haven't used node-red before but does it require "plugins" or arbitrary node modules to be installed to be usable? A quick look into your package suggests that you decided to put everything into
/app/data. Is it because of that?@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules
I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!
-
@girish Yes. Any new "plugins" installed are node modules that would be installed in /app/data/data/node_modules
I installed a couple of Node-RED modules (plugins), took a backup of the app in Cloudron, cloned the app from backup, etc... and all seemed to work well. Anything I'm missing? Thanks!
@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?
-
@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.
-
@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?
-
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
-
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.
-
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?
-
@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).
-
@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 any update or estimate on when Node-Red may hit the official release?
To (as a n00b) It looks like most of the heavy lifting has been done, nor?@jsilence It's a good question. We've been using it for a while. Bear in mind it doesn't have LDAP, but you might not need that for your use-case.
