Meteor and AWS Elastic Beanstalk

Hi guys,

I am aware, that there are some other threads out there regarding this combination, but most of them a pretty old and I just want to check the current situation, before I throw myself into the AWS world.

Current situation:
One Big DigitialOcean Droplet running my main app and mongo. This droplet has 8GB of RAM and 4 CPUs - so should be kinda okay. Thing is, that we are expecting a soon-to-come pretty substantial user bump and thus way more load.

–> I am thinking of switching to AWS with Elastic Beanstalk, as I really want something which properly autoscales.

I am currently already using mup and I am aware, that there is a plugin out there: https://github.com/zodern/mup-aws-beanstalk
BUT: I also read, that the deployment times are pretty bad - some say around 45mins. This is not really acceptable for me.
Then I also found some blogposts out there like this one: https://blog.416serg.me/step-by-step-guide-to-deploy-a-meteor-application-to-aws-elastic-beanstalk-in-production-1bd899bbf3f9
Again, this blog post is pretty outdated, uses a couple of “ugly” workarounds and all that.

So I guess my question is: is AWS Elastic Beanstalk suitable for meteor? If yes, which method of deployment do you recommend? I really need something which works reliably and as fast as possible!

I also already thought of doing the following:

  • Create/define a “base image” for my EC2 instances which run in my Elastic Beanstalk, which already has everything installed it needs except my meteor app itself
  • create a simple build script, which builds my app and uploads the bundle.tar.gz file to AWS S3
  • find some way (I am totally new to AWS!) to tell Elastic Beanstalk to begin updating my EC2 instances from this new bundle I just uploaded one by one
  • if EBS needs to scale up, just spin up a new instance from my base image, load the current bundle from AWS, unpack, npm install and go.

I really need some way which does not stop my main development Mac for like 45mins, because it needs to mup deploy!

Thanks for your input in advance,
best, Patrick

2 Likes

The 45min deploy time only applies if you have a fairly large app, and used the default deployment setting, which is RollingWithAdditionalBatch. There are tradeoffs to using this, you get a fresh instance and you have no downtime, but it takes time to spin up and gradually transition your clients to the new batches. We have currently changed this to AllAtOnce, which simply replaces the app in-place, and you get 1-5 minutes of downtime, but the overall deployment time is faster 10 min in total usually with our large app. This is using our fork of mup-aws-beanstalk, which allows changing this setting. It has worked really well for us.

Hi @jorgeer thanks for your reply!
Unfortunately I can’t have a downtime that big, even like 30 seconds would be a problem. Besides that, is AWS / EBeanstalk, mup etc. working fine for you?
How do you host your mongodb? self managed EC2 or are you using something like MongoDB Atlas?

Another option is “Rolling”, which takes out a percent of your servers at a time, leaving you with lower capacity but without downtime, and doesn’t take that much longer than AllAtOnce.

It is working perfectly well for us with the cusomizations we have made.

For Mongo, we use Scalegrid, which manages EC2 containers on our accont for us in the same region as we have EB, so we have everything in once place.

1 Like

Okay thank you very much for the input!
I am thinking of using MongoDB Atlas, which also provides AWS instances, so I would also have everything in one place.
And thanks for the tip regarding the “Rolling” option!
Any other input you can give a fellow Meteorfan like me who switches from a normal root (digitalOcean Droplet) to AWS? Was it difficult for you to spin up your first Elastic Beanstalk?

Not really, no. It was very easy to get up and running, I have 6 active applications running it at the moment, and monitor them using montiapm.com. The default monitoring on EB / EC2 is so barebones.

Let me know if you need help with configuration, or finding the fork that allows changing deployment policy.

1 Like

I really need some way which does not stop my main development Mac for like 45mins, because it needs to mup deploy!

You don’t really have to wait for it… After mup completes the build and upload it to AWS, the rolling begins… You can actually disconnect then. The rolling process is handled by AWS beanstalk not the mup script.
Regarding the rolling options, I don’t think a long transition should bother you, the platform would be busy but no downtime and you can continue your work and check a while later that all is fine.

Sorry for the bump, but can anyone quickly explain the advantage of Elastic Beanstalk over just using direct EC2 instances and MUP? Is it that you have to manually update all the EC2 instances? Doesn’t MUP help with this?

I’ve heard of doing it both ways direcct EC2s with ELBs and then Elastic Beanstalk… which is better and why?

1 Like

I think the main benefit would be auto scaling. With beanstalk, you can set the min and max EC2 instances you want and it will scale up and down without you needing to do anything.

Think authority. One authority level can modify the EC2 sets, another authority level can update the Load Balancer, a certain department can work on the firewalls and so on you can segregate the access to the infrastructure using multiple IAMs.
As mentioned above, horizontal autoscaling is another feature provided by EBS as well as a structure for setting EC2s in target groups and availability zones.
If you wanted to build something very complex with … live video streaming for example, you could use a Cloud Formation template and build/rebuild your infrastructure programmatically (as you do with MUP) to include multiple AWS services which are not available in EBS. It all depends on what you need to do. For most Meteor projects, 1 EC2 with a NGINX balancer will probably do the job.

2 Likes

I hear you on mup man for sure it takes like 45 mins or more and that’s going to be annoying as hell. I know it is for me!

I hope this can help, here’s how I am doing it - I just build the app with meteor build and scp that to the server. I then start the instance in screen and define the port etc with export in the shell, in nginx I run that as an upstream, and btw did you know you can run multiple instances also on one machine? Just set different ports. Pretty awesome feature of meteor.

For the spec you said 4 cores and only 8gb of ram, it’s fairly light really for production usage, especially with a database running alongside. I would recommend going up to 8 cores and 16gb of ram and an additional 16gb of swap on disk. Very easy to add disk swap just check the OS manual for your distro usually just run dd and swapon

To save money you can run mongo db, a main webserver and the primary nginx config all on one machine, and then just add another webserver with 4 cores and 4gb of ram and just do the same, run the scp command and untar the build file, start it in screen and leave it running then give the IP to nginx as a secondary upstream. In this manner I have run 3 webservers and easily withstand 1 million visitors per day and thousands of request per second.

http://nginx.org/en/docs/http/load_balancing.html

2 Likes