We have hosted RocketChat on AWS and I have two questions and not sure if possible. Couldn't find anything on the docs.
Separate database and application servers from each other
Connect to a specific database based on the subdomain in URL
Any thoughts?
Cheers
You can definitely run your Mongodb servers seperately from your Rocket.Chat servers.
To route based on domain. You would just simply have to have a Rocket.Chat instance running for each subdomain you wish to have Rocket.Chat running on.
Then when starting the instances for those domains include environment variables like:
# subdomain1
PORT=3001
MONGO_URL=mongodb://ip-to-mongo-host:27017/subdomain1?replSet=rs0
MONGO_OPLOG_URL=mongodb://ip-to-mongo-host:27017/local?replSet=rs0
# subdomain2
PORT=3002
MONGO_URL=mongodb://ip-to-mongo-host:27017/subdomain2?replSet=rs0
MONGO_OPLOG_URL=mongodb://ip-to-mongo-host:27017/local?replSet=rs0
Above of course is assuming you are running your mongodb in replicaset mode. Which for Rocket.Chat I would definitely recommend. Especially when you go to scale the instances out to handle additional load.
Then in your reverse proxy just simply route:
subdomain1 -> 127.0.0.1:3001
subdomain2 -> 127.0.0.1:3002
Related
I have two servers and both are working fine.
How to sync all my data from one server to another server/backup-storage/remote-storage.
I want to know if one of my server is down due to heavy load then how to use instantly second server and what is the role of DNS in this, because if we use another server then we have to change DNS also for particular website so how to overcome this.
You can check cloudflare load balancer.
Architecturally you have two problems to solve:
load balancing (how clients are routed to one of the servers) - this involves sometimes DNS settings but because cloudflare hosts your DNS as well, you are cool
Synchronization: files and database sync between hosting accounts. Now here there is no standard way to go especially because your are hosted using cpanel
DATABASE:
You can't use master-master or master-slabe database replication mechanisms like Galera Cluster has.
You're best bet is to have a cron that will export the database from one server to the other. (using mysqldump - basically exporting and then importing)
on live:
mysqldump -u userName -p yourLiveDatabaseName > live_database_export.sql
on the hot backup (your other account):
mysql -u username -p yourOtherServerDatabaseName < live_database_export.sql
FILES:
If you have SSH access use rsync.
Otherwise you may need to invent something.
For instance you can check the Cpanel API in regards to account transfers -> that will solve the database as well https://api.docs.cpanel.net/openapi/whm/operation/create_remote_user_transfer_session/
As a remark - you are not in the best position to do HA having two cPanel shared accounts. What I usually do is to use virtual machines that are sync at the hypervisor level.
I have 2 x AWS EC2 instances with a node.js app. Out of the box, they come with a local mongod instance that works fine. Given the criticality of the app, I decided to spin up 2 x EC2 front ends (node js) to talk to a mongo db in another availability zone using the AWS ELB.
Full IP communication/27017 connectivity exists between all 3 nodes.
When using only 1 server to the mongo server, it works just fine. When adding both front end servers into the ELB target group, I get random 504 gateway errors.
Removing a server from the group fixes the issue.
Any suggestions on what I should look for?
In terms of how the node.js server connects to mongo, there is a config.json file that simply points out the IP and DB name required.
Thanks!
AWS Load Balancer use "round robin" mechanism to route user's requests. Does your application have way to control user sessions? If not then your first request come to server 1, then second request to server 2 which doesn't have any information to the first request may result in error. That explain why it works fine when you have 1 server only
the server uses redis (the app server) and the following components:
Node.js - Server-side Javascript-framework
Express.js - Web application framework for Node.js
Nginx - Web server & reverse proxy
MongoDB - NoSQL database
redis - Session Manager & data structure server
Socket.IO - Bi-directional communication between web clients and servers
I was using Galaxy to host my meteor app and recently decided to host my app with Amazon Cloudfront serving static webpage (angular client) and connect that to my meteor app running on an EC2 container.
I have the static page working and I have the meteor app on the EC2 container, which points to a remote mongo server, working as well. I am using the meteor-client-bundler package to attempt to connect the client (static cloudfront) to the Meteor server via DDP URL. Here is where I am stuck.
The DDP Url should be my meteor server correct? Hosted at ec2....amazonaws.com)? I feel like it has to be because I have publications and methods on the server I will need to hit constantly. If that is correct, then what if I also want to have two EC2 containers running the same Meteor app? Just like in Galaxy, in case 1 is getting maintenance work done or goes down, I want the backup to take over. How can I set up two different DDP urls?
You should use a custom domain for the server, and use that custom domain in the DDP URL. While using the EC2 address will work, it's better to use a different address, especially if you ever want to move to another provider.
You can use NGINX as a reverse proxy to have 2 or more Meteor apps on the one box. It's not too difficult to set up.
You can also use Meteor up (aka mup) to do multiple deployments to the same box. http://meteor-up.com/ Meteor up will give you a very simple way to deploy, it will even revert to the previous version if something goes wrong automatically. You can even configure it to run letsencrypt to give you https security, and automatically renew the certs.
For anyone who is new to this stuff like I am, I figured out to buy another domain name, use dns (route 53) to a load balancer (elastic beanstalk) which handles multiple ec2s for 1 domain, and then point your ddp from the client to the domain. Boom. Thanks for the help #Mikkel
Recently i decided to move my database from inside my server machine to the MongoDB Atlas service.
Atlas provides a IP Whitelist feature which i use to remotely connect to the database cluster.
Should i plug my server application to Atlas using this feature?
What happens if my server IP changes? Is it secure?
For a general information on how to connect to an Atlas deployment, please see Connect to a Cluster
For connecting using a driver, please see Connect via Driver. There is an extensive list of examples using all of the officially-supported drivers.
As mentioned in the Prerequisites section, you need to use SSL/TLS and IP whitelist to connect to your Atlas instance. This whitelist would need to be updated should your application server's IP changes.
The whitelist provides an additional security layer in addition to your username/password, since this list will essentially reject any connection not originating from a known IP address. It is strongly recommended to utilize this whitelist, and arguably the effort required to maintain the whitelist is comparably small to the security advantages it provides.
I am currently developing a service application that pulls data from Mongo and returns it to consumers. There is a layer of authentication involved and I am using Heroku to host the service. Mongo was being hosted on MongoLabs, but there were some significant performance concerns and so we have moved to hosting Mongo on one of our cloud servers. We want to be able to secure access to Mongo using a firewall, white-listing the ip address of the service app on Heroku.
There are a couple of issues with this.
Issues
Well, at least these are main ones...
Heroku, while providing some nice features like easily managing cluster settings, s/w upgrades, etc., draws ip addresses from a pool. While the dns value of an application's url may not change, the underlying ip address can and will change.
to be better secured, mongo-server01 is placed behind a firewall that requires rules to be added using static ip addresses to allow access.
Since Heroku can't provide static ip addresses, we need to consider options for how Heroku can access mongo-server01 while still protecting the data it hosts.
Static IP addresses for outbound requests
There seem to be a couple of options, specifically for Heroku. Fixie and QuotaGuard Static both seem to serve that function, but these seem to be geared toward HTTP and HTTPS communication only (perhaps not even HTTPS).
Mongo doesn't use HTTP, it uses its own network protocol over port 27017, by default
https://groups.google.com/forum/embed/#!topic/mongodb-user/eX_RIv2cZVw
Does this mean these proxies won't work for calls to Mongo? In theory, there doesn't seem to be any reason that a proxy is only for HTTP or HTTPS requests. That being said, there doesn't seem to be any way to get in to these Heroku plugins and configure the proxy to use a different port or to handle Mongo's particular protocol.
If we could get into the proxy, perhaps we could put an additional set of ssh keys in place so the ssl tunnel chain could continue on to mongo-server01. But there doesn't see to be any way to ssh to these proxies or access configuration through the plugin dashboards.
The question (finally!)
How can one connect from Heroku to a firewalled host to get data from MongoDb? Are there proxies that can be used to achieve this?
The simple approach. Won't work because Heroku applications don't use static ip addresses.
Using a proxy. The Heroku proxy plugins don't know how to proxy mongodb protocol. Can't install ssh keys on proxy for ssh tunneling.
What can be done to get a connection without opening up the Mongo server to the world?
I spoke with the folks at QuotaGuard and they do have something that does the trick.
we offer a SOCKS proxy which should do the trick as it proxies at the TCP layer
https://devcenter.heroku.com/articles/quotaguardstatic#socks-proxy-setup
I did need to make a simple change to bin/qgsocksify
#SOCKS_DIR="$(dirname $(dirname $(readlink -f ${BASH_SOURCE[0]})))/vendor/dante
SOCKS_DIR="${HOME}/vendor/dante"
After that, the proxy worked like a charm.