6

I run my meteor app on EC2 like this: node main.js (in tmux session)

Here are the steps I use to update my meteor app:

1) meteor bundle app.tgz

2) scp app.tgz EC2-server:/path

3) ssh EC2-server and attach to tmux

4) kill the current meteor-node process by C-c

5) extract app.tgz

6) run "node main.js" of the extracted app.tgz

Is this the standard practice?

I realize forever can be used too but still do you have to kill the old node process and start a new one every time I update my app? Can the upgrade be more seamless without killing the Node process?

Dan Dascalescu
  • 143,271
  • 52
  • 317
  • 404
Krishna Srinivas
  • 1,620
  • 1
  • 13
  • 19

3 Answers3

7

You can't do this without killing the node process, but I haven't found that really matters. What's actually more annoying is the browser refresh on the client, but there isn't much you can do about that.

First, let's assume the application is already running. We start our app via forever with a script like the one in my answer here. I'd show you my whole upgrade script but it contains all kinds of Edthena-specific stuff, so I'll outline the steps we take below:

  1. Build a new bundle. We do this on the server itself, which avoids any missing fibers issues. The bundle file is written to /home/ubuntu/apps/edthena/edthena.tar.gz.

  2. We cd into the /home/ubuntu/apps/edthena directory and rm -rf bundle. That will blow away the files used by the current running process. Because the server is still running in memory it will keep executing. However, this step is problematic if your app regularly does uncached disk operatons like reading from the private directory after startup. We don't, and all of the static assets are served by nginx, so I feel safe in doing this. Alternatively, you can move the old bundle directory to something like bundle.old and it should work.

  3. tar xzf edthena.tar.gz

  4. cd bundle/programs/server && npm install

  5. forever restart /home/ubuntu/apps/edthena/bundle/main.js

There really isn't any downtime with this approach - it just restarts the app in the same way it would if the server threw an exception. Forever also keeps the environment from your original script, so you don't need to specify your environment variables again.

Finally, you can have a look at the log files in your ~/.forever directory. The exact path can be found via forever list.

Community
  • 1
  • 1
David Weldon
  • 63,632
  • 11
  • 148
  • 146
1

David's method is better than this once, because there's less downtime when using forever restart compared to forever stop; ...; forever start.

Here's the deploy script spelled out, using the latter technique. In ~/MyApp, I run this bash script:

echo "Meteor bundling..."
meteor bundle myapp.tgz
mkdir ~/myapp.prod 2> /dev/null
cd ~/myapp.prod
forever stop myapp.js
rm -rf bundle
echo "Unpacking bundle"
tar xzf ~/MyApp/myapp.tgz
mv bundle/main.js bundle/myapp.js
# `pwd` is there because ./myapp.log would create the log in ~/.forever/myapp.log actually
PORT=3030 ROOT_URL=http://myapp.example.com MONGO_URL=mongodb://localhost:27017/myapp forever -a -l `pwd`/myapp.log start myapp.js
Dan Dascalescu
  • 143,271
  • 52
  • 317
  • 404
0

You're asking about best practices.

I'd recommend mup and cluster

They allow for horizontal scaling, and a bunch of other nice features, while using simple commands and configuration.

Michael Cole
  • 15,473
  • 7
  • 79
  • 96