GitLab Runner의 시스템 서비스
GitLab Runner은 하부 OS를 감지하고 결국 init 시스템에 기반하여 서비스 파일을 설치하는 데에 Go ‘service’ 라이브러리를 사용합니다.
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와 똑같이 동작합니다.