I need to expose a Node-red server running at localhost at the port 1880 to the internet. However, according to the product requirement, it must be done with a "plug and play" feeling, which means, no ddns or further network setup needed. What I actually need is something very similar to ngrok (ngrok would actually do the job, but because of a hardware requirement i.e. it is an IOT device it could not be installed).
The server is built to be super robust locally but intermittent online. Therefore, it could not be a cloud based aplication. It must work locally independent of internet connection. I want my https nodes be available online when internet is provided, however, work normally in the local network when there is no internet!
The server is a Linux (yocto) already running some HTTP requests that should be done online. Now, my plan is actually to mirror the local node-red server to a bluemix(IBM-Cloud) hosted Node-Red instance if it is even possible. I really need some ideas about how to deal with this issue.
There are a number of posts in the docs and elsewhere that cover the general and security issues regarding connecting Node-RED to the Internet.
I'm not sure why you can't get NGROK working, I would have thought it should work. There are some other similar tools around and there are VPNs as well of course but I don't think that would help the case you talk about.
As I understand it, you want 2 things?
A device permanently able to reach out to Internet facing API's (http-request node)
To be able to connect to Node-RED from the internet
1 could be covered by your device itself assuming that it is robust (a UPS would be helpful for example) and your Internet connection similarly robust. Alternatively, another instance of Node-RED on a cloud platform or VPS would be a decent solution. Bluemix is one example, Azure, AWS or your own VPS would also work. You can connect the 2 together using various methods though MQTT would be a sensible place to start. Don't forget that you need to secure both ends AND the traffic between them though - don't overlook that, we've seen plenty of examples of compromised endpoints here already.
2 is most easily covered by ngrok or a similar tool or indeed a VPN solution which could reside on the device or on your Internet router. If this is a business/corporate network however, you will need to consult with your IT/networking people as to what will work and what is best.
It is hard to give specific information without knowing more about your environment and requirements.
Could you give me more info about how should I do this or how to start. Should I create 2 instances connected through MQTT nodes? Would it be possible to just mirror the local instance to a second one in the cloud (I would prefer it). Maybe I am just not searching right, but I am struggling to find info that help me with that.
Out of curiosity: The device is a Siemens IoT device, the processor is 32bits however without MMX module in the processor. Ngrok 32 bits needs this module to run, therefore, no Ngrok.
Design the UI so that it works entirely via MQTT. Use an MQTT server accessible to both the local and cloud node red servers. Then put identical UI flows on the local and cloud instances, with the non-ui stuff just on the local one. For convenience you could use the same node-red flows but disable the non-required flow tabs on the cloud one.
I liked the idea. However it does not mean to be a cloud solution i.e. the internet can be intermittent and the local server must always be up and running. It is build to be super robust locally and intermittent online. I will edit the question to include this information. Sorry about not being clear about it!
I believe it is possible to have two mqtt servers running in a way that they automatically mirror each other, though I am not sure how to do it and Google doesn't seem particularly helpful. Perhaps someone else can comment on this. If it can be done then you could run a local mqtt server which runs the system and a mirror mqtt server in the cloud, along with the cloud node-red server.
MQTT brokers can indeed mirror any topic path you like. And with the right settings will recover after a network break to the latest values.
However, I've never actually done it so you would need to hunt through the settings.
Arranging things so that the on-site broker always pushes to the cloud one is also completely possible. You will want to set up TLS as well as an id/password for security.
Sorry I can't help further as I've never needed to actually implement this though I know it is possible.
For anyone interested, having done a bit of research, this feature is called Bridging. Looking at it it does appear that it could be used to keep an MQTT server in the cloud synchronised with a local one by telling the local one to bridge the required topics over to the one in the cloud. This can be two way so topics published to the local server would be sent across to the remote and also topics published to the remote server would be picked up by the local one. I believe it can be entirely driven by the local one so the remote one does not need direct access to the local one The local one needs to be able to access the remote one obviously.
I intend to do some experiments with this and will post back in a new thread at some point (it may be a little while till I can get round to it though). Info on setting up Mosquitto for bridging can be found in
