We’ve been using this for quite some while now, its an ansible script complete with HAProxy (optional) + nginx-passenger + Mongo deployment: https://github.com/smowden/meteor-ansible
Check out the tests directory for different configurations
We’ve been using this for quite some while now, its an ansible script complete with HAProxy (optional) + nginx-passenger + Mongo deployment: https://github.com/smowden/meteor-ansible
Check out the tests directory for different configurations
So meteor-ansible and phusion passenger are to be used together? Is there a guide?
what do you mean? Phusion-Passenger is a server that handles loadbalancing and spawning meteor instances, meteor-ansible is a script that sets up your server to serve meteor using phusion passenger.
I’m going to be deploying a large app, wondering about the current state of deployment overall in Meteor 1.3/1.4?
Galaxy pricing is too high and management would rather take more time to deploy on our own.
I had planned on deploying to DigitalOcean, but I have seen a lot of these type of topics appearing lately so I am a bit reluctant.
Would MUP or any alternatives be suggested in my position? Any advice or pitfalls I should be aware of?
I don’t like to keep ‘marketing’ our solution but here it is again given your question:
We also use Digital Ocean. The pitfall is that we have not yet automated new servers (budget 30 mins for a new server the first time around to get things going), but once setup, we have automated deployment to existing servers. Automating new servers is on our todo (https://github.com/ramezrafla/meteor-deployment/issues/3)
I wrote a quick tutorial on deploying a meteor app to DO box in less than 10 minutes if anyone here is interested.
I posted in another thread as well
I forked arunoda’s meteor-up (it is abandoned, with the last version here was 0.11.3 and created a brand new repo that picks up where it left off – namely supporting 1.2 + deployments without docker. I called it meteor-up-classic. I’ve successfully gotten 1.3.5.1 running using mup-classic (where as arunoda’s mup doesn’t support anything above meteor 1.2).
Of course if you need or want docker, kadirahq’s meteor-up is where the new development is taking place. In my case I can’t use docker because I need access to the file system (read/write/delete dirs and files) OUTSIDE of the Meteor application and don’t know enough about docker and how to configure that (and don’t have the cycles to figure it out right now) – hence meteor-up-classic.
Good points! Working like that sounds simple and effective.
In the future it might still be worth it to make an API or use an existing one to handle your file management. In the end accessing local files for permanent storage will become quite an headache and it might limit your growth potential. Also a bit separation of concerns may just be well. Off course it totally depends on your project, this is in general the case.
If it works just fine but don’t limit yourself too much on platforms just because you want access to local files. There are a multitude of other options for that.
Only issue is that you can’t easily connect to Mongo, if you run Mongo on your server as well.
why not? you can connect to any mongo instance (no matter whereis it placed)
I also use this fork with 1.4 and it works fine for me .
I’ve just added a feature to my mup fork I wanted to add for very long. Now when deploying, mup shows you the path of bundle.tar.gz
file it builds. If the deployment fails for some reason, you can try to deploy again without going through the lengthy build process again, by supplying bundle.tar.gz path as an argument:
mup deploy /path/to/bundle.tar.gz
I’ve noticed that in some cases there was a problem with node-gyp, and installing it separately fixed the issue.
Also @M4v3R your install-node.sh file still looks to install the old version of node by default:
# Install Node.js - either nodeVersion or which works with latest Meteor release
<% if (nodeVersion) { %>
NODE_VERSION=<%= nodeVersion %>
<% } else {%>
NODE_VERSION=0.10.43
<% } %>
It only does that when there’s no nodeVersion param in the mup.json file. Which is ok, because this parameter is there by default, and if someone deleted it on purpose, he would probably expect it to be 0.10.43 even after upgrading.
Alright. No worries, anyhow, in meteor-up-classic I made the change to this file too just in case.
Thanks Serkan! @serkandurusoy
I’ve been struggling with a mup? deployment for weeks now, and your link to Phusion Passenger and their walkthrough on deploying a Meteor app (1.3.3) worked perfectly for me on an Ubuntu 14.04.x EC2 instance.
I owe you a big beer!
Thanks again.
pm2-meteor is another option. I think one advantage with mup is that it handles mongod for you (on the same server), whereas pm2-meteor and Passenger require you to handle the mongod setup.
Thanks Sam @ffxsam
I already have a MongoDB instance on an EC2, so that’s already taken care of.
I tried pm2-meteor, see my post on discord. I’ll have to revisit it , but I really liked Phusion.
pm2-meteor worked, but maybe it was my app conflicting with the version of jQuery I had (or however it got) installed,
via NPM.