GitLab Runner의 시스템 서비스

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed

GitLab Runner은 하부 OS를 감지하고 결국 init 시스템에 기반하여 서비스 파일을 설치하는 데에 Go ‘service’ 라이브러리를 사용합니다.

note
‘service’는 프로그램을 서비스(데몬)로 설치, 제거, 시작, 중지 및 실행합니다. Windows XP+, Linux/(systemd | Upstart | SysV), 그리고 macOS/Launchd를 지원합니다.

GitLab Runner가 설치되면 서비스 파일이 자동으로 생성됩니다:

  • systemd: /etc/systemd/system/gitlab-runner.service
  • upstart: /etc/init/gitlab-runner

사용자 정의 환경 변수 설정

사용자 정의 환경 변수로 GitLab Runner를 실행하고 싶을 수 있습니다. 예를 들어, runner의 환경에서 GOOGLE_APPLICATION_CREDENTIALS를 정의하고 싶을 수 있습니다. 이는 모든 runner가 실행하는 모든 작업에 자동으로 추가되는 변수를 정의하는 environment 설정과는 다릅니다.

systemd 사용자 정의

systemd를 사용하는 runner의 경우, 각 변수를 내보낼 때 /etc/systemd/system/gitlab-runner.service.d/env.conf를 생성하고 Environment=key=value 라인을 사용하세요. 예를 들어:

[Service]
Environment=GOOGLE_APPLICATION_CREDENTIALS=/etc/gitlab-runner/gce-credentials.json

그런 다음 구성을 다시로드합니다:

systemctl daemon-reload
systemctl restart gitlab-runner.service

upstart 사용자 정의

upstart를 사용하는 runner의 경우, /etc/init/gitlab-runner.override를 생성하고 원하는 변수를 내보냅니다. 예를 들어:

export GOOGLE_APPLICATION_CREDENTIALS="/etc/gitlab-runner/gce-credentials.json"

이를 적용하려면 runner를 다시 시작하십시오.

기본 중지 동작 재정의

일부 경우에는 서비스의 기본 동작을 재정의하고 싶을 수 있습니다.

예를 들어, GitLab Runner를 업그레이드할 때 모든 진행 중인 작업이 완료될 때까지 우아하게 중지하려 할 수 있습니다. 그러나 systemd, upstart 또는 다른 서비스는 프로세스를 거의 즉시 다시 시작할 수 있습니다.

따라서 GitLab Runner를 업그레이드할 때 설치 스크립트는 아마도 새로운 작업을 처리하던 runner 프로세스를 중지하고 다시 시작합니다.

systemd 재정의

systemd를 사용하는 runner의 경우, 다음 내용으로 /etc/systemd/system/gitlab-runner.service.d/kill.conf를 작성하십시오:

[Service]
TimeoutStopSec=7200
KillSignal=SIGQUIT

systemd 유닛 구성에 이 두 설정을 추가한 후, runner를 중지하고 systemd는 프로세스를 중지하기 위해 SIGQUIT를 사용합니다. 추가로 중지 명령에 2시간 타임아웃이 설정되어 있으며, 이는 이 시간 제한을 초과하여 우아하게 종료되지 않는 경우 systemd가 SIGKILL을 사용하여 프로세스를 종료합니다.

upstart 재정의

upstart를 사용하는 runner의 경우, 다음 내용으로 /etc/init/gitlab-runner.override를 작성하십시오:

kill signal SIGQUIT
kill timeout 7200

이 두 설정을 추가한 후 runner를 중지하면 upstart는 기본적으로 systemd와 똑같이 동작합니다.