소개

PM2는 Node.js 애플리케이션을 위한 고급 프로덕션 프로세스 매니저입니다.

이 도구는 애플리케이션을 백그라운드에서 실행하고, 다운되면 자동으로 재시작하며, 로드 밸런싱을 위한 클러스터 모드를 제공하는 등의 기능을 포함하고 있습니다.

 

사용하는 이유

PM2는 주로 아래와 같은 기능들 때문에 널리 사용됩니다:

  1. 프로세스 관리: PM2는 애플리케이션을 백그라운드에서 실행하고, 애플리케이션이 실패했을 때 자동으로 재시작합니다. 
  2. 로드 밸런싱: 여러 인스턴스를 실행하여 애플리케이션의 부하를 분산시키는 클러스터 모드를 제공합니다. 이는 시스템 리소스를 효율적으로 사용하고 성능을 향상시키는 데 도움을 줍니다.
  3. 로그 관리: 실행 중인 프로세스의 로그를 관리하고, 쉽게 접근할 수 있게 해 줍니다. 이는 문제 해결 과정에서 큰 도움을 줍니다.
  4. 무중단 서비스: PM2는 노드 애플리케이션을 무중단으로 운영할 수 있도록 돕습니다. 코드를 변경한 후에도 서비스를 중단하지 않고 업데이트할 수 있습니다.

 기본적인 사용방법

- 설치

$ npm install -g pm2@latest

 

- pm2 를 이용한 애플리케이션 실행

$ pm2 start app.js

 

-  프로세스 삭제 , 중단,  모든 프로세스 죽이기

$ pm2 delete 프로세스id
$ pm2 stop 프로세스id
$ pm2 kill

 

- 프로세스 재시작/ 리로딩

$ pm2 restrart 프로젝트실행파일이름.js // 선호되지 않는 명령어 :프로세스를 kill하고 시작
$ pm2 reload 프로젝트실행파일이름.js // 선호 : 프로세스를 kill 하지 않고 바로 적용

 

- 프로세스 상태확인

$ pm2 status
$ pm2 list

   status : 현재 실행중인 프로세스의 운영상태에 초점을 맞춘 정보 제공

   list :  모든 관리 중인 프로세스에 대한  포괄적인 세부 정보 제공 

 

- 프로세스 모니터링

$ pm2 monit

 

 

무중단 서비스 적용 방법

→ cluster 모드로 실행  : Node.js가 싱글 스레드라서 주어진 자원을 최대한 활용하지 못하고 하나의 CPU만 사용하는 문제를 해결할 수 있습니다.

 

- ecosystem.config.js 파일 생성

$ pm2 ecosystem

 

- 파일을 아래와 같이 수정

apps: [{
  name: 'app',
  script: './app.js',// 실행해야하는 스크립트 입력
  instances: 0, // cpu 코어수 만큼 프로세스 생성
  exec_mode: ‘cluster’, // 모드 변경
  env: {
      NODE_ENV: 'local',
    },
  }]

  참고로 app 에 사용할 수 있는 변수는 다음과 같다.

  • name : 실행 모드 이름
  • script : 실행되는 파일
  • instances : 프로세스 수
  • autorestart : 재시작 on/off
  • watch : watch on/off
  • env: Node.js 환경변수 

프로세스 증가 / 감소

$ pm2 scale app +4 // 프로세스 4 증가
$ pm2 scale app 4  // 프로세스 4 감소

 

- 실행

$ pm2 start ecosystem.config.js

 

 

 참고자료

  1. https://engineering.linecorp.com/ko/blog/pm2-nodejs
  2. https://any-ting.tistory.com/74  
  3. pm2.keymetrics.io/

폴더삭제 명령어

$ rmdir '삭제할 폴더명'

 

폴더 안에 뭐가 다른 파일이나 폴더가 있을경우 삭제가 되지 않는 경우

 

$ rm -rf '삭제할 폴더명'

 r : 파일 디렉토리 함께 삭제하기

 f : 파일 유무와 상관없이 삭제하기

npm run build

{
...
"scripts": {
    "build": "nest build",
    ...
    }
...
}

 터미널에서 npm run build 를 입력하면 package.json 에 있는 위의 스크립트가 실행됩니다.

실행이 완료되면, 프로젝트의 소스 코드가 dist 디렉토리 아래에 컴파일된 결과물로 저장됩니다..

이렇게 생성된 파일들은 배포에 사용됩니다.

또한,  aws-ec2 프리티어 micro 에 배포할 때  npm install 시 발생할 수 있는 메모리 부족현상을 해결 할때도 용이합니다.

npm run start:prod

"scripts": {
  "start:prod": "node dist/main"
}

     이 스크립트를 실행하면, dist 디렉토리 내의 main.js 파일이 Node.js를 통해 생성된 JavaScript 파일을 사용하여 애플리케이션이 실행됩니다.

 

이때, 빌드할 때 환경변수를 .env 를 통해 입력되도록 했으면  NODE_ENV 를 적용하여야 합니다.

빌드 과정을 마친 후, package.json 에 있는 스크립트를 아래의 예와 같이 수정하여 애플리케이션을 실행합니다.

"scripts": {
  "start:prod": "NODE_ENV=prod node dist/main"
}

 

Build 를 하는 이유 

Nest.js는 주로 TypeScript로 작성됩니다.

TypeScript는 JavaScript로 컴파일되어야 런타임에서 실행될 수 있습니다.

Build 과정에서 TypeScript 코드가 JavaScript 코드로 변환됩니다.

이 Build 과정을 통해 프로덕션 모드를 위한 애플리케이션을 빌드합니다.

이 과정에서 개발을 위한 의존성이 제외되고 배포만을 위한 의존성만 남게된다.

-> 클론 후 npm install 시 설치해야할 패키지들이 줄어든다. 

 

  package.json package-lock.json
역할 - Node.js 프로젝트에서 사용되는 json 파일.
- 프로젝트의 메터데이터(이름, 버전 등)와 의존성 목록을 정의
- 프로젝트에서 설치된 의존성의 정확한 버전과 의존성 트리를 저장
- 패키지 설치시 추가적으로 설치된 패키지들의 버전을 저장
필요성 - 개발자 간 협업 시 환경의 일관성을 유지 - 빌드의 일관성을  보장
- 배포나 빌드시 버전 충돌이나 예기치 않은 버그를 방지
차이 - 범용적인 의존성 정보를 제공 - 이미 설치된 의존성의 정확한 버전과 구조를 저장

 

 

참고자료

  1. https://velog.io/@songyouhyun/Package.json%EA%B3%BC-Package-lock.json%EC%9D%98-%EC%B0%A8%EC%9D%B4
  2. https://www.geeksforgeeks.org/difference-between-package-json-and-package-lock-json-files/

Git Flow

복잡한 프로젝트 관리를 위해 여러브랜치를 사용하는 전략이다.

장점 : 뚜렷한 브랜치 구조는 대규모 팀이나 프로젝트에 적합하고, 버전 관리와 출시가 용이하다.

단점 : 복잡하고 브랜치 관리가 어려울 수 있으며, 작은 프로젝트나 빠른 개발 사이클에는 비효율적일 수 있다.

GItHub Flow

단순화된 방식으로, main 브랜치 하나와 기능 브랜치들로 구성된다. 모든 변경사항은 main 으로 병합되기 전에 리뷰된다.

장점 : 단순하고 이해하기 쉬우며, 지속적인 배포와 통합에 적합하다.

단점 : 매우 크고 복잡한 시스템에서는 충분한 구조를 제공하지 않을 수 있다.

GitLab-flow

위의 두 전략의 장점을 결합하여 환경에 따라 코드를 배포하는 유연한 전략이다.

장점 : 유연하며 다양한 배포 환경에 적응할 수 있다. 코드 관리와 릴리스가 분리되어 있어 안정성을 높일 수 있다.

단점 : 설정과 관리가 복잡할 수 있으며, 전략을 완전히 이해하고 적용하기 위해서는 경험이 필요할 수 있다.

 

요약 및 정리

전략 브랜치 구조 주 사용 사례 장점 단점
Git Flow master, develop, feature, release, hotfix 대규모 프로젝트, 복잡한 릴리스 사이클 체계적인 브랜치 관리 가능 설정 및 관리 복잡성
GitHub Flow main, feature, 지속적인 배포와 통합, 단순 프로젝트 간단하고 빠른 개발사이클에 적합 대규모, 복잡한 시스템 관리에 한계
GitLab master, pre-production, production 다양한 배포 환경, 유연한 워크 플로우 필요 환경별 코드 배포 가능 초기 설정이 복잡하며 유지 관리에 노력이 필요

 

 

참고자료

  1. https://wiki.yowu.dev/ko/dev/Git/about-git-github-gitlab-flow
  2. https://velog.io/@kw2577/Git-branch-%EC%A0%84%EB%9E%B5
  3. https://blog.hwahae.co.kr/all/tech/9507

+ Recent posts