Jenkins 자동 재기동을 위한 서비스 파일 생성

Jenkins 비정상 종료 시 자동 시작하는 systemd 서비스 파일

테스트 환경

• NHN Cloud
• Ubuntu 20.04 LTS
• Docker 23.0.3
• Jenkins 2.399
• Python 3.9

 

상황

Jenkins가 비정상적으로 종료되었을 경우, Jenkins가 자동 실행되게 하도록 합니다.

 

해결방법

• sudo systemctl enable jenkins 명령어 실행
  • Failed to enable unit: Unit file jenkins.service does not exist.와 같은 오류가 발생합니다.
• Jenkins Docker 컨테이너를 자동 시작하는 systemd 서비스 파일을 생성하여 적용해줍니다.

1. /usr/lib/systemd/system 디렉토리에 jenkins.service파일 생성

sudo vi /usr/lib/systemd/system/jenkins.service

 

2. 파일 내용 작성

[Unit]
Description=Jenkins container
Requires=docker.service
After=docker.service

[Service]
Restart=on-failure
Group=docker
ExecStart=/usr/bin/docker start -a jenkins
ExecStop=/usr/bin/docker stop -t 2 jenkins

[Install]
WantedBy=multi-user.target

Jenkins Docker 컨테이너를 관리할 새 systemd 서비스인 jenkins를 정의합니다.

 

서비스 파일에는 세 개의 부분이 있습니다.

• [Unit]: 서비스가 필요로하는 모든 항목을 나열합니다. 적용하기 위해서는 Docker 서비스가 실행 중이어야 합니다.
• [Service] :
  • Restart=on-failure : 서비스가 어떤 이유로 실패하거나 중지되면 자동으로 다시 시작되어야함을 지정
    • 서비스가 비정상적으로 종료되었을 때에만 동작함. 호스트 머신이 강제 종료되는 경우는 시스템 수준의 이벤트로서 서비스 자체의 종료와는 다르기 때문에 일반적으로 호스트 머신이 강제 종료될 때는 systemd가 서비스를 재시작하지 않음. -> 데몬 감시 스크립트 등록이 필요할 것으로 생각됨
  • Group : irteam, irteamsu, root 사용자 모두 실행 가능하도록 Group 설정
  • ExecStart : Jenkins 컨테이너를 시작하는 명령을 지정
  • ExecStop : Jenkins 컨테이너를 중지하는 명령을 지정
• [Install]: 서비스가 시작될 때, 이 경우 multi-user.target 레벨에서 시작됨을 지정

 

3. 새 서비스 파일을 인식하도록 systemd 데몬을 다시 로드합니다.

sudo systemctl daemon-reload

서비스 파일에 대한 변경 사항을 인식하도록 systemd 데몬을 다시 로드하는 것입니다.

 

4. Jenkins 서비스를 부팅 시 자동 시작하도록 설정합니다.

sudo systemctl enable jenkins

 

결과

1. Jenkins 비정상 종료 시 Jenkins 도커 컨테이너가 자동으로 실행되는 것을 확인하기

• SIGABRT 로 비정상 종료 됨

 

• 자동 재실행 됨

 

• 로그

 

2. 호스트 머신 비정상 종료(reboot) 시 Jenkins 도커 컨테이너가 자동으로 실행되는 것을 확인하기

• systemctl enable 명령어로 reboot 가능 확인!

 

systemd 서비스 파일 설정

[Service]

Restart=[no|on-success|on-failure|on-watchdog|on-abort|always]

• 해당 유닛이 죽었을 때나 혹은 WatchdogSec만큼의 시간 동안 응답이 없는 경우 재시작한다.
• no (기본값) : 유닛을 다시 시작하지 않는다.
• on-success: 유닛이 정상적으로 종료 되었을 때만 재시작한다.
  • 종료 시 '0' 값을 리턴하여 종료 되었거나 SIGHUP, SIGINT, SIGTERM, SIGPIPE 등과 같은 시그널 또는 SuccessExitStatus 설정에서 지정된 리턴 코드 목록에 따른 시그널에 대해서 모두 성공으로 인식해 재시작 하게 된다.
• on-failure : 유닛이 비정상적으로 종료 되었을 때 재시작한다.
  • 리턴값이 '0' 이 아닌 경우, core dump 와 같이 비정상적인 시그널을 받고 종료된 경우, 타임 아웃값 내 응답이 없는 경우 등 재시작한다.
• on-watchdog : WatchdogSec 에 설정된 시간 내 응답이 없는 경우에만 재시작한다.
• on-abort : 지정되지 않은 리턴값을 받은 경우 재시작한다.
• always : 종료 상태 등과 무관하게 무조건 재시작한다.
  • 사용자가 중지해도 시스템이 다시 띄워지게 되므로 설정된 유닛 중지 시 주의 필요

시스템 리소스 관련 Limit 설정

• sudo systemctl show jenkins | grep ^Limit : 리소스별 설정된 Limit 값 목록 조회

 

• LimitAS
  • 서비스에서 사용할 수 있는 최대 가상 메모리 공간
  • infinity : 서비스가 필요한 만큼의 가상 메모리를 사용할 수 있도록 제한하지 않음
• LimitRSS
  • 서비스에서 사용할 수 있는 최대 물리 메모리 공간
  • infinity : 서비스가 필요한 만큼의 RAM을 사용할 수 있도록 제한하지 않음
• LimitCORE
  • 충돌 발생 시 서비스에서 생성할 수 있는 코어 덤프 파일의 최대 크기
  • infinity : 코어 덤프 파일 크기 제한하지 않음
• LimitNOFILE
  • 서비스가 동시에 가질 수 있는 열린 파일(파일 디스크립터)의 최대 개수
  • 1048576 : 최대 1048576개의 열린 파일을 동시에 가질 수 있음

 

최대 오픈 파일 수 설정

• 사용자 계정에 대한 리소스 제한을 설정하는 시스템 구성 파일
• 개별 사용자나 프로세스가 시스템 자원을 독점하는 것을 방지하고, 자원 할당을 보장하기 위해 사용

/etc/security/limits.conf

 

• <domain> : 제한이 적용되는 범위를 지정
  • @그룹명
  • 사용자명
  • * : 모든 사용자
• <type> : 제한의 유형 지정
  • soft : 일시적으로 초과할 수 있는 제한 값
  • hard : 초과할 수 없는 최대 값
• <item> : 제한되는 자원 지정
  • core : 코어 파일의 최대 크기
  • data : 최대 데이터 크기
  • fsize : 최대 파일 크기
  • memlock : 최대 잠긴 메모리 주소 공간(물리적 RAM에 잠긴 상태로 유지하는 메모리 양, 디스크로 스왑되지 않고 빠른 액세스가 필요할 때)
  • nofile : 최대 개방 파일 수
  • rss : 최대 레지던트 세트 크기(프로세스가 실제 RAM에 보유하고 있는 메모리의 일부)
  • stack : 최대 스택 크기
  • cpu : 최대 CPU 시간
  • nproc : 최대 프로세스 수
  • as : 주소 공간 제한
  • maxlogins : 해당 유저의 최대 로그인 수
  • priority : 유저 우선순위
  • locks : 유저가 가지고 있을 수 있는 최대 파일 개수
  •  
• <value> : 지정된 자원의 제한 값 정의
• 설정 내용 적용하는 방법 2가지
  • 1. 재부팅하기
    2. ulimit -a 로 리소스 재로드하기

ulimit -a