Perhaps a better place to ask this would be somewhere on Amazon, but I thought I’d check here just in case. I was seduced by the easiness of deploying to AWS with Meteor Up as found in this tutorial, and got my meteor app up and running on a micro instance without much of a hitch. My database is hosted separately at mLab (formerly MongoLab).
The final issue is autoscaling. I despise (more than I care to express) doing sysadmin work, so my end goal here is getting my app set up to a point where I don’t have to worry about it any more and can focus on the development (I’m a one-man show, after all). The process detailed in the link above makes it easy for me to set a host IP address in the mup.json file, hit mup deploy, and be done with the whole thing, but that doesn’t seem possible when I want to use the Autoscaling Group function (I tried looking into Elastic Beanstalk, but on the surface it seemed like it would have been impossible to set custom env_variables, as well as support for node v0.10.40 – if I’m wrong about that let me know!). Closest thing that I’ve seen is CodeDeploy, which is Amazon’s own CI thingy which doesn’t seem to be compatible with MUP. Is there anything I can do? My ideal scenario is that I’d designate some sort of “master” host IP address to keep inside the mup.json file, then whenever I deploy the “master instance” is updated and the change proliferates to the rest of the “slave” running instances. But I haven’t seen such a thing much asked about, let alone exist, and I’ve been running in circles. Any ideas?
You can get easy autoscaling if each new virtual machine knows how to deploy and update itself. BeanStalk does this well as it has a CLI to manage the life cycle.
If you really want to do it with MUP, you could install MUP on a VM and run setup on localhost and save this as a custom AMI.
This VM would also need to pull the code from a repo on startup and get MUP to deploy the code against localhost.
You can setup the autoscaling triggers and rules using a cloud-formation template.
You would also need to manage app versions, and for that you might want a running version manager in the VM that watches for new versions and redeploys. Perhaps you can make this look directly at Git.
The key here is to decentralize the deployment so that you don’t need to keep track of dynamically provisioned servers.
All of the above is pretty much how Amazon BeanStalk works. So I would say to use that or use Galaxy. Rolling your own is doable and fun, but if you are looking to save time and money, it’s probably not the best path as you will have a lot of maintenance.
I successfully deployed our company’s Meteor app on Amazon EB. Here are some tips to get you going quickly:
As you mentioned, EB is missing the correct Node versions (0.10.40). But don’t worry, EB uses some configuration files during deployment, which you can use to setup your environment. Any files placed inside a “.ebextensions” folder will be taken by EB and ran in alphabetical order. This way you can install the missing Node version, even when autoscaling happens. Follow this guide to achieve this: https://thesauceco.de/blog/Automatically-install-custom-Node-for-Meteor-in-Elastic-Beanstalk/
You mentioned you had no way of setting the env vars during deployment. Through the same mechanism (.ebextensions) it is possible to set them. Just add these lines to one of your config files:
You can add your own to this list. Notice I disable websockets, since they don’t play well with the elastic load balancer (yet). And the last one is the node command to start your application. By default, EB uses node install which won’t work with your meteor app.
Finally, don’t forget to enable session stickiness on your load balancer with cookie expiration = 0. This is specially important when you have multiple servers.