Questions about basic Meteor deployments on EC2

help
1

I’ve deployed my Meteor application, from my local laptop to an EC2 instance with mup.

My mup.json looks like so:

{
  "servers": [
    {
      “host”: “my_domain_name_to_aws_elasticip_.com”,
      "username": "ubuntu",
      “pem”: “/path_to_pem/pem_file.pem"
    }
  ],
  "setupMongo": true,
  "setupNode": true,
  "nodeVersion": "0.10.35",
  "setupPhantom": false,
  “appName”: “application-name",
  “app”: “/path_to_meteor_application/application",
  "env": {
    "ROOT_URL": "https://my_domain_name_to_aws_elasticip_.com"
  },
  "ssl": {
    "pem": "./ssl.pem"
  },
  "deployCheckWaitTime": 30
}

So does this mean that my application is running, file_system — mongo_database — server_software, under one process — on one server — on the EC2 instance? I come from a .net background where we always had a MS SQL db on a separate server — it just seems strange to have both database and server running not only side-by-side, but in the same process (if in fact this is what is going on).

I plan to deploy more Meteor applications, in the same way, to the same EC2 instance.

This approach to Production deployment seems the easiest to me — being my first time with Meteor. I’m sure there are drawbacks. For example, scaling? But what other drawbacks are there? And how would one go about separating the database off on its own EC2 instance (if that is the ‘recommended’ way)?

Also, what about the maintainability of the database? For example backup and restoring the Mongo database? Right now I can use Robomongo to ssh into the EC2 instance and view/modify the database — but what about maintenance?

2

you can set up your database elsewhere and point your application to it using a mongodb URL in environment variable MONGO_URL
in mup, you can write the environment variable in mup.json, e.g.:

"env": { "MONGO_URL": "mongodb://my.awesome.db:1337" }

as for the latter part of the question, consider https://mms.mongodb.com/

3

Thanks for the feedback.

Going through the process:

I create another EC2 instance just for Mongo database, with an Elastic IP of 11.111.1.111. And created a subdomain like so:

databases.my_domain_name_to_aws_elasticip_.com.

I could then create a CNAME to point this subdomain to 11.111.1.111.

I could then choose some random port like 1337, and open this port up in a security group.

I then add my environment variable:

“env”: { “MONGO_URL”: “mongodb://databases.my_domain_name_to_aws_elasticip_.com:1337” }

And when I do a mup setup, my Meteor application’s Mongo database will be deployed to the above server and be available on port 1337? And my Meteor application will know where to find the Mongo database and communicate with it like it’s in the same process on the same machine (like it does on my local box)?

Assuming that the above is how I would deploy, what about the following setup:

I will have 2 or more Meteor applications with the same name on the same EC2 server. The mup.json file will have a appName variable like so:

“appName”: “application-name",

If I deploy 2 or more Meteor applications with the same name to the same EC2 server, and deploy the 2 database to another EC2 server, how would the databases differentiate themselves?

Would I need to change the port they are listening on? Like this maybe:

// mup1.json

“env”: { “MONGO_URL”: “mongodb://databases.my_domain_name_to_aws_elasticip_.com:1337” },
“appName”: “application-name",

// mup2.json

“env”: { “MONGO_URL”: “mongodb://databases.my_domain_name_to_aws_elasticip_.com:1447” },
“appName”: “application-name",

4

no

to the best my of knowledge, Meteor Up can only setup mongo on the machine you deploy to

referencing your app to a MONGO_URL is a Meteor standard, which means you’d have to setup your DB independently and just refer your app to it, regardless of Meteor Up.

I’ve never deployed 2 applications to the same server, but after reading mup’s docs again, the multiple json files seem the right way

as for the database ports, the database URL is an access point to an existing database, so you might as well use the same port.

if @arunoda is out here (creator of mup), perhaps he has something more to say

5

Thanks again.

When you say,

Do you mean mup can/will only setup Mongo to the local instance of the Meteor application it’s associated with?

For example, If I’m using mup to deploy to EC2 instance great_domain.com,

// mup1.json

"env": {
    "ROOT_URL": "https://great_domain.com",
    "MONGO_URL": "mongodb://databases.great_domain.com:1337" 
  },

I’m going to need to manually install a Mongo database on the databases.great_domain.com EC2 instance and open the port 1337?

And further, will I need to open different ports for different Mongo databases on the databases.great_domain.com EC2 instance?

6

to the best of my knowledge, yes

(i edited my previous post to clarify “locally”)

7

But when you say,

If we have multiple databases on the databases.great_domain.com EC2 instance, and they’re being accessed by multiple Meteor applications with the same name (and therefore the same database name):

// mup1.json

“appName”: “application-name",
"env": {
    "ROOT_URL": "https://client1.great_domain.com",
    "MONGO_URL": "mongodb://databases.great_domain.com:1337" 
  },

// mup2.json

“appName”: “application-name",
"env": {
    "ROOT_URL": "https://client2.great_domain.com",
    "MONGO_URL": "mongodb://databases.great_domain.com:1447" 
  },

Then how would we differentiate between databases if we don’t map to different on the databases.great_domain.com EC2 instance?

8

Ok – I think that’s where some of my confusion is, how to configure cloned Meteor applications (same codebase) to refer a particular database? At that point it doesn’t matter if the Meteor applications (2 or more) are on one server or are on separate servers.

… maybe I’m thinking about this all wrong.

Maybe the question should be, If either the Meteor application or Mongo database ‘share’ an EC2 instance, how do I differentiate and deploy my Meteor application(s) and Mongo database(s) with the same code base for different clients?

9

you should stick to the traditional wisdom you’ve practiced in the .NET domain

data servers should be independent of application servers - this means you’d have replica sets (and optionally shards) of mongoDB, where each set member resides in its own server (EC2 instance for that matter)

your (meteor) application instances should reside in their own servers as well (let’s keep it simple and skip multiple instances of the application on the same server)

now, you would point all your application instances to a single database url

specifically in mup, what you wanna do is perhaps deploy a single application to multiple servers, rather than deploying multiple applications to a single server (see https://github.com/arunoda/meteor-up#multiple-deployment-targets)

another helpful tool: https://github.com/meteorhacks/cluster

why do you need 2 databases for 1 application?

10

I went back and corrected that line – thanks.

What I’m thinking about is this:

EC2 (1) instance → client1.great_domain.com

EC2 (2) instance → client2.great_domain.com

EC2 (3) instance
→ databases.great_domain.com:1337 (for client1.great_domain.com)
→ databases.great_domain.com:1337 (for client2.great_domain.com)

In this case, I would need to differentiate between client1.great_domain.com and client2.great_domain.com Mongo database on EC2 (3).

This to me is the traditional way of doing things. In most cases I could get 5 - 10 databases on one Database Sever (or even more). Only in cases where there was extreme load would I have one database per server.

The only way I can see right now to differentiate between client1 and client2 databases is to change the application name in the mup.json file like so:

// mup1.json

“appName”: “client1-application-name",
"env": {
    "ROOT_URL": "https://client1.great_domain.com",
    "MONGO_URL": "mongodb://databases.great_domain.com:1337" 
  },

// mup2.json

“appName”: “client-2-application-name",
"env": {
    "ROOT_URL": "https://client2.great_domain.com",
    "MONGO_URL": "mongodb://databases.great_domain.com:1337" 
  },

This would create a database with names client1-application-name and client2-application-name on the EC2 (3) ‘Database Server’? They both would be available via port 1337.

Would this work? Is this a good approach?

11

Sorry, do you mean here that I should have (1) database for (1) EC2 instance ‘database server’? …

Instead of (2) or more database for (1) EC2 instance ‘database server’.

12

OK, I think I understand better your requirements

are these applications related in any manner? is there a significance to having them on a shared mongo instance?

if the answer is no, I strongly advise against having a shared database (be it mongo or SQL) instance - this couples the applications in terms of security and scale, which should be avoided by keeping them isolated
Also, cloud computing is cheap and you shouldn’t be bothered with such potential concerns

However, if you still want to use the same mongo instance, then according to mup’s docs, 2 distinct appNames would create 2 distinct databases

13

To your question: A central admin Meteor application running on its own EC2 instance will be the only way these applications are related -- they know nothing about one another. I will be querying each of these database and collating/aggregating data about each -- that's the extent of it.

I’m probably misunderstanding.

The database server, would be the EC2 Ubuntu server, with an Public IP of 11.111.11.111.

Then I will install a ‘database instance’, which to me means installing Mongo db, packages: mongodb-org-server, mongodb-org-mongos, mongodb-org-shell, and mongodb-org-tools. Manually installed.

Within this ‘database instance’ I will have to create (2) ‘databases’, names: client1-application-name and client2-application-name. Using mup for this.

What I understand you to say is that you recommend not to put more than one ‘database’ on a ‘database instance’?

For example you think I should do this:

EC2 (1) instance (application server 1)
→ client1.great_domain.com

EC2 (2) instance (application server 2)
→ client2.great_domain.com

EC2 (3) instance (database server 1)
→ url: client1_database.great_domain.com:1337 (database instances 1)
→ name: client1_application (databases 1)

EC2 (4) instance (database server 2)
→ url: client2_database.great_domain.com:1337 (database instances 1)
→ name: client2_application (databases 1)

The main reasons I’d like to keep more than one database – as far as I know right now – is for cost. Building a SaaS I’d have to pass on the cost of (2) dedicated EC2 instances, instead of (1) dedicated EC2 instance for the ‘application server’ and a ‘shared’ EC2 instance for the ‘database’.

14

if the 2 databases are not in the same product domain, then they shouldn’t be in the same instance

as for your example, instances #3 and #4 can’t have the same url

15

Updated the URL, thanks.

Also updated the reasons I’d like to share a EC2 server for the database.

16

well, business and money overrules engineering decisions,
so I guess you’d have to use a single mongo instance with 2 databases:

  1. provide different appNames in mup.json
  2. use the same MONGO_URL for both applications

this should work.

1 Like
17

So two different EC2 instances – (1) for each database? Why not have more than one database on a EC2 instance? Just to distribute the load for scale, to distribute risk? The cost will increase by a good amount I think.

I have one small EC2 instance I’m testing out on now and I pay ~ $25 a month. I can’t wait to see what the cost of that box will be like once the client starts using it in earnest.

18

had I been an informed client, I wouldn’t want my data to be coupled with another client’s data in any way
as for scaling, mongodb replicas are on the instance level, which means you get to replicate both databases involuntarily

technically speaking these are not good practices, but as I’ve said in the previous post, business/money necessities overrule engineering practices and if you rather cut down costs at the moment, that’s fine too

the upside is you can always separate the databases

1 Like
19

Thank you. Exactly what I needed.

But what about the installation and configuration of Mongo DB on that ‘database server’? I’d need to install on the EC2, and then configure the port on the database instance. I’d then need to setup the a AWS security group on that EC2, opening up that port for inbound traffic?

In your example that would be port 1337.

Is there a good place to get a walk through of how to do this the right way?