- 환경 변수 사용
- 디버그 모드 실행
- 슈퍼 유저 권한
- 구성 파일
- 시그널
- 명령 개요
- 등록 관련 명령어
- 서비스 관련 명령어
- 실행 관련 명령어
- 내부 명령어
- 문제 해결
-
gitlab-runner stop이 정상적으로 종료되지 않음
GitLab Runner 명령어
GitLab Runner에는 빌드를 등록, 관리 및 실행하는 데 사용하는 명령어 세트가 포함되어 있습니다.
아래 명령을 실행하여 명령어 목록을 확인할 수 있습니다:
gitlab-runner --help
특정 명령에 --help를 추가하여 해당 명령의 도움말 페이지를 볼 수 있습니다:
gitlab-runner <command> --help
환경 변수 사용
대부분의 명령은 환경 변수를 구성을 전달하는 데 사용하는 방법으로 지원합니다.
특정 명령에 대해 --help를 호출할 때 환경 변수 이름을 볼 수 있습니다. 예를 들어, run 명령에 대한 도움말 메시지는 다음과 같습니다:
gitlab-runner run --help
출력은 다음과 유사합니다:
NAME:
gitlab-runner run - run multi runner service
USAGE:
gitlab-runner run [command options] [arguments...]
OPTIONS:
-c, --config "/Users/ayufan/.gitlab-runner/config.toml" Config file [$CONFIG_FILE]
디버그 모드 실행
디버그 모드는 정의되지 않은 동작이나 오류 원인을 찾을 때 특히 유용합니다.
명령을 디버그 모드로 실행하려면 명령 앞에 --debug를 추가하십시오:
gitlab-runner --debug <command>
슈퍼 유저 권한
GitLab Runner 구성에 액세스하는 명령은 슈퍼 유저(root)로 실행될 때 다르게 작동합니다. 파일 위치는 명령을 실행하는 사용자에 따라 다릅니다.
gitlab-runner 명령을 실행하면 실행 모드를 볼 수 있습니다:
$ gitlab-runner run
INFO[0000] Starting multi-runner from /Users/ayufan/.gitlab-runner/config.toml ... builds=0
WARN[0000] Running in user-mode.
WARN[0000] Use sudo for system-mode:
WARN[0000] $ sudo gitlab-runner...
확실히 이 모드를 사용하려면 user-mode를 사용해야 합니다. 그렇지 않으면 명령 앞에 sudo를 추가하십시오:
$ sudo gitlab-runner run
INFO[0000] Starting multi-runner from /etc/gitlab-runner/config.toml ... builds=0
INFO[0000] Running in system-mode.
Windows의 경우 관리자로 명령 프롬프트를 실행해야 할 수 있습니다.
구성 파일
GitLab Runner 구성은 TOML 형식을 사용합니다.
편집해야 하는 파일은 아래에서 찾을 수 있습니다:
- GitLab Runner가 슈퍼 유저(
root)로 실행되는 *nix 시스템의 경우:/etc/gitlab-runner/config.toml - GitLab Runner가 root가 아닌 사용자로 실행되는 *nix 시스템의 경우:
~/.gitlab-runner/config.toml - 다른 시스템의 경우:
./config.toml
대부분의 명령은 사용자 컴퓨터에서 여러 다른 구성을 가질 수 있도록 사용자 정의 구성 파일을 지정하기 위한 인수를 허용합니다. 사용자 정의 구성 파일을 지정하려면 -c 또는 --config 플래그를 사용하거나 CONFIG_FILE 환경 변수를 사용하십시오.
시그널
시스템 시그널을 사용하여 GitLab Runner와 상호 작용할 수 있습니다. 다음 명령은 다음 시그널을 지원합니다:
| 명령 | 시그널 | 동작 |
|---|---|---|
register
| SIGINT | 등록을 취소하고 이미 등록된 경우 삭제합니다. |
run, exec, run-single
| SIGINT, SIGTERM | 실행 중인 모든 빌드를 중단하고 가능한 한 빨리 종료합니다(강제 종료). |
run, exec, run-single
| SIGQUIT | 새로운 빌드의 수락을 중지합니다. 현재 실행 중인 빌드가 완료될 때까지 종료합니다(점진적 종료). |
run
| SIGHUP | 구성 파일을 다시로드합니다. |
예를 들어, 러너의 구성 파일을 강제로 다시로드하려면 다음과 같이 실행하십시오:
sudo kill -SIGHUP <main_runner_pid>
sudo kill -SIGQUIT <main_runner_pid>
경고:
shell 또는 docker executor를 사용하는 경우 killall 또는 pkill을 사용하여 정상적인 종료에 사용하지 마십시오. 이는 하위 프로세스도 종료되어 시그널 처리를 적절하게 처리하지 못할 수 있습니다. 작업을 처리하는 주 프로세스에만 사용하십시오.
운영 체제가 위의 시그널에 의해 셧다운된 경우 서비스를 자동으로 다시 시작하도록 구성된 경우 (일부 플랫폼의 기본 설정) 위의 시그널로 인해 종료된 경우 자동으로 러너가 다시 시작될 수 있습니다.
명령 개요
gitlab-runner를 인수없이 실행하면 다음 내용이 나타납니다:
NAME:
gitlab-runner - a GitLab Runner
USAGE:
gitlab-runner [global options] command [command options] [arguments...]
VERSION:
16.5.0 (853330f9)
AUTHOR:
GitLab Inc. <support@gitlab.com>
COMMANDS:
exec 빌드를 로컬에서 실행합니다
list 구성된 모든 러너를 나열합니다
run 멀티 러너 서비스를 실행합니다
register 새 러너를 등록합니다
reset-token 러너의 토큰을 재설정합니다
install 서비스를 설치합니다
uninstall 서비스를 제거합니다
start 서비스를 시작합니다
stop 서비스를 중지합니다
restart 서비스를 다시 시작합니다
status 서비스의 상태를 가져옵니다
run-single 단일 러너를 시작합니다
unregister 특정 러너의 등록을 취소합니다
verify 등록된 모든 러너를 확인합니다
artifacts-downloader 빌드 아티팩트를 다운로드하고 추출합니다 (내부용)
artifacts-uploader 빌드 아티팩트를 생성 및 업로드합니다 (내부용)
cache-archiver 캐시 아티팩트를 생성 및 업로드합니다 (내부용)
cache-extractor 캐시 아티팩트를 다운로드하고 추출합니다 (내부용)
cache-init 캐시 경로의 권한을 변경합니다 (내부용)
health-check 특정 주소에 대한 상태를 확인합니다
read-logs 파일에서 작업 로그를 읽습니다. 쿠버네티스 executor에서 사용됩니다 (내부용)
help, h 명령 목록 또는 특정 명령에 대한 도움말을 표시합니다
GLOBAL OPTIONS:
--cpuprofile value CPU 프로파일을 파일에 작성합니다 [$CPU_PROFILE]
--debug 디버그 모드 [$RUNNER_DEBUG]
--log-format value 로그 형식 선택(옵션: runner, text, json) [$LOG_FORMAT]
--log-level value, -l value 로그 레벨(옵션: debug, info, warn, error, fatal, panic) [$LOG_LEVEL]
--help, -h 도움말 표시
--version, -v 버전 표시
등록 관련 명령어
새 러너를 등록하거나 등록되어 있는지를 나열 및 확인하려면 다음 명령어를 사용하십시오.
이러한 명령어는 다음과 같은 인수를 지원합니다:
| 매개변수 | 기본값 | 설명 |
|---|---|---|
--config
| 구성 파일 섹션에서 확인 | 사용할 사용자 정의 구성 파일 지정 |
gitlab-runner register
이 명령은 GitLab Runners API를 사용하여 GitLab에 러너를 등록합니다.
등록된 러너는 구성 파일에 추가됩니다.
하나의 GitLab Runner 설치에서 여러 구성을 사용할 수 있습니다. gitlab-runner register를 실행하면 새로운 구성 항목이 추가됩니다. 기존 항목은 제거되지 않습니다.
러너를 등록하는 두 가지 옵션이 있습니다:
- 대화형.
- 비대화형.
대화형 등록
이 명령은 보통 대화형 모드(기본)에서 사용됩니다. 러너 등록 중에 여러 질문을 받습니다.
이 질문은 등록 명령어를 호출할 때 인수를 추가하여 미리 채워놓을 수 있습니다:
gitlab-runner register --name my-runner --url "http://gitlab.example.com" --registration-token my-registration-token
또는 register 명령어 전에 환경 변수를 구성하여 미리 채워놓을 수 있습니다:
export CI_SERVER_URL=http://gitlab.example.com
export RUNNER_NAME=my-runner
export REGISTRATION_TOKEN=my-registration-token
gitlab-runner register
모든 가능한 인수와 환경을 확인하려면 다음을 실행하세요:
gitlab-runner register --help
비대화형 등록
비대화형 / 직접 모드로 등록하는 것도 가능합니다.
등록 명령어를 호출할 때 인수를 지정할 수 있습니다:
gitlab-runner register --non-interactive <other-arguments>
또는 register 명령어 전에 환경 변수를 구성하여 미리 채워놓을 수 있습니다:
<other-environment-variables>
export REGISTER_NON_INTERACTIVE=true
gitlab-runner register
--key={true|false}의 형태로 전달해야 합니다.
[[runners]] 구성 템플릿 파일
구성 템플릿 파일 기능을 사용하여 러너 등록 중에 추가 옵션을 쉽게 구성할 수 있습니다.
gitlab-runner list
이 명령은 구성 파일에 저장된 모든 러너를 나열합니다.
gitlab-runner verify
이 명령은 등록된 러너가 GitLab에 연결하는지 확인하지만, 러너가 GitLab Runner 서비스에서 사용 중인지는 확인하지 않습니다. 예시 출력은 다음과 같습니다:
Verifying runner... is alive runner=fee9938e
Verifying runner... is alive runner=0db52b31
Verifying runner... is alive runner=826f687f
Verifying runner... is alive runner=32773c0f
GitLab에서 제거된 이전 러너를 제거하려면 다음 명령을 실행하세요.
config.toml의 백업을 확인하세요.gitlab-runner verify --delete
gitlab-runner unregister
이 명령은 GitLab Runners API를 사용하여 등록된 러너를 등록 해제합니다.
다음 중 하나가 필요합니다:
- 완전한 URL 및 러너 토큰.
- 러너 이름.
--all-runners 옵션을 사용하면 모든 연결된 러너를 등록 해제합니다.
- 러너가 러너 등록 토큰으로 생성된 경우,
gitlab-runner unregister는 러너를 삭제합니다. - 러너가 GitLab UI나 Runners API를 사용하여 생성된 경우,
gitlab-runner unregister는 러너 관리자를 삭제하지만 러너를 삭제하지 않습니다. 러너를 완전히 삭제하려면 러너 관리 페이지에서 러너 삭제를 하거나DELETE /runnersREST API 엔드포인트를 사용하세요.
단일 러너를 등록 해제하려면 먼저 gitlab-runner list를 실행하여 러너의 세부 정보를 가져옵니다:
test-runner Executor=shell Token=t0k3n URL=http://gitlab.example.com
그런 다음 이 정보를 사용하여 하기 명령 중 하나를 사용하여 등록 해제합니다.
config.toml의 백업을 확인하세요.URL 및 토큰으로
gitlab-runner unregister --url "http://gitlab.example.com/" --token t0k3n
이름으로
gitlab-runner unregister --name test-runner
참고: 주어진 이름과 일치하는 러너가 여러 개인 경우, 첫 번째 러너만 제거됩니다.
모든 러너
gitlab-runner unregister --all-runners
gitlab-runner reset-token
이 명령은 러너 ID 또는 현재 토큰을 사용하여 GitLab Runners API를 통해 러너의 토큰을 재설정합니다.
이 명령은 러너의 이름(또는 URL 및 ID)과 선택적으로 PAT를 기대합니다. 토큰이 이미 만료된 경우, PAT 및 러너 ID를 사용할 것을 권장합니다.
--all-runners 옵션을 사용하면 모든 연결된 러너의 토큰이 재설정됩니다.
러너의 현재 토큰으로
gitlab-runner reset-token --name test-runner
PAT 및 러너 이름으로
gitlab-runner reset-token --name test-runner --pat PaT
PAT, GitLab URL 및 러너 ID로
gitlab-runner reset-token --url "https://gitlab.example.com/" --id 12345 --pat PaT
모든 러너
gitlab-runners reset-token --all-runners
서비스 관련 명령어
다음 명령어들은 러너를 시스템 또는 사용자 서비스로 관리할 수 있습니다. 이들을 사용하여 러너 서비스를 설치, 제거, 시작 및 중지할 수 있습니다.
gitlab-runner installgitlab-runner uninstallgitlab-runner startgitlab-runner stopgitlab-runner restartgitlab-runner status- 다중 서비스
- 서비스 관련 명령 실행 시 ‘액세스 거부’ 오류 발생 시
모든 서비스 관련 명령은 다음과 같은 인수를 허용합니다:
| 매개변수 | 기본값 | 설명 |
|---|---|---|
--service
| gitlab-runner
| 사용자 정의 서비스 이름 지정 |
--config
| 구성 파일에서 확인하십시오 | 사용할 사용자 정의 구성 파일 지정 |
gitlab-runner install
이 명령은 GitLab Runner를 서비스로 설치합니다. 실행되는 시스템에 따라 다른 세트의 인수를 허용합니다.
Windows 또는 super-user에서 실행 시 –user 플래그를 허용합니다. 이를 통해 shell executor로 실행된 빌드의 권한을 변경할 수 있습니다.
| 매개변수 | 기본값 | 설명 |
|---|---|---|
--service
| gitlab-runner
| 사용할 서비스 이름 지정 |
--config
| 구성 파일에서 확인하십시오 | 사용할 사용자 정의 구성 파일 지정 |
--syslog
| 시스템 로깅 서비스와 통합되어야 하는지 여부 | 서비스가 시스템 로깅 서비스와 통합되어야 하는지 여부 지정 |
--working-directory
| 현재 디렉토리 | shell executor로 빌드가 실행될 때 모든 데이터가 저장되는 루트 디렉토리 지정 |
--user
| root
| 빌드를 실행하는 사용자 지정 |
--password
| 없음 | 빌드를 실행하는 사용자의 비밀번호 지정 |
gitlab-runner uninstall
이 명령은 GitLab Runner를 서비스로 실행하는 것을 중지하고 제거합니다.
gitlab-runner start
이 몹령은 GitLab Runner 서비스를 시작합니다.
gitlab-runner stop
이 몹령은 GitLab Runner 서비스를 중지합니다.
gitlab-runner restart
이 몹령은 GitLab Runner 서비스를 중지한 다음 시작합니다.
gitlab-runner status
이 몹령은 GitLab Runner 서비스의 상태를 출력합니다. 서비스가 실행 중이면 종료 코드는 0이고, 실행 중이 아니면 0이 아닙니다.
다중 서비스
--service 플래그를 지정하여 여러 개의 GitLab Runner 서비스를 별도로 구성 가능합니다.
실행 관련 명령어
이 명령은 GitLab에서 빌드를 가져와 처리할 수 있게 합니다.
gitlab-runner run
이 명령은 GitLab Runner가 서비스로 시작될 때 실행되는 주요 명령입니다.
config.toml에서 정의된 모든 러너를 읽고 모두 실행을 시도합니다.
명령에는 다음과 같은 매개변수가 허용됩니다.
| 매개변수 | 기본값 | 설명 |
|---|---|---|
--config
| 구성 파일에서 확인하십시오 | 사용할 사용자 정의 구성 파일 지정 |
--working-directory
| 현재 디렉토리 | shell executor로 빌드가 실행될 때 모든 데이터가 저장되는 루트 디렉토리 지정 |
--user
| 현재 사용자 | 빌드를 실행하는 사용자 지정 |
--syslog
| false
| 모든 로그를 SysLog(UNIX) 또는 이벤트 로그(Windows)로 보냅니다 |
--listen-address
| 빈값 | 프로메테우스 메트릭 HTTP 서버가 수신해야 하는 주소(<호스트>:<포트>)를 지정합니다
|
gitlab-runner run-single
이 명령은 단일 GitLab 인스턴스에서 한 번에 하나의 빌드만 실행하는 데 사용할 수 있는 보충 명령입니다. 구성 파일을 사용하지 않고 모든 옵션을 매개변수나 환경 변수로 전달해야 합니다. GitLab URL 및 Runner 토큰도 지정해야 합니다.
예시:
gitlab-runner run-single -u http://gitlab.example.com -t my-runner-token --executor docker --docker-image ruby:2.7
--help 플래그를 사용하여 모든 가능한 구성 옵션을 볼 수 있습니다.
gitlab-runner run-single --help
--max-builds 옵션을 사용하여 러너가 종료되기 전에 실행하는 빌드 수를 제어할 수 있습니다. 0의 기본값은 러너에 빌드 제한이 없고 작업이 영원히 실행된다는 것을 의미합니다.
--wait-timeout 옵션을 사용하여 작업이 종료되기 전에 러너가 대기하는 시간을 제어할 수 있습니다. 0의 기본값은 러너에 제한 시간이 없고 작업 간에 영원히 대기한다는 것을 의미합니다.
gitlab-runner exec (deprecated)
경고: 이 기능은 GitLab 15.7에서 폐기되었으며 17.0에서 제거될 예정입니다. 파이프라인 구문 및 유효성 검사 시뮬레이션은 GitLab 파이프라인 편집기에서 사용할 수 있습니다. 이 변경 사항은 호환성이 없는 변경 사항입니다.
참고:
모든 .gitlab-ci.yml의 기능이 exec에서 지원되는 것은 아닙니다. limitations of gitlab-runner exec 섹션에서 정확히 무엇이 지원되는지 확인하십시오.
이 명령을 사용하여 가능한 한 CI 환경을 모방하려고 하면서 로컬로 빌드를 실행하여 GitLab에 연결할 필요가 없습니다. 대신, 로컬 .gitlab-ci.yml을 읽고 모든 빌드 단계가 실행되는 새로운 빌드 환경을 생성합니다.
이 명령은 모든 것이 로컬에서 실행되기 때문에 .gitlab-ci.yml을 빠르게 확인하고 확인하는 데 유용하며 모든 것이 로컬에서 실행되기 때문에 손상된 빌드를 디버깅하는 데도 유용합니다.
exec를 실행할 때는 .gitlab-ci.yml에 있는 실행자와 작업 이름을 지정해야 합니다. 명령은 .gitlab-ci.yml을 포함하는 Git 저장소의 루트 디렉터리에서 실행해야 합니다.
gitlab-runner exec는 로컬 Git 저장소의 현재 상태를 복제합니다. 테스트하려는 변경 사항을 미리 커밋해 놓은지 확인하십시오.
예를 들어, 다음 명령은 셸 실행자를 사용하여 로컬에서 tests라는 작업을 실행합니다:
gitlab-runner exec shell tests
사용 가능한 실행자 목록을 보려면 다음을 실행하세요:
gitlab-runner exec
shell 실행자의 모든 가능한 옵션 목록을 보려면 다음을 실행하세요:
gitlab-runner exec shell
exec 명령을 사용하여 docker 실행자를 사용하려면 docker-machine shell 또는 boot2docker shell 환경에서 실행해야 합니다. 이는 로컬 디렉터리를 Docker 컨테이너 내부의 디렉터리에 정확하게 매핑하도록 해야 하기 때문입니다.
기타 옵션도 사용할 수 있습니다:
-
모든 가능한 구성 옵션을 보려면
--help를 사용합니다:gitlab-runner exec --help - 프로젝트가 기본
.gitlab-ci.yml을 사용하지 않는 경우 CI/CD 구성 파일의 경로를 지정하려면--cicd-config-file을 사용합니다. - 작업 실행 제한 시간(초)을 설정하려면
--timeout을 사용합니다.1800을 기본값으로 사용하여 실행이 30분 후에 타임아웃됩니다.
gitlab-runner exec의 제한 사항
현재 exec의 구현에 따라 GitLab CI/CD의 일부 기능이 작동하지 않을 수 있거나 일부 기능만 작동할 수 있습니다.
현재 exec 구현을 대체하여 모든 기능과 완전히 호환되도록 만드는 방법에 대해 고민 중입니다. 자세한 내용은 이 이슈를 추적하십시오.
호환성 테이블 - .gitlab-ci.yml 기반의 기능
다음 기능들이 지원됩니다. 특정 기능이 이 테이블에 나열되어 있지 않으면 지원되지 않습니다.
| GitLab CI 기능 |
exec에서 사용 가능
| 설명 |
|---|---|---|
image
| yes | 확장된 구성(name, entrypoint)도 지원됩니다.
|
services
| yes | 확장된 구성(name, alias, entrypoint, command)도 지원됩니다.
|
before_script
| yes | 전역 및 작업 수준 before_script을 지원합니다.
|
after_script
| 부분적으로 | 전역 after_script은 지원되지 않습니다. 작업 수준 after_script만 지원됩니다. 명령만 고려되며, when은 항상으로 하드코딩되어 있습니다.
|
variables
| yes | 기본 (일부 지원), 전역 및 작업 수준 변수를 지원합니다. 기본 변수는 코드에서 볼 수 있습니다. |
cache
| 부분적으로 | 특정 구성에 따라 기대한대로 작동할 수도 있고 아닐 수도 있습니다. |
| YAML 기능들 | yes | 앵커(&), 별칭(*), 맵 병합(<<)은 YAML 사양의 일부이며 구문 분석기에서 처리됩니다.
|
pages
| 부분적으로 | 명시적으로 요청하면 작업 스크립트가 실행되지만 GitLab이 관리하는 페이지 상태에 영향을 주지 않습니다. |
호환성 테이블 - 변수 기반의 기능
| GitLab CI 기능 |
exec에서 사용 가능
| 설명 |
|---|---|---|
GIT_STRATEGY
| yes | |
GIT_CHECKOUT
| yes | |
GIT_SUBMODULE_STRATEGY
| yes | |
GIT_SUBMODULE_PATHS
| yes | |
GIT_SUBMODULE_UPDATE_FLAGS
| yes | |
GIT_SUBMODULE_DEPTH
| yes | |
GIT_SUBMODULE_FORCE_HTTPS
| yes | |
GET_SOURCES_ATTEMPTS
| yes | |
ARTIFACT_DOWNLOAD_ATTEMPTS
| no | 아티팩트는 지원되지 않습니다. |
RESTORE_CACHE_ATTEMPTS
| yes |
호환성 테이블 - 기타 기능
| GitLab CI 기능 |
exec에서 사용 가능
| 설명 |
|---|---|---|
| 비밀 변수 | no | |
| 트리거 | no | |
| 스케줄 | no | |
| 작업 시간 초과 | no | 1시간으로 하드코딩됨. |
[ci skip]
| no |
기타 요구 사항 및 제한 사항
로컬에 Docker가 설치된 경우에만 gitlab-runner exec docker를 사용할 수 있습니다. 이것은 GitLab Runner가 호스트 바인드 볼륨을 사용하여 Git 소스에 액세스하기 때문에 필요합니다.
내부 명령어
GitLab Runner는 단일 이진 파일로 배포되며 빌드 중에 사용되는 몇 가지 내부 명령어를 포함하고 있습니다.
gitlab-runner artifacts-downloader
GitLab에서 아티팩트 아카이브를 다운로드합니다.
gitlab-runner artifacts-uploader
아티팩트 아카이브를 GitLab에 업로드합니다.
gitlab-runner cache-archiver
캐시 아카이브를 생성하고, 로컬에 저장하거나 외부 서버에 업로드합니다.
gitlab-runner cache-extractor
로컬 또는 외부에 저장된 파일에서 캐시 아카이브를 복원합니다.
문제 해결
아래는 몇 가지 일반적인 문제점입니다.
서비스 관련 명령을 실행할 때 Access Denied 오류 발생
일반적으로 서비스 관련 명령어는 관리자 권한이 필요합니다:
- Unix(Linux, macOS, FreeBSD) 시스템에서는
gitlab-runner앞에sudo를 붙입니다. - Windows 시스템에서는 상위 명령 프롬프트를 사용합니다.
관리자명령 프롬프트를 실행합니다. 가장 간단한 방법은 Windows 검색란에명령 프롬프트를 작성하고 마우스 오른쪽 버튼을 클릭하여관리자로 실행을 선택합니다. 실행 여부를 확인받게 됩니다.
/usr/lib/gitlab-runner: No such file or directory
gitlab-runner 실행 파일이 GitLab 13.3에서 /usr/lib/에서 /usr/bin/으로 이동되었습니다.
역호환성을 위해 /usr/lib/gitlab-runner를 /usr/bin/gitlab-runner로 가리키는 심볼릭 링크가 추가되었습니다. GitLab 14.0에서 심볼릭 링크가 제거되었습니다.
/usr/lib/gitlab-runner: No such file or directory 오류를 해결하려면 다음 중 하나를 수행해야 합니다:
- 직접
gitlab-runner를 호출합니다($PATH에/usr/bin이 있는 경우). -
/usr/bin/gitlab-runner를 호출합니다.
gitlab-runner stop이 정상적으로 종료되지 않음
호스트에 설치된 runner가 로컬 executor로 작동할 때 일부 작업(예: 아티팩트 다운로드 또는 업로드, 캐시 처리)에 대해 추가적인 프로세스를 시작합니다. 이러한 프로세스는 gitlab-runner 명령으로 실행되므로, 이러한 프로세스를 종료하려면 pkill -QUIT gitlab-runner 또는 killall QUIT gitlab-runner를 사용할 수 있습니다. 해당 프로세스를 종료하면 그들이 책임지는 작업도 실패합니다.
이를 방지하기 위한 두 가지 방법이 있습니다:
-
SIGQUIT을 종료 신호로 사용하여 runner를 로컬 서비스(예:systemd)로 등록하고gitlab-runner stop또는systemctl stop gitlab-runner.service를 사용합니다. 다음은 이 작업을 가능하게 하는 예시 구성입니다:; /etc/systemd/system/gitlab-runner.service.d/kill.conf [Service] KillSignal=SIGQUIT TimeoutStopSec=infinity- 이 구성 변경을 적용하려면 이 파일을 만든 후
systemctl daemon-reload로systemd를 다시로드합니다.
- 이 구성 변경을 적용하려면 이 파일을 만든 후
-
kill -SIGQUIT <pid>명령으로 프로세스를 수동으로 종료합니다. 주요gitlab-runner프로세스의pid를 찾아야 합니다. 이는 시작 시 로그를 확인하여 찾을 수 있습니다:$ gitlab-runner run Runtime platform arch=arm64 os=linux pid=8 revision=853330f9 version=16.5.0
시스템 ID 상태 파일 저장: 액세스 거부
GitLab Runner 15.7 및 15.8은 config.toml 파일을 포함하는 디렉터리에 대한 쓰기 권한이 없으면 시작하지 않을 수 있습니다.
GitLab Runner가 시작될 때 config.toml을 포함하는 디렉터리에서 .runner_system_id 파일을 검색합니다. .runner_system_id 파일을 찾을 수 없으면 새 파일을 생성합니다. 만약 GitLab Runner가 쓰기 권한이 없으면 시작에 실패합니다.
이 문제를 해결하려면 일시적으로 파일 쓰기 권한을 허용한 후 gitlab-runner run을 실행합니다. .runner_system_id 파일이 생성된 후 권한을 읽기 전용으로 재설정할 수 있습니다.
도움말