Meteor-Station
edit: I have just been made aware of pm2 (thanks to pchoo on IRC's meteor chan). Seems like a robust mup alternative.
Meteor-Station is a highly configurable and flexible deployment solution for Meteor. Since mup is no longer maintained, the Meteor community was forced to move to mupx. However mupx uses docker, and this technology choice should not be forced onto anyone.
Installation
npm install meteor-station -g
Configuration file
The configuration file is rather similar to mup's, but please save it in mstation.json:
Speed-up
Meteor-Station provides a significant speed-up by not tarring the bundle. It also allows to not bother with the backup / rollback mechanism which once again brings down deployment times significantly.
The whole advantage of using rsync is lost with syncing a tarred archive; internally mstation uses rsync azv <source> <target> --delete
which only transfers what has been updated, and removes anything from the destination which no longer exists in the source. In other words, it's fast, and better.
Example usage
n.b feature not yet checked in
$ mstation init
Creates the default configuration file for meteor-station.
$ mstation
This command looks for settings.json in the pwd, and performs all required steps to get your project deployed and running.
$ mstation --settings staging-prefs.json --config staging-server.conf
Say you have various servers, i.e for staging, testing, production etc. the --settings and --config flags enable you to run mstation with different configs.
n.b feature not yet checked in
$ mstation --backup false
This skips the step of creating a backup of your project on the target servers. This means rollback is impossible in case deployment fails, but it provides a significant speedup.
$ mstation start
Start the Meteor Application
$ mstation stop
Stop the Meteor Application
$ mstation restart
Restart the Meteor Application
$ mstation logs
Tail -f the logs for this Meteor Application
Running custom deployment steps
n.b feature not yet checked in
mstation
allows you to add your own deployment configuration steps. This is because every version of meteor, on every target may have different setup requirements.
For example, when installing from OSX, bcrypt is binary incompatible and needs to be rebuilt. Fibers, and a whole host of node packages need to be installed too, and some packages need to be removed from the bundle.
Trying to cater for all these scenarios doesn't make sense. Instead, simply add your own 'custom-deploy-steps.sh' (for example) script, and point to it with:
mstation --custom custom-deploy-steps.sh
Which will allow you to make any required modifications to the installed bundle for it to work.
Understanding the deployment pipeline
The best way to master your Meteor deployments is to thoroughly understand the deployment pipeline. It's really not the complicated, and once understood, you'll better be able to diagnose and fix your own issues without having to depend on third parties.
Step 1: the build
The build step consists of nothing more but:
meteor --build /tmp/build
Step 2: generating scripts and configuration
ETC.