thank you.
Do you mind sharing which fork you used?
you mean under /opt/my-app-name/app/server ? What are they named?
So this is what needs to be changed in the Mup source?
There is no ssh access on NodeChef but we can certainly install pdftk in your app container. For MongoDB access, we provide a connection string so you can access your database with MongoChef. And the free trial period is for 7 days.
please refer to Meteor 1.3 deploy Error with MUP
I used fork https://github.com/M4v3R/meteor-up Please make sure you follow the steps for reinstall if you are using old MUP.
When MUP is showing the errors, it is using the logs stored on the server. Just look at those logs (not sure about the path …but it should be under /opt/yourapp)… specially lines above the one shown through MUP. I think you have to delete old node-gyp in your home directory, on server, to which MUP refers during installation.Post that it runs happily.
1 Like
@aadams and anyone else using MUP and MUPX, we walked away from MUP and couldn’t be happier. Depending on a what I believe to be a hacky package to deploy your Meteor instance is risky, and also inefficient.
Here is what we did:
- Shell build script that compiles Meteor into the compressed tar, then pushes onto our servers with ssh, then calls local compile and update script
- The local update script restarts pm2 (running n - 1 instances of Meteor, where n is the number of cores) – see # 6 below
- We use tengine (instead of nginx) which includes session-based load balancing out of the box
- We need mongo on the same maching, so we reserve a core for it (hence the n - 1) – but you can use a hosted DB service if you wanted to
- We use icinga2 (you could use Nagios) to check that the instances are up and that the URL is responding
- When restarting the n - 1 instances, we wait 5s between each instance restart to give the chance to the load balancer to transfer traffic over to another instance so we maintain VHA
You should REALLY look into using Galaxy. Takes away so much of your pain (we wanted to, but our real-time app needed Mongo close by)
2 Likes
If it helps:
Local Box:
mupx 1.5.3 (no fork)
Server:
Ubuntu 14.04
Node 0.10.43
Meteor 1.3.4.1
My most successful, long-term deployment strategy has been to use a slightly hacked* version of https://github.com/julien-c/meteoric.sh to deploy iterations of an app on a Debian box starting three years ago when Meteor was at 0.5.7. All I have to do is type meteoric deploy and the four app instances are updated and running about a minute. I have haproxy or nginx load balancing (I’m using this setup for a couple of apps) and also have a 1 member replica set running on the same box. (I don’t use the meteoric setup command – I set up node, mongo, etc., manually.) This is still working with 1.3.5.1, and should continue to work with 1.4 once I’ve updated node, mongo, etc.
* so I can set environment variables in the deploy config file
I’ve had other apps that were running on DO and other on-premise Ubuntu boxes using mup and mupx, but haven’t had much success with either of those since Meteor 1.2. In some cases, I still mupx deploy apps just because it’s an easy one-liner to get a (not working) build on the production server. Then I run a few commands on the server to clean up the build (i.e. remove and install bcrypt and fibers) and start the app instances. It’s a bit annoying, but it works.
In the end, I had to give up on mup and mupx – I don’t think I’ve actually been able to successfully mup deploy or mupx deploy anything since 1.2.
1 Like
Thanks @perumalkuk
I saw this post, and tried a few things within, but maybe I missed something – I’ll try again.
I tried this fork. But I’ll clone it and try again. [quote=“perumalkuk, post:14, topic:27306”]
When MUP is showing the errors, it is using the logs stored on the server. Just look at those logs (not sure about the path …but it should be under /opt/yourapp)… specially lines above the one shown through MUP.
[/quote]
I never looked at the logs on the server, just the error output. I’ll have a look at them.
Thanks for this advice – I’ll give that a try.
@ramez this is a great idea! I’ve always wondered why I never heard of anyone doing this before…
I’m using AWS EC2 and have ssh access. Do you think I could use a script similar to yours to deploy there?
So far, I haven’t had the need for load balancing. But I’ll look into this tech as I grow for sure.
This is exactly what I’m doing – I have mongo on the same EC2 instance.
I’m in the same boat as you, we need mongo close.
Do you have a sample to help me and others get started with this approach?
Hey @aadams, will start sanitizing the scripts, add some explanations and pushing onto GitHub repo - ETA tomorrow - Monday
1 Like
Updated repo and added a few screenshots – hope that helps anyone looking for production grade deployment and for one reason or the other, can’t (unfortunately) use Galaxy.
1 Like
I’ve taken a crack at writing out a few scripts for my deployment situation, some of it lifted from your repo. I need help flushing it out more, any help is appriciated.
@ramez, thank you for all your help so far!
Thanks @ramez. I followed most of your instruction and was able to successfully deploy 1.4. I notice that pm2-web is no longer maintained, ended up using pm2-gui. I was also forced to use ‘npm install’ with ‘unsafe-perm’ flag.
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).
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.
I’m still interested in your script for deployment, if I can get a step by step walk through, I might give it another try on a fresh EC2 box to test.
Wow, this is amazing @perumalkuk! I’m going to follow and see how far I get after I spin up another EC2 instance.
Looks awfully familiar if you ask me 
[I did skip Mongo setup as I assumed it was beyond the scope of typical user, thanks for including it]
I would recommend adding a section about using re-deployment scripts, in other words, what happens when we want to update the Meteor app.
1 Like
Thanks @ramez I have used your guide as reference … hence the similarity. I knew the steps but I was lazy as MUP was working. With 1.4 I had to take the plunge.
I did this document quickly. I will see if I can add the ones you have suggested and nginx and letsencrypt setup … thanks again.
1 Like