[Q] November 2016 - State of deployments for actual Meteor (1.4.2)?

deployment
1

Hi!

I’m really concerned because deploying is becoming more complicate every release from some times now.
I know that meteor official way to deploy is galaxy, but I need to deploy to a private network; and other than this I firmly believe that we have the right to deploy wherever we want/need, without constrictions

I was using kadirahq/mup (the original, not mupx) to deploy to my VPS (using docker).

Otherwise I was using heroku, with the “horse” buildpack.

Actually with the 1.4.2, as I know (maybe i’m wrong) neither of this method works anymore.

Maybe we can try to find a method that can be community driven, defining some standards that hopefully will last longer. Like Arunoda’s mantra project vision.

Personally I’m really disappointed about all this breaking changes in the platform, Meteor is wasting his audience right now and this is a real pity for this really good tool.

4 Likes
2

Hi, use my gist and adapt it.

3

You just released your password AND your app name in the wild! Delete that gist right now my friend!!

1 Like
4

Look more carefully :slight_smile: you are wrong. But I appreciate the bold warning!! :smiley:

1 Like
5

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.

6

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
7

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.

8

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
9

Hi @aleritty

Im doing it by hand also… check my repo…

meteor-deployment

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
10

This is intresting, old school bash scripting :smiley:

My question was more about finding common guidelines but this is a good base.

11

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?

12

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
13

try this one

5 Likes
14

That looks pretty cool. Nice work!

15

Good idea using pm2 that is rock solid!

16

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.

17

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.

18

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?

19

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
20

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 ?