what are the major steps required to create multiple instances of a meteor.js application running on a single server?

Question

I have designed a meteor.js application and it works great on localhost and even when deployed to the internet. Now I want create a sign-up site that will spin up new instances of the application for each client who signs up on the back-end. Assuming a meteor.js application and python or javascript for the sign-up site, what high level steps need to be taken to implement this?

I am looking for a more correct and complete answer that takes the form of my poorly imagined version of this:

1. Use something like node or python to call a shell script that may or may not run as sudo
2. That script might create a new folder to hold instance specific stuff (like client files, config, and or that instances database).
3. The script or python code would deploy an instance of the application to that folder and on a specific port
4. Python might add configuration information to a tool like Pound to forward a subdomain to a port
5. Other things....!?

I don't really understand the high level steps that need to be taken here so if someone could provide those steps and maybe even some useful tools or tutorials for doing so I'd be extremely grateful.

Answer 1

I have a similar situation to you but ended up solving it in a completely different way. It is now available as a Meteor smart package:

https://github.com/mizzao/meteor-partitioner

The problem we share is that we wanted to write a meteor app as if only one client (or group of clients, in my case) exists, but that it needs to handle multiple sets of clients without them knowing about each other. I am doing the following:

• Assume the Meteor app is programmed for just a single instance
• Using a smart package, hook the collections on server (and possibly client) so that all operations are 'scoped' only to the instance of the user that is calling them. One way to do this is to automatically attach an 'instance' or 'group' field to each document that is being added.

Doing this correctly requires a lot of knowledge about the internals of Meteor, which I've been learning. However, this approach is a lot cleaner and less resource-intensive than trying to deploy multiple meteor apps at once. It means that you can still code the app as if only one client exists, instead of explicitly doing so for multiple clients. Additionally, it allows you to share resources between the instances that can be shared (i.e. static assets, shared state, etc.)

For more details and discussions, see:

• https://groups.google.com/forum/#!topic/meteor-talk/8u2LVk8si_s
• https://github.com/matb33/meteor-collection-hooks (the collection-hooks package; read issues for additional discussions)

Answer 2

Let me remark first that I think spinning up multiple instances of the same app is a bad design choice. If it is a stop gap measure, here's what I would suggest:

1. Create an archive that can be readily deployed. (Bundle the app, reinstall fibers if necessary, rezip). Deploy (unzip) the archive to a new folder when a new instance is created using a script.

2. Create a template of an init script and use forever or daemonize or jesus etc to start the site on reboot and keep the sites up during normal operation. See Meteor deploying to a VM by installing meteor or How does one start a node.js server as a daemon process? for examples. when a new instance is deployed populate the template with new values (i.e. port number, database name, folder). Copy the filled out template to init.d and link to the runlevel. Alternatively, create one script in init.d that executes other scripts to bring up the site.

3. Each instance should be listening to its own port, so you'll need a reverse proxy. AFAIK, Apache and Nginx require restarts when you change the configuration, so you'll probably want to look at Hipache https://github.com/dotcloud/hipache. Hipache uses redis to store the configuration information. Adding the new instance requires to add a key to redis. There is an experimental port of Hipache that brings the functionality to Nginx https://github.com/samalba/hipache-nginx

What about DNS updates? Once you create a new instance, do you need to add a new record to your DNS configuration?