One the same project but different aspects of it, deployment is something we are looking at how the project should be deployed into UAT and PRD. We have finished POC on using MUP to build image and deploy it to a test node running docker, which looking cool and fully automated.
But how we should scale it for production, how we setup mongdb instance separately from the image, whether compose.io is a better way to host mongodb separately? Do we need load balance with ngeix website and multiple meteor instance in multiple container?
Those are question we have and would like to plan in advance for the project, again it will be great if anyone about to point us any articles.
We preferred to host our application by ourself instead of galaxy, or there is a very strong reason to use galaxy.
First, I’d say that the main value of Galaxy is its easy integration with Kadira. Application performance monitoring (APM, what Kadira is) is incredibly valuable, and Kadira in particular is very well written. If APM isn’t important to you, then go ahead and host these things yourself.
If your goal is to do everything as cheaply as possible, the fastest, cheapest and easiest solution is to use a single, high performance AWS instance that runs an single-node, replicated mongod instance with a database directory on an EBS guaranteed-IOPs drive; and meteor run --production --port 80 (note, it looks like the MDG folks suggest against doing that, so maybe just package with their build commands and run it directly with node) with a MONGO_OPLOG_URL and MONGO_URL environment parameter set to the appropriate path.
if you want to create a mongodb instance separate from your web host, which is a “gold standard,” just start a new AWS instance
compose.io is great, but all database providers are a rip off (and the fact that there are so many of them should be a huge red flag that what they do is fundamentally undifferentiated and provided out-of-the-box by mongo)
you don’t need to load balance, use AWS Application Load Balancing if you really think you do, but it’s better to just upgrade your instance and configure it to be backed-up regularly
to run a new meteor instance, start a new AWS EC2 instance in the same VPC and specify the MONGO_OPLOG_URL and MONGO_URL to point to the database host.
Deployment seems complex, but I think people make these insane systems to do fundamentally really simple things.
If it’s just an MVP go ahead and host it yourself. Especially, if you never done it before it can be a very educating experience.
However, any real world production app that receives serious traffic and/or is concerned about proper security should be hosted by experienced personal only. There are many ways to screw things up and e.g. you don’t wanna find yourself explaining to your customers that your servers got compromised just because you didn’t know better. Quick example, you should never use the --production flag to deploy, read more here: https://guide.meteor.com/deployment.html#never-use-production-flag, also you should never be running your app and your db on the same server. These are very elementary mistakes to make and there are a lot more subtle ones that are easy to overlook that potentially open up vulnerabilities or performance issues.
So my opinion is: either invest serious time in learning how to setup secure, scalable database and node.js servers or pay someone who knows how to do so (Galaxy, Heroku, MLab, Compose). Using Galaxy is also a nice way to contribute to meteors future and its continued development.