我在EC2上运行我的meteor应用程序:node main.js
(在tmux会话中)
以下是我用来更新meteor app的步骤:
1)meteor bundle app.tgz
2)scp app.tgz EC2-server:/ path
3)ssh EC2-server并附加到tmux
4)用C-c杀死当前的流星节点进程
5)提取app.tgz
6)运行解压缩app.tgz的“node main.js”
这是标准做法吗?
我意识到forever
也可以使用,但是你每次更新我的应用程序时都必须杀死旧节点进程并启动一个新进程吗?升级是否可以更加无缝,而不会破坏节点进程?
答案 0 :(得分:7)
如果不杀死节点进程,你不能这样做,但我没有发现真的很重要。实际上更烦人的是客户端上的浏览器刷新,但是你无能为力。
首先,我们假设应用程序已在运行。我们通过forever启动我们的应用程序,其脚本与我的答案here中的脚本类似。我将向您展示我的整个升级脚本,但它包含各种特定于Edthena的内容,因此我将概述下面的步骤:
构建新捆绑包。我们在服务器本身上执行此操作,这可以避免任何missing fibers问题。捆绑文件将写入/home/ubuntu/apps/edthena/edthena.tar.gz
。
我们cd
进入/home/ubuntu/apps/edthena
目录和rm -rf bundle
。这将吹走当前运行进程使用的文件。因为服务器仍在内存中运行,所以它将继续执行。但是,如果您的应用程序定期执行未缓存的磁盘操作,例如在启动后从private
目录中读取,则此步骤会出现问题。我们没有,所有静态资产都由nginx提供,所以我觉得这样做很安全。或者,您可以将旧bundle
目录移至类似bundle.old
及should work的目录。
tar xzf edthena.tar.gz
cd bundle/programs/server && npm install
forever restart /home/ubuntu/apps/edthena/bundle/main.js
这种方法确实没有任何停机时间 - 它只是以服务器抛出异常时的方式重新启动应用程序。 Forever还保留了原始脚本的环境,因此您无需再次指定环境变量。
最后,您可以查看~/.forever
目录中的日志文件。确切的路径可以通过forever list
找到。
答案 1 :(得分:1)
大卫的方法比这更好一次,因为使用forever restart
与forever stop; ...; forever start
相比,停机时间更短。
这是使用后一种技术拼写出来的部署脚本。在~/MyApp
中,我运行此bash脚本:
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
答案 2 :(得分:0)