Thanks for your advise. I’m really unexperienced.
1 Like
As a long time developer and person who likes to deploy a lot of things to a lot of sub-domains, I did not want to pay per-instance prices. Therefore, I have been working on an AWS AMI to solve this problem in a way that satisfied my requirements… here is a sneak peek:
I’ve been using it for six or so weeks now, and it has taken that long to get through all the AWS hoop-jumping to get the AMI packaged, scanned, documented & etc… but as soon as they approve my new logo (last step!) it will be published.
It should be available for free next week in the Amazon AWS Marketplace!
2 Likes
+1 for Heroku. I agree with @SkinnyGeek1010, other points I’d add:
- Easy integration for automatic test runners (e.g. CircleCi).
- Having automatic per pull request staging apps. This means that every time I create a pull request, a brand new (free) staging app with that code gets automatically spun up (with mongoDB and pre-set settings) so that it can be QA’d or shown to the rest of the team.
3 Likes
That’s really interesting the part where you can upload to a staging in heroku. Does anyone knows or recommend a tutorial on this?
What about the price for the $7 plan on heroku, is it worth it compared to other hosts?
A lot of good information in this topic, thank you all!
1 Like
I’m still using MUP with AWS. Works great. Had to take a break from app dev which is why I’m still on MUP. However, after several server spikes/restarts, I’m now finding I need to look into horizontal scaling/load balancing and have been looking into options - Galaxy, AWS, cluster, etc.
It seems like cluster is no longer developed and also has a problem supporting multi-core machines. Is there a majority on what to use for horizontal instancing? I think Galaxy looks easy enough, but I’m curious how they scale on AWS behind the scenes. As everyone said for the last few years AWS couldn’t support session-affinity and websocket at the same time across multiple EC2 instances.
You can use nginx / tengine with sticky session and redirect to your meteor instances. We use it with Digital Ocean and I would be very surprised if you can’t do it with EC2 instances.
Nice. And looks like Galaxy rolls its own sticky-session support on AWS that they call “stable sessions”. Seems very cool and well planned. Learn about it here:
I echo this question. Also, can we ssh into a heroku instance? I need to place temp files and templates OUTSIDE the Meteor directory, and usually do that with a ssh to a EC2 instance. Without ssh support, I have no way to access the file system.
I’ve been using heroku for easier deployments, but I don’t think you can access it with ssh. If I need custom file storage I use digital ocean with nginx and mupx or manual deployments using meteor build
Yeah, I guess I’m going to have to use mup then (can’t use mupx because I don’t know how to store files outside of the Meteor dir).
You can use fscollection package and state the url from the computer/server, example: /home/user/Documents/... not sure if it works with mup/mupx as I’ve only tested it with manual deployments but I’m pretty sure it would since you are storing the meteor app in /opt/appname folder inside the ubuntu server
I might look at moving my file system work I do outside of the Meteor directory to the cloud at some point, and then I’ll consider S3.
What exactly is your problem/question? 
@klabauter, I don’t really have one in this context right now. Although I did find out from this thread I can’t ssh into heroku, which rules that service out for me.
On a side note, I’m not considering mupx due to the fact it uses docker. I use directories outside of the meteor project for reading/writing/deleting files. I have many files that reside there on a permanent basis as well. I don’t know how to resolve this “requirement” using docker.
I’m currently using EC2 and meteor-up-classic on Meteor 1.3.5.1 and this has worked out great so far.
I have (had) the same problem as you do. I have to access files outside of the main app directory.
I am now using my own fork of mupx with custom startup shell scripts but before I did that is just call these custom shell scripts every time I deployed a new version.
What you wanna do is “mount” the dirs you need into your main docker container. just copy the original shell script from here (you have to edit some bash VARs defined at the top) and add more --volume parameters as you need to access these dirs you define in each param - and every time you deploy you just call this script once after the deployment is finished. (if you use SSL you will see a nginx bad gateway error for maybe 15 secs. don’t worry thats normal). Hope this helps!
1 Like
@klabauter thanks for taking the time out to share this tip with us. I might have more questions for you when/if I decide to tackle this issue again. I have to pick my battles these days, and I solved this one for now with meteor-up-classic (but I hope to move to a docker solution eventually).
Exactly. The reason why you purchase DevOps cheaply on the market.
Learn docker and websockets. But not to deploy a 9to5 app.