@aadams if you are open to trying other solutions, you could certainly consider NodeChef; the easiest way to deploy Meteor 1.3 and 1.4 apps
I’m interested, but I have a requirement, where I need to have pdftk installed on the local box. It’s a standard install, where I ssh into the EC2 instance and do a sudo apt-get install pdftk. I’ll eventually want SSL support too. I need to be able to have a relatively static IP that I’ll point a domain of my choosing to. Also, I use MongoChef for database access (ssh into it) as well.
If all this is possible, and you can provide step by step instructions, and it works of course, I’m open to giving it a try for a month or so as a trial run.
I am using MUP with 1.3.4.1 and it works. You will find in the forum discussion about it. I used one of the forks of MUP which has architecture flag.
My suggestion is to look at the npm logs on the server under the server directory in your app. You will get clues.I think it is to do with the version of node-gyp used by MUP. Check your version of node-gyp on server ( mine is 3.4.0). I think MUP uses a old version.
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.