쉬운 배포 및 업데이트를위한 Node.js 설정

쉬운 배포 및 업데이트를위한 Node.js 설정

---

우리는 현재 CMS에서 제공되는 콘텐츠에 대한 실시간 업데이트를 제공하는 node.js / socket.io 애플리케이션에서 지원하는 고객을 위해 웹 사이트 (Apache의 TYPO3)를 개발하고 있습니다.

이것이 우리의 첫 번째 node.js 프로젝트이기 때문에 '완벽한 설정'에 관한 모범 사례가 없으므로 배포 기술을 연구하는 데 시간을 투자했습니다.

좋은 설정을 얻기 위해 몇 가지 질문이 남아 있습니다.

1. 고객이 쉽게 배포 할 수 있습니다. 이것은 우리 웹 사이트가 풍부한 웹 사이트를 제공하고 고객이 관리하지 않는 서버에서 실행되는 '라이브'TYPO3 설치에 통합 될 것이기 때문에 매우 중요합니다. 느린 과정.

2. 업데이트하기 쉬워야합니다. 다시 시작을 요청하고 서버를 변경하는 것은 느린 프로세스이므로 이상적으로는를 사용하여 라이브 설치에 푸시 된 변경 사항을 수신 할 때 노드 설치를 다시 시작 / 업데이트해야합니다 git.

전개

일반적인 합의는 사용하는 것 같다 forever가 실행을 유지하는 노드 응용 프로그램을 배포에 관해서. 나는 테스트 forever했고 npm install forever -g(global)에 의해 설치되었을 때 잘 작동하는 것 같습니다 . 그래도 라이브 환경에 전역 적으로 설치하려면 외부 지원이 필요하므로 응용 프로그램의 node_modules디렉토리 에서 실행하고 싶지만 견고한 래퍼를 만들 수 없었습니다.

또한 forever잘 작동하지만 수동으로 시작해야합니다. 서버 부팅시 시작되고 계속 실행되도록하는 가장 좋은 방법은 무엇입니까?

• 간단한 init.d스크립트?
• 워치 독 래퍼를 작성 중입니까?
• forever상태 를 확인하는 TYPO3 스케줄러 작업 ?

신속한 개발 / 업데이트시 재시작

우리는 현재 프로젝트의 개발 단계에 있으며 node.js 애플리케이션을 변경할 때마다 수동으로 node또는 forever. 이것은 작동하지만 이상적이지 않습니다. 다음과 같이 npm파일 수정을 확인하고 변경 node이 감지되면 다시 시작하는 몇 가지 작은 모듈이 있습니다 .

• Nodemon
• Node.js 감독자
• 되튐
• 결절 (노드를 다시 시작할 필요가 없으므로와 결합하는 것이 더 쉬울 수 있음 forever)
• 쪽으로

누구든지 이것들에 대한 경험이 있습니까?

업데이트 : 클러스터를 사용하지 않는 이유는 무엇입니까?

클러스터 모듈은 관통 유사한 기능을 제공합니다 재 장전 장치,하지만 노드와 0.5+ 작동하지 않습니다 . 이를 대체 한 핵심 클러스터 모듈 (노드 0.6+) 에는 이러한 모든 기능이 포함되지 않고 클러스터링 만 제공됩니다. 차례로 socket.io에서는 잘 작동하지 않습니다 . 적어도 Redis를 사용하지 않고서 는 안됩니다 (고객에게 다른 필수 서비스를 강제 할 수 없기 때문에 문제가됩니다).

-

분명히 저는 forever고객에게 프로젝트를 넘기기 전에 업데이트-재시동 기와 결합 된 가장 안정적인 솔루션을 찾으려고 노력하고 있으며, 누군가가 검증 된 기술 조합을 생산했으면 좋겠습니다.

---

수집 한 모든 지식 ( 아이디어에 대한 Julian Knight 에게 큰 감사 )과 지난주에 테스트 한 방법을 결합하여 아래에 설명 된 배포 솔루션에 만족하기로 결정했습니다 (비슷한 질문으로 다른 사람들을 도울 수 있으면 좋겠다고 생각했습니다. ) :

스크립트 오류시 자동 재시작 및 스크립트 변경시 자동 다시로드는 forever가 node.js 스크립트 내에서 생성되는 한 스크립트 감시도 포함하므로 forever 에 의해 처리됩니다 .

이를 위해 실제로 실행하려는 스크립트 server.js를 실행 하기 위해를 추가했습니다 app.js.

server.js

var forever = require('forever'),
    child = new(forever.Monitor)('app.js', {
        'silent': false,
        'pidFile': 'pids/app.pid',
        'watch': true,
        'watchDirectory': '.',      // Top-level directory to watch from.
        'watchIgnoreDotFiles': true, // whether to ignore dot files
        'watchIgnorePatterns': [], // array of glob patterns to ignore, merged with contents of watchDirectory + '/.foreverignore' file
        'logFile': 'logs/forever.log', // Path to log output from forever process (when daemonized)
        'outFile': 'logs/forever.out', // Path to log output from child stdout
        'errFile': 'logs/forever.err'
    });
child.start();
forever.startServer(child);

이렇게하면 응용 프로그램 디렉터리의 모든 파일에서 변경 사항을 감시하고 forever하나가 변경되는 즉시 에서 실행중인 스크립트를 다시 시작합니다 . 로그와 pidfile은 애플리케이션의 하위 디렉토리에 있으므로 파일 감시에서 무시해야합니다. 그렇지 않으면 스크립트가 다시 시작됩니다.

.foreverignore

pids/**
logs/**

이 모든 것이 시스템 부팅시 시작되도록 start node-app하고 Ubuntu의 Upstart를stop node-app 사용 하여 서비스를 쉽게 제어 할 수 있도록합니다 . 나는 두 가지 예 (조합 한 이 와 이 하나의) 아주 잘 작업을 수행 하나로를 :

/etc/init/node-app.conf

# This is an upstart (http://upstart.ubuntu.com/) script
# to run the node.js server on system boot and make it
# manageable with commands such as
# 'start node-app' and 'stop node-app'
#
# This script is to be placed in /etc/init to work with upstart.
#
# Internally the 'initctl' command is used to manage:
# initctl help
# initctl status node-app
# initctl reload node-app
# initctl start node-app

description "node.js forever server for node-app"
author      "Remco Overdijk <remco@maxserv.nl>"
version "1.0"

expect fork

# used to be: start on startup
# until we found some mounts weren't ready yet while booting:

start on started mountall
stop on shutdown

# Automatically Respawn:
respawn
respawn limit 99 5

env HOME=/home/user/node-app-dir

script
    # Not sure why $HOME is needed, but we found that it is:
    export HOME=$HOME
    chdir $HOME
    exec /usr/local/bin/node server.js > logs/node.log &
end script

#post-start script
#   # Optionally put a script here that will notifiy you node has (re)started
#   # /root/bin/hoptoad.sh "node.js has started!"
#end script

Kevin이 그의 기사에서 현명하게 언급 했듯이 노드를 루트로 실행하는 것은 현명하지 못하므로 exec sudo -u www-data /usr/local/bin/node다음 주에 새 서버로 이동할 때로 변경할 것입니다 .

So, forever gets started automatically by node server.js which gets launched by upstart, and monitors for crashes and file changes, keeping the entire setup running as long as we want.

I hope this helps anyone.

---

Since my last answer is for the future! Here are some other links to assist:

• https://serverfault.com/questions/274857/how-to-use-node-js-as-a-production-web-server
• http://www.slideshare.net/the_undefined/nodejs-best-practices-10428790 (see slide 35)
• http://www.slideshare.net/the_undefined/nodejs-in-production (slides 31 to the end)
• When node.js goes down, how can I bring it back up automatically?

There doesn't yet seem to be a perfect answer but there are plenty of people running production Node instances. Hopefully this will point you in the right direction.

---

You might be better off, for production use, to look at something like Cluster. You might not want the cluster features but it also includes other production features such as zero downtime restarts, logging, workers, etc.

As you say, Forever is OK for testing but doesn't really have what it takes for production use.

I seem to vaguely remember that Cluster or something similar may be adopted into Node itself come v0.7

ReferenceURL : https://stackoverflow.com/questions/11084279/node-js-setup-for-easy-deployment-and-updating