WAS를 System Service로 만들기

Linux System Service

• 리눅스의 systemd가 관리하는 service를 system service라고 한다.
• systemd를 컨트롤하기 위해 systemctl을 사용한다.
• 시스템 차원에서 등록한 service의 실행관리를 해준다.

아파치나 mongodb, mysql을 직접 설치하고 돌릴 때, 모두 이 system service 가 실재 실행 파일을 찾아서 돌리는 것이였다.

sudo systemctl start mongod

와 같은 명령처럼, 내가 내 앱(파이썬이나 ,node.js, go로 만든) 서비스를  'myservice' 라고 지정했다면

sudo systemctl start myservice
sudo systemctl stop myservice

와 같은 명령어로 쉽게 컨트롤 할 수 있다.

시스템 서비스로 운영했을 때 장점

• 실행 관리 - 시스템 재부팅 시 자동 재시작, 서비스의 자동 복구가 가능하다.
• 일관성 - 모든 서비스가 동일한 인터페이스로 관리된다.
  • 서비스 관리 - 시스템 상태를 쉽게 확인, 단일 명령으로 시작, 중지, 재시작이 가능하다.
  • 로깅 통합 - journalctl 명령으로 로그 확인이 쉽다.
• 의존성 관리 - 서비스 간 시작 순서를 설정할 수 있다.
• 병렬화된 부팅 - 부팅 프로세스를 알아서 최적화해준다.

nohup과 비교

초보자때 많이 사용하는 nohup은 위와 비교해 아래와 같은 것들을 해야 했다.

• 실행 관리 - corn이나 rc.local에 등록하면 자동 재부팅이 된다.
• 일관성
  • 서비스 관리: 전역적 실행이 아니라, 해당 디렉토리로 직접 찾아가 실행해야 한다. (물론 전역으로 프로그램을 등록하는 방법도 있다.)
  • 로그: 따로 어디에 저장해야 할지 작성해야 한다. 중앙 집중은 안 된다.
• 의존성 관리 - 할 수 없다. 수동으로 순서대로 해줘야 한다.
• 부팅 최적화 - 할 수 없다.

서비스 등록 방법

1. /etc/systemd/system 아래에  서비스명.service 라는 파일을 생성한다.
2. .service 파일의 내용을 작성한다. (형식은 아래에 기재)
3. sudo systemctl daemon-reaload  명령을 통해, 새로 작성/수정/삭제한 서비스를 systemd가 감지하도록 한다.
4. sudo systemctl start 서비스명  (.service는 생략 가능) 명령을 통해 시작한다.

파일 형식

[Unit]
Description=Go Application
After=network.target

[Service]
ExecStart=/data/myservice/server
WorkingDirectory=/data/myservice
Restart=always
User=root
Group=root

[Install]
WantedBy=multi-user.target

• Unit : 유닛에 대한 설명과, 의존성
  
  • Description : 설명
  • After : 먼저 실행돼야 하는 유닛 (여기서는 네트워크 초기화가 이루어진 후 실행돼야 하는 걸 말한다.)
• Service: 실행 파일, 작업 디렉토리, 리스타트, 권한
• Install : 언제, 어떻게 활성화되거나 설치될지
  • WantedBy : 어떤 타겟의 일부로 포함될지

* 유닛은 특정 작업, 상태, 프로세스 또는 리소스를 나타낸다. (서비스, 타깃, 소켓 등) 
* 타깃은 서비스가 systemd실행 모드를 나타낸다. init(systemd의 이전 버전)기반의 런레벨과 비슷한 개념이다. (multi-user.target)이 일반적이다.

실행 확인

그냥 프로그램 명으로 실행했을 때

systemd로 실행후 status를 확인했을 때

sudo journalctl -u github-runner -f  로 실시간 로그를 확인할 수도 있다. 

systemd 커맨드 치트 시트

내 생각

• python이나 node.js 파일을 nohup이나 nodaemon으로 관리하는 것보다는 나은 것 같다.
• 그런데 자세히 보면 재시작 같은 관리는 docker에서도 다 해주는 것이다.
• service는 등록 과정 등 os별 설정 과정이 필요하므로 확장성을 위해서 docker로 관리하는 것이 편해 보인다. 로그 관리만 좀 더 신경쓰면 될 것 같다.
• 결론은 도커를 할 줄 안다면 도커로 하는게 나을 것 같다.