NodeBB AWS auto scaling
-
Hi Everyone,
We are deploying NodeBB application in AWS with auto scaling is enable.
Single NodeBB instance is working fine with load balancer. As soon as new instance is launch NodeBB is showing error on Home page "Looks like your connection to NodeBB was lost, please wait while we try to reconnect. ".
Can anyone let me know how can we resolve this issue.
Farooq
-
Need more details. How do you have your instance configured? Can you post the
config.jsonwithout secrets.Sounds like it's crashing, possibly because of a database error. There should not be a database on the instance, they should all point to the same ElastiCache DB.
-
The built in auto-balancer is incompatible with NodeBB websockets last time I checked. That's probably the issue you're having.
-
I'm facing the same issue when i deployed onto IBM Bluemix Cloud Foundry. On a single instance NodeBB works fine but after scaling it repeatedly getting the error message state above. No idea how to resolve this. I suspect it has something to do with the URL in config.json that is not compatible with the LB ... it is a shame though.
Wondering if it is the same on Digital Ocean when scaled up? @PitaJ Are you able to comment please?
Thanks
-
@yapne that message essentially just means that websockets aren't working. I'm your case, it may be that your load balancer is using round robin or something as opposed to IP mapping.
-
@pitaj I believe Bluemix Cloud Foundry is using round robin algorithm.
I did modify the webserver.js file in order for Cloud Foundry to inject the internal port. Below are the changes and i'm starting NodeBB using node app.js
var port = process.env.PORT;
var socketPath = isSocket ? process.env.PORT : '';the URL in config,json, i think it is the reverse PROXY url given by Bluemix CF. Also the port in config.json i have also left it as 4567. Not sure if this correct in my case though.
-
When you run NodeBB in a cloud that has a load-balancer, reverse proxy, routers etc., it has to be configured to work properly, especially when you scale the server to use multiple instances.
One of the constraints Socket.io, SockJS and similar libraries have is that they need to continuously talk to the same instance of the server. They work perfectly well when there is only 1 instance of the server
Found this post too
https://community.nodebb.org/topic/4383/hundreds-of-polling-requestsThat pretty much explains the issue i'm encountering on Cloud Foundry. Suspect it will apply to AWS too ...
-
@yariplus my config
{
"url": "https://staging.XXXX.org",
"secret": "XXXX",
"database": "mongo",
"port": 4567,
"mongo": {
"host": "172.31.42.228",
"port": 27017,
"database": "nodebb",
"username": "nodebb",
"password": "AAAAA"
},
"oauth": {
"id": "2bb8010d070f0be6f58d",
"secret": "36a6b6da7df8e96f92b2aae22e24306a619a5413"
},"socket.io": { "origins": "https://staging.XXXX.org:* https://staging.XXXX.org:*", "transports": ["websocket"], "address": "https://staging.XXXX.org" },"socket.io:origins": "https://staging.XXX.org",
"sessionKey": "express.sid",
"cookieDomain": ".philanthropyu.org",
"socket.io:transports": ["websocket"],"redis": { "host":"nodebb.ifinyn.0001.euc1.cache.amazonaws.com", "port":"6379", "database": 0 }, "edx_host": "https://staging.XXXXX.org", "aws_access_key_id": "xxxxxxx", "s3_path": "https://XXX-community-uploads.s3.amazonaws.com/", "aws_secret_access_key": "xxxxxxxxxx", "master_token": "xxxxxxxxxx"}
