Hi, use my gist and adapt it.
You just released your password AND your app name in the wild! Delete that gist right now my friend!!
1 Like
Look more carefully 
you are wrong. But I appreciate the bold warning!! 
1 Like
That is a mup configuration file, this is what I was using since 1.4.2 (with multiple servers) but now it seems to be broken (another time).
My point is about finding a “more trusted way”, something that will not be broken every two releases.
I know that in some days everything will start working again (both “horse” and mup hopefully) but actually the wrong part is that we aren’t supposed to chase meteor changes to deploy… I don’t need to patch/update ssh every time I need to login on my VPS. We need to define some standards to follow, something more like an agreement about how proceed.
I agree with what you are saying. Though what errors you’ve got ? Also, I agree “it should be”. Make it be, start the initiative.
1 Like
Everyone can “start his tool” but if we gather a some (maybe a lot) of developers here on the community maybe we can go over “my interpretation” or “your interpretation” of the right way to deploy, but maybe we can reach “our interpretation” that is useful for more than a handfull of people.
This is my vision, maybe I’m wrong.
Actually I found two promising discussions here that reflect how differents are the deployment methods right now:
Docker: team up to create a reference docker image for meteor (this, about creating a “universal docker image”)
And an older one: Heroku vs Galaxy vs Mupx vs Manual deployment about different approaches.
I’m deploying by hand.
Meteor build then ftp, then tar then copy then restart node.
This is error prone and old school, not “CI” compatible, but for me it works.
5 Likes
Hi @aleritty
Im doing it by hand also… check my repo…
i have a simple script… just paste the folder… change the port … and voila… running.
If you want you can publish you port 80, or other port but you will need to use Nginx, i also left a cool link in the readme…
1 Like
This is intresting, old school bash scripting
My question was more about finding common guidelines but this is a good base.
How do you get environment variables in? Do you just include them in your settings.json and build packs it in with the node app it pushes out?
Like @vjau, I’ve done some manual deployments using that same workflow. To get environment variables in, you can just start the node process with the environment variables already set (either by exporting them individually before issuing node bundle/main.js) or by cut and pasting something like:
sudo PORT=3000 MONGO_URL=mongodb://user:password@127.0.0.1:27017/mydbname?replicaSet=rs0 MONGO_OPLOG_URL=mongodb://oplogger:oploggerpassword@127.0.0.1:27017/local?authSource=admin ROOT_URL=https://mydomainname.com MAIL_URL="smtp://smtp.mydomainname.com/" node bundle/main.js
Manual deployment got tedious after a while, so I’ve got one script to run on the client and one on the server to achieve the same thing (build on client - ftp to server - untar - copy/rename folder - restart node).
I’ve also got that same app deployed to a different server and use a totally different deploy method:
By hacking Julien Chamond’s script (from back in the day …), I’ve got the deploy process down to a mup-like configuration script and one command on the client ( meteoric deploy) to have it up and running on the production server a minute or two later. What it’s doing behind the scenes is: ssh into prod server - pull the latest app version from github - build on the production server - untar - copy/move folder - restart node. There are downsides to this approach (production server CPU burn; intial setup is fiddly), but it does make the deploy process pretty straightforward, once the initial setup is done. Github repo for deploy scripts here.
For other apps, I’ve just pinned them to Meteor 1.2.1 so I can keep using mupx to deploy easily to D.O… (mupx hasn’t worked consistently for me since 1.2.1).
1 Like
try this one
5 Likes
That looks pretty cool. Nice work!
Good idea using pm2 that is rock solid!
I’ve switched from mup to pm2-meteor a month or 2 ago( during The Great 1.2 To 1.4 Transition), and very happy since.
pm2 is a great node process monitor, and pm2-meteor basically a one command deploy tool that bundles your app together with your settings.json, and sends it over to your VPS where pm2 takes over.
We are maintaining the Meteor Azure tool (with a path towards native integration in the future) which is compatible with any version of Meteor >1.4. The main Galaxy features are supported out-of-the-box i.e zero-downtime, one command deployment and you can configure more advanced architectures with multi-region fail-over or auto-scaling rules/schedule.
Not sure what your specific requirements are with deploying to a private network, but you might want to consider looking into Azure’s App Service Environment which is specifically designed for this sort of thing.
This is great. I’m deploying to AWS EC2 instance using Mup modified for Meteor version 1.3.5.1, but have issues once I tried to bump to 1.4.1.
Can/Will you share you procedure and script so I can give this a try myself?
My deployed app is still using Meteor 1.2.1 so i don’t know if this works with 1.4 but i suppose it can be adapted if not.
I’m using Ubuntu 14.04 LTS
I have an upstart script with following content
start on started mongod
stop on shutdown
respawn
setuid node
env MONGO_URL='mongodb://localhost:27017/meteor'
env ROOT_URL='http://xxx.xxx.xxx.xxx:pppp'
env PORT=pppp
env MAIL_URL='smtp://login:pass@url/'
exec /usr/bin/node /var/local/sites/myapp/bundle/main.js >> /var/log/myapp.log 2>&1
You put this script in /etc/init.d/
The bundle is untared in /var/local/sites/myapp
You have to install npm dependencies (look in the readme), with appropriate permissions.
You have to give permission to your node user to write to the log you have specified
I have also a node “script” that does a backup of the database every 30 minutes and upload it on amazon glacier and on my personnal NAS.
EDIT: it seems upstart is replaced by systemd in ubuntu 16.04, so perhaps try that instead
1 Like
This seems great! I’m a newbie regarding deployments, and I’m curious how to get this pm2 tool working to get a meteor server deployed to Amazon. Can someone help me ?
Well, start by installing PM2 on your server. There are several tutorials out there for that. I use Ubuntu 16.04 with nginx and pm2. You can use Amazon, Digital Ocean, or any other VPS provider. Try to get a barebones Node app running on it.
Once that’s working, install PM2-Meteor on your client, fill in the pm2-meteor.json file and pm2-meteor deploy to your server.
pm2-meteor simply builds and bundles your meteor app locally, and then sends that bundle to your server, unpacks it, and lets PM2 take it from there.
PM2 takes care of running, monitoring and logging. It restarts your meteor app in case of crash or server reboot,…
1 Like