프로덕션 Node.js 서버 배포

프로덕션 Node.js 서버 배포

---

저는 Node.js 앱을 작성했으며 프로덕션 머신 중 하나에서 실행하려고합니다. 이것은 매우 일반적인 요청처럼 보이지만 적절한 해결책을 찾을 수 없습니다. 프로덕션 Node.js 앱 배포를위한 확립 된 솔루션이 없습니까?

앱은 간단하지만 (<100 LOC) 매우 효율적이고 안정적이어야하며 다시 시작하지 않고도 수년 동안 계속 실행할 수 있어야합니다. 초당 수십 개의 연결로 대규모 사이트에서 실행될 것입니다. (앱은 웹 서버로 사용되지 않으며 JSON API 만 있습니다.)

다음은 내가 고려한 접근 방식이지만 아직 확실하지 않습니다.

프레임 워크 (예 : Express) 사용

앱은 고성능이어야하고 매우 단순해야하므로 프레임 워크 형태로 부풀려 짐을 추가하는 것은 피하고 싶습니다.

다음으로 서버 시작 nohup

여기서 주된 문제는 예외 처리에 있습니다. 우리는 (분명히) 예외로 인해 전체 서버가 충돌하는 것을 원하지 않습니다. 내가 이해하는 바에 try {} catch {}따르면 Javascript 인터프리터가 예외 후 예측할 수없는 상태로 남아 있기 때문에 전체 앱을 루프로 래핑하는 것은 도움이되지 않습니다. 그 맞습니까?

Forever와 같은 것을 사용

나는 우리의 FreeBSD 시스템에 Forever를 설치했는데 매우 버그가 많았습니다. 결국 Forever에서 죽일 수없는 끝없는 프로세스를 생성했습니다. kill -9내 컴퓨터를 되찾기 위해 실행 해야했고 Forever에서 프로덕션 앱을 실행하는 것에 대해 너무 자신감이 없습니다. 또한 Upstart (유사한 도구이지만 좀 더 일반적인)가 FreeBSD에서 실행되지 않는 것 같습니다.

호스팅 솔루션 (예 : Heroku, Rackspace, Amazon EC2 등)

이것은 아마도 가장 간단한 해결책 일 것입니다. 그러나 우리는 이미 나머지 웹 서버를위한 심각한 하드웨어를 가지고 있습니다. 재정적 고려 사항으로는 말이되지 않습니다.

확실히 이것에 대한 확실한 해결책이 있어야합니까? 내가 뭔가를 놓치고 있습니까?

---

• 세션, 쿠키, 미들웨어 등을 직접 다루고 싶지 않다면 정말 프레임 워크를 사용해야합니다 (전투 테스트를 거쳤으므로 Express와 같은 것을 권장합니다). Express는 정말 가볍습니다.
• nohup으로 서버 시작 : 그렇게해서는 안되며 일반 "node"명령으로 시작하면됩니다. 또한 Express는 경로를 try-catch로 래핑하므로 서버가 경로에서 충돌하지 않습니다. 그러나 서버에 심각한 문제가있는 경우 서버를 다시 시작하는 것을 두려워해서는 안됩니다 (게다가 프로세스가 2-3 개 이상이면 하나만 죽기 때문에 최소한 1-2 개가 남아 있고 사용자는 t 느낌).
• 모니터링을 위해 저는 개인적으로 Upstart 및 Monit 과 같은 OS 수준에서 더 많은 것을 선호합니다 .
• 호스팅 솔루션 : 이미 심각한 하드웨어를 가지고 있기 때문에 다른 것에 투자 할 필요가 없습니다. 부하 분산 장치 (아마도 nginx 또는 node-http-proxy)를 사용하여 작업을 프록시하십시오.

---

Hosting Node Apps를 참조하십시오 .

이 튜토리얼은 서버 측 JavaScript 애플리케이션을 위해 node.js 앱을 호스팅 할 수있는 서버를 설정하는 과정을 안내합니다. 현재 node.js 호스팅 옵션은 웹 서버와 통신하는 노드 데몬 프로세스를 실행하는 것으로 요약됩니다. 대부분의 웹 서버는 다른 포트에 대한 연결을 프록시 할 수 있으므로 Apache 또는 nginx를 사용하여이를 수행 할 수 있습니다.

---

여기에 세 가지 질문이 있습니다.

질문 0 : "노드 앱에 프레임 워크를 사용해야합니까?"

질문 1 : "프로덕션 머신에서 노드 서버를 어떻게 실행합니까?"

질문 2 : "노드 앱을 프로덕션에 배포하는 방법".

들어 질문 하나 , 내가 정말 좋아 클러스터 (최신 노드 버전이 내장 그런 일을 가지고 있지만, 그래서 당신은 체크 아웃 수도 있습니다). 저는 Monit / Upstart와 같은 것을 통해 OS 레벨 이벤트를 모니터링하고 서버가 양호한 상태인지 확인하는 데 성공했습니다. (이것은 Ruby Thin 서버의 N 클러스터를 모니터링했지만 같은 것입니다).

트래픽에 따라 여러 시스템에서 클러스터를 실행 한 다음 그 앞에로드 밸런서를 배치 할 수 있습니다. 이는 트래픽, 요청을 완료하는 데 걸리는 시간 / 이벤트 루프를 차단하는 시간, 머신 당 시작하는 프로세서 / 노드 인스턴스 수에 따라 다릅니다.

프레임 워크는 더 나은 오류 처리를 제공하고 일반 node.js 앱을 종료하는 오류를 포착합니다. 프레임 워크없이 수행하는 경우 node.js에서 오류 처리에 대해 읽어야합니다.

대한 질문이 , 내가 노드 사회가 아직 좋은 배포 표준을 가지고 있다고 생각하지 않습니다. Ruby의 Capistrano 도구를 사용해 볼 수 있습니다 (여기 에는 Capinstrano를 사용한 클러스터 배포에 대해 설명하는 블로그 항목이 있습니다 ).

Capistrano의 나쁜 점은 사실이 아닐 수도있는 몇 가지 가정 (예 : Rails 프로젝트를 배포하고 있음)을 내놓기 때문에 결국 프레임 워크와 많이 싸우게 될 수 있다는 것입니다.

일반적으로 내 goto 배포 솔루션은 배포 도구를 제공하고 필요한 작업을 수행 할 수있는 Python의 Fabric 도구입니다.

또 다른 배포 옵션은 Nodester 와 같은 "클라우드" 입니다.

---

pm2를 사용해보세요. NPM을 통해 설치 가능한 간단하고 직관적 인 CLI입니다. PM2로 애플리케이션을 시작하기 만하면 애플리케이션이 수많은 트래픽을 처리 할 준비가됩니다.

PM2 공식 링크

pm2를 사용하여 프로덕션 용 노드 js 애플리케이션을 설정하는 방법

---

당신은에 Serverfault에 걸쳐 더 나은 답변을 얻을 수 있지만, 설명 거기에 하나의 사용자의 현재 경험 사용은 supervisord. 프로세스를 유지하기 위해 일종의 프로세스 감시자를 사용해야 할 것이며 node, 또 다른 일반적인 권장 사항은 node어떻게 든 프로세스 에 대한 리버스 프록시 연결 인 것 같습니다 . 나는 아마도 nginx(이렇게 nginx하면 로깅, 인증 또는 필요한 다른 상위 수준의 HTTP 기능을 노드에 베이킹하는 것과는 반대로 처리 할 수 있음)에 투표 할 것 haproxy입니다. 더 가볍습니다. 리버스 프록시 선택은 WebSocket 지원이 필요한지 여부에 따라 크게 달라집니다.

아직 노드에 대한 "표준"워크 플로가 더 이상 존재하는지 잘 모르겠습니다. 웹앱을 계속 실행하는 무수한 방법을 가진 Rails처럼 성숙하지는 않습니다.

---

Cloudkick의 직원들은 이에 대한 훌륭한 솔루션을 썼습니다. 그것은라고 Cast, http://cast-project.org/ .

서버와 워크 스테이션에 캐스트를 설치하십시오. 서버에서 캐스트 에이전트를 시작하고 워크 스테이션이 서버 캐스트 인스턴스로 서명하도록합니다. 그런 다음 "번들"을 생성하고, 서버에 업로드하고, 생성 / 업그레이드 / 파괴하고 인스턴스를 시작 / 중지 할 수 있습니다. 서비스가 다운되면 Cast가 자동으로 서비스를 다시 시작합니다. 또한 stdout / strerr을 원격으로 추적 할 수있을뿐만 아니라 실행중인 인스턴스 및 PID # 목록을 가져오고 워크 스테이션에서 인스턴스 / 서버를 관리 할 수 ​​있습니다 (SSHing 필요 없음). 문서는 약간 구식이지만 결과는 약간의 추가 작업의 가치가 있습니다. 모든 상호 작용 / 명령은 HTTPS 및 RESTful API를 통해 이루어집니다.

이 전에는 SCP / SSH를 사용하여 모든 업그레이드를 수작업으로 수행했습니다. 우리는 supervise상황 을 유지하고 있습니다. 우리는 뒤돌아 보지 않았습니다.

참고 URL : https://stackoverflow.com/questions/8386455/deploying-a-production-node-js-server