‘Modulus deploy’ runned quite well to me. One line of code and all running. Database included. Need to say that the non inclusion of database is the only thing that keeps me out of Galaxy. I’d really like to deploy on Galaxy, but until it offers an integrale solution i’ll stay at modulus.io
Yep I agree, that would be a killer combo. The multi region is especially enticing as the only way to do multi region on Heroku that I know of is to use Route53 and multiple apps on different regions. Using EBS is also a nice feature once you have multiple instances. Though I think Apollo will help to greatly reduce the amount of servers needed.
One nice site to learn these is CBT nuggets as they can really dive in deep (on my short list of things to get into):
https://www.cbtnuggets.com/search?q=aws
Regarding @jsantana 's pain point of compiling apps locally and uploading a large bundle… you can continue down the manual deployment path and write some scripts so that deploying is a one line command. Looking at MUP source code would be a good starting point (as well as writing down everything you manually have to do).
This is very convenient on day 1 but be aware that having your database in Modulus makes it very hard to switch hosts. You would have to migrate all of your data over to a new host in that case. Also more importantly Modulus and MDG are not spending all of their resources and knowledge on maintaining databases while a dedicated database host only focuses on keeping your data. IMHO the odds of having better DB perf and support are way higher with a dedicated host. My personal favorite for Mongo and RethinkDB is Compose.io as they’ve worked out really well for me (I’ve also used MongoLab and Compose for Mongo DBs).
Great thread this. Lots of interesting ideas.
Here we’ve been using mupx for our oldest production app and galaxy for our newest. mupx is great but I’m a little nervous relying on 3rd parties and each release of Meteor I have to wonder if I can update and still deploy with it. Galaxy has being improving steadily and the SSL integration was a big win. So I will be migrating the mupx app to galaxy soon I think.
After reading this thread through I will definitely be looking at Heroku and also CircleCI. Thanks @SkinnyGeek1010 & @siphion.
3 Likes
After initial deployment via mupx or what-have-you.
If your upload speed is the problem consider building a simple second level file watch (like meteor does) of your build dir to scp only the changed files to the server or a free file sync app via sshfs link. Putting said script on the deployment server to build from the source if it’s all minified and merged for single file deployment might save you time but this would be much better on a staging server, which would save on these concerns. Then deploy the slower way to production if nessecary.
If you just use raw js files during staging (no real build process) you can reload the client after pushing changed files via scp or similar sshfs mount. Anyway it seems if you can’t setup a local dev environment sufficiently and upload speed is a problem and you can’t also alternatively run a staging test server environment it seems like a possible solution to me.
It should be possible the deployment system is smart enough to git the release from your repository automatically and your development environment is beyond a sufficient simulation maybe with load testing ability etc. Once a new release is pushed and maybe a signature signed to authenticate etc. a rolling update is self triggered via git notification API.
Alternatively maybe consider a faster connection?
I’ve not studied Heroku.
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).