GitLab Runner 명령어

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

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 형식을 사용합니다.

편집할 파일은 다음 위치에 있습니다:

  1. root(슈퍼 유저)로 실행될 때 *nix 시스템: /etc/gitlab-runner/config.toml
  2. root(슈퍼 유저)로 실행되지 않을 때 *nix 시스템: ~/.gitlab-runner/config.toml
  3. 다른 시스템: ./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>
caution
만약 shell 또는 docker 실행자를 사용 중이라면 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                  execute a build locally
   list                  List all configured runners
   run                   run multi runner service
   register              register a new runner
   reset-token           reset a runner's token
   install               install service
   uninstall             uninstall service
   start                 start service
   stop                  stop service
   restart               restart service
   status                get status of a service
   run-single            start single runner
   unregister            unregister specific runner
   verify                verify all registered runners
   artifacts-downloader  download and extract build artifacts (internal)
   artifacts-uploader    create and upload build artifacts (internal)
   cache-archiver        create and upload cache artifacts (internal)
   cache-extractor       download and extract cache artifacts (internal)
   cache-init            changed permissions for cache paths (internal)
   health-check          check health for a specific address
   read-logs             reads job logs from a file, used by kubernetes executor (internal)
   help, h               Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --cpuprofile value           write cpu profile to file [$CPU_PROFILE]
   --debug                      debug mode [$RUNNER_DEBUG]
   --log-format value           Choose log format (options: runner, text, json) [$LOG_FORMAT]
   --log-level value, -l value  Log level (options: debug, info, warn, error, fatal, panic) [$LOG_LEVEL]
   --help, -h                   show help
   --version, -v                print the version

아래에서 각 명령이 하는 일에 대해 자세히 설명합니다.

등록 관련 명령어

새 러너를 등록하거나, 등록된 러너 디렉터리을 확인하고 확인하는 다음 명령어를 사용합니다.

이러한 명령어는 다음 인자를 지원합니다:

매개변수 기본값 설명
--config 구성 파일 섹션 참조 사용할 사용자 정의 구성 파일 지정

gitlab-runner register

이 몤령은 GitLab Runners API를 사용하여 GitLab에 러너를 등록합니다.

등록된 러너는 구성 파일에 추가됩니다. GitLab Runner의 단일 설치에서 여러 구성을 사용할 수 있습니다. gitlab-runner register를 실행하면 새 구성 항목이 추가됩니다. 기존 구성 항목은 제거되지 않습니다.

러너를 등록하는 두 가지 옵션이 있습니다:

  • 대화형
  • 비대화형
note
러너는 GitLab Runners API를 직접 사용하여 등록할 수 있지만 구성은 자동으로 생성되지 않습니다.

대화형 등록

이 명령은 일반적으로 대화형 모드(기본값)에서 사용됩니다. 러너 등록 중에 여러 질문을 받게 됩니다.

이 질문은 등록 명령을 호출할 때 인수를 추가하여 사전에 채울 수 있습니다: 

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
note
부욜형 매개변수는 명령줄에서 --key={true|false}와 함께 전달해야 합니다.

[[runners]] 구성 템플릿 파일

구성 템플릿 파일 기능을 사용하여 러너 등록 중에 추가 옵션을 쉽게 구성할 수 있습니다.

gitlab-runner list

이 명령은 구성 파일에 저장된 모든 러너를 나열합니다.

gitlab-runner verify

이 명령은 등록된 러너가 GitLab에 연결할 수 있는지 확인하지만, 러너가 GitLab Runner 서비스에서 사용 중인지는 확인하지 않습니다. 예시 출력은 다음과 같습니다: 

러너 확인... 동작 중                        runner=fee9938e
러너 확인... 동작 중                        runner=0db52b31
러너 확인... 동작 중                        runner=826f687f
러너 확인... 동작 중                        runner=32773c0f

GitLab에서 제거된 이전 러너를 제거하려면 다음 명령을 실행하세요.

caution
이 작업은 되돌릴 수 없습니다. 구성 파일을 업데이트하므로 실행하기 전에 config.toml의 백업을 확인하세요.
gitlab-runner verify --delete

gitlab-runner unregister

이 명령은 GitLab Runners API를 사용하여 등록된 러너를 등록 해제합니다.

다음 중 하나를 예상합니다:

  • 전체 URL 및 러너 토큰.
  • 러너 이름.

--all-runners 옵션을 사용하면 모든 연결된 러너를 등록 해제합니다.

note
러너는 GitLab Runners API를 사용하여 등록 해제할 수 있지만 사용자의 구성은 수정되지 않습니다.
  • 러너가 러너 등록 토큰으로 생성된 경우, gitlab-runner unregister와 함께 러너 인증 토큰이 러너를 삭제합니다.
  • 러너가 GitLab UI에서 생성되었거나 Runners API를 사용하여 생성된 경우, gitlab-runner unregister와 함께 러너 인증 토큰이 러너 관리자를 삭제하지만 러너 자체는 삭제하지 않습니다. 러너를 완전히 제거하려면 공유 러너 삭제를 실행하거나 DELETE /runners REST API 엔드포인트를 사용하세요.

단일 러너를 등록 해제하려면 먼저 gitlab-runner list를 실행하여 러너의 세부 정보를 가져옵니다: 

test-runner     Executor=shell Token=t0k3n URL=http://gitlab.example.com

그런 다음 다음 명령 중 하나를 사용하여 이 정보를 사용하여 러너를 등록 해제할 수 있습니다.

caution
이 작업은 되돌릴 수 없습니다. 구성 파일을 업데이트하므로 실행하기 전에 config.toml의 백업을 확인하세요.

URL과 토큰으로 

gitlab-runner unregister --url "http://gitlab.example.com/" --token t0k3n

이름별 

gitlab-runner unregister --name test-runner
note
주어진 이름으로 여러 러너가 있는 경우 첫 번째 러너만 삭제됩니다.

모든 러너 

gitlab-runner unregister --all-runners

gitlab-runner reset-token

이 명령은 GitLab Runners API를 사용하여 러너 토큰을 재설정합니다. 러너 ID 또는 현재 토큰](https://docs.gitlab.com/ee/api/runners.html#reset-runners-authentication-token-by-using-the-current-token)을 사용하여 실행됩니다.

러너의 이름(또는 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

서비스 관련 명령어

다음 명령어는 러너를 시스템 또는 사용자 서비스로 관리할 수 있게 해줍니다. 이를 사용하여 러너 서비스를 설치, 제거, 시작, 중지할 수 있습니다.

모든 서비스 관련 명령어는 다음과 같은 인수들을 받습니다:

매개변수 기본값 설명
--service gitlab-runner 사용자 정의 서비스 이름 지정
--config 구성 파일 참조 사용할 사용자 정의 구성 파일

gitlab-runner install

이 명령은 GitLab Runner를 서비스로 설치합니다. 실행되는 시스템에 따라 다른 인수 집합을 받습니다.

Windows나 슈퍼-사용자로 실행되면 --user 플래그를 받아 셸 실행기로 실행되는 빌드의 권한을 낮출 수 있습니다.

매개변수 기본값 설명
--service gitlab-runner 사용할 서비스 이름 지정
--config 구성 파일 참조 사용할 사용자 정의 구성 파일 지정
--syslog true (systemd 시스템에 적합) 서비스가 시스템 로깅 서비스와 통합되어야 하는지 지정
--working-directory 현재 디렉터리 셸 실행기로 실행되는 빌드의 모든 데이터가 저장되는 루트 디렉터리 지정
--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 현재 디렉터리 셸 실행기로 실행되는 빌드의 모든 데이터가 저장되는 루트 디렉터리 지정
--user 현재 사용자 빌드를 실행하는 사용자 지정
--syslog false 모든 로그를 SysLog (Unix) 또는 EventLog (Windows)로 전송
--listen-address 없음 Prometheus 메트릭 HTTP 서버가 리스닝해야 하는 주소 (<호스트>:<포트>)를 지정

gitlab-runner run-single

이 명령은 단일 GitLab 인스턴스에서 단일 빌드를 실행하는 데 사용되는 보조 명령입니다. 설정 파일을 사용하지 않으며 모든 옵션을 매개변수 또는 환경 변수로 전달해야 합니다. GitLab URL 및 러너 토큰도 지정해야 합니다.

예를 들어: 

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 (사용 중단됨)

caution
이 기능은 deprecated되었으며, 17.0에서 삭제 예정입니다. 파이프라인 구문과 유효성 시뮬레이션은 GitLab 파이프라인 편집기에서 사용할 수 있습니다. 이 변경 사항은 기존의 기능에 큰 변화를 가져오는 것입니다.
note
모든 .gitlab-ci.yml의 기능이 exec에서 지원되지는 않습니다. gitlab-runner exec의 제한 사항을 확인해주세요.

이 명령은 가능한 한 CI 환경을 복제하려고 노력하여 로컬로 빌드를 실행할 수 있도록 해줍니다. GitLab에 연결할 필요가 없으며, 대신 로컬의 .gitlab-ci.yml을 읽고 모든 빌드 단계가 실행되는 새로운 빌드 환경을 생성합니다.

이 명령은 .gitlab-ci.yml에 있는 실행기와 작업 이름을 지정해야 합니다. 명령은 소스 코드가 있는 Git 리포지터리의 루트 디렉터리에서 실행되어야 합니다.

예를 들어, 다음 명령어는 쉘 실행기를 사용하여 tests라는 작업을 로컬로 실행합니다. 

gitlab-runner exec shell tests

모든 이용 가능한 실행기 디렉터리을 보려면 다음을 실행하세요. 

gitlab-runner exec

모든 사용 가능한 옵션 디렉터리을 보려면 shell 실행기에서 다음을 실행하세요. 

gitlab-runner exec shell

exec의 --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 예 확장된 구성(name, entrypoint)도 지원됩니다.
services 예 확장된 구성(name, alias, entrypoint, command)도 지원됩니다.
before_script 예 전역 및 작업 수준의 before_script을 모두 지원합니다.
after_script 부분적으로 전역 after_script은 지원되지 않습니다. 작업 수준의 after_script만 지원되며, 명령만 고려되며, when은 하드코딩으로 always로 설정됩니다.
variables 예 기본 변수(일부 지원), 전역 및 작업 수준 변수를 지원합니다. 기본 변수는 코드에서 확인할 수 있습니다.
cache 부분적으로 특정 구성에 따라 예상대로 작동할 수도, 그렇지 않을 수도 있습니다.
YAML 기능 예 앵커(&), 별칭(*), 맵 Merge(<<)은 YAML 명세서의 일부이며 파서에서 처리됩니다.
pages 부분적으로 작업 스크립트는 명시적으로 요청할 경우 실행되지만, GitLab에서 관리하는 페이지 상태에는 영향을 주지 않습니다.

호환성 테이블 - 변수 기반의 기능

GitLab CI 기능 exec로 가능 코멘트
GIT_STRATEGY 예  
GIT_CHECKOUT 예  
GIT_SUBMODULE_STRATEGY 예  
GIT_SUBMODULE_PATHS 예  
GIT_SUBMODULE_UPDATE_FLAGS 예  
GIT_SUBMODULE_DEPTH 예  
GIT_SUBMODULE_FORCE_HTTPS 예  
GET_SOURCES_ATTEMPTS 예  
ARTIFACT_DOWNLOAD_ATTEMPTS 아니오 아티팩트는 지원되지 않습니다.
RESTORE_CACHE_ATTEMPTS 예  

호환성 테이블 - 기타 기능

GitLab CI 기능 exec로 가능 코멘트
비밀 변수 아니오  
triggers 아니오  
schedules 아니오  
작업 시간 초과 아니오 1시간으로 하드코딩됨.
[ci skip] 아니오  

다른 요구사항 및 제한 사항

로컬에서 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

로컬 또는 외부에 저장된 파일에서 캐시 아카이브를 복원합니다.

문제 해결

일반적인 문제들은 아래와 같습니다.

서비스 관련 명령어를 실행할 때 액세스 거부가 발생합니다

일반적으로 서비스 관련 명령어는 관리자 권한이 필요합니다:

  • 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을 직접 호출합니다(/usr/bin이 $PATH에 있는 것으로 가정).
  • /usr/bin/gitlab-runner를 호출합니다.

gitlab-runner stop이 우아하게 종료되지 않는 경우

호스트에 설치된 러너가 로컬 실행자를 사용하고 있을 때, 추가 작업(아티팩트 다운로드 또는 업로드, 또는 캐시 처리)을 위해 추가적인 프로세스가 시작됩니다. 이러한 프로세스는 gitlab-runner 명령으로 실행되므로, 이러한 작업을 실행하는 경우 연관된 작업이 실패합니다.

이를 방지하는 두 가지 방법이 있습니다:

  • SIGQUIT를 종료 시그널로 사용하여 러너를 로컬 서비스(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 러너 15.7 및 15.8은 config.toml 파일을 포함하는 디렉터리에 대한 쓰기 권한이 없을 경우 시작되지 않을 수 있습니다.

GitLab 러너가 시작되면 config.toml을 포함하는 디렉터리에서 .runner_system_id 파일을 찾습니다. .runner_system_id 파일을 찾을 수 없는 경우 새 파일을 만듭니다. GitLab 러너에 쓰기 권한이 없으면 시작에 실패합니다.

이 문제를 해결하려면 일시적으로 파일 쓰기 권한을 허용한 다음 gitlab-runner run을 실행하십시오. .runner_system_id 파일이 생성되면 권한을 읽기 전용으로 재설정할 수 있습니다.