자체 호스트형 실행기 모니터링 및 문제 해결

자체 호스트형 실행기의 상태 확인

자체 호스트형 실행기는 리포지토리, 조직 또는 GitHub Enterprise Server 인스턴스의 엔터프라이즈 설정에서 찾을 수 있습니다. 자체 호스트 실행기를 관리하려면 자체 호스트 실행기를 추가한 위치에 따라 다음 권한이 있어야 합니다.

• 사용자 리포지토리: 리포지토리 소유자여야 합니다.

• 조직: 조직 소유자여야 합니다.

• 조직 리포지토리: 조직 소유자거나 리포지토리에 대한 관리자 액세스 권한이 있어야 합니다.

• 엔터프라이즈: GitHub Enterprise 사이트 관리자여야 합니다.

1. 조직 또는 리포지토리에서 기본 페이지로 이동하여 설정을 클릭합니다.

2. 왼쪽 사이드바에서 작업을 클릭한 다음 실행기를** 클릭합니다**.

3. "실행기"에서 실행기 이름, 레이블 및 상태를 포함하여 등록된 실행기 목록을 볼 수 있습니다.

   상태는 다음 중 하나로 표시될 수 있습니다.

   • 유휴 상태: 실행기가 GitHub Enterprise Server에 연결되어 있으며 작업을 실행할 준비가 되었습니다.
   • 활성: 실행기에서 현재 작업을 실행하고 있습니다.
   • 오프라인: 실행기가 GitHub Enterprise Server에 연결되어 있지 않습니다. 이는 컴퓨터가 오프라인 상태이거나, 자체 호스트형 실행기 애플리케이션이 컴퓨터에서 실행되고 있지 않거나, 자체 호스트형 실행기 애플리케이션이 GitHub Enterprise Server과(와) 통신할 수 없기 때문일 수 있습니다.

네트워크 연결 문제 해결

자체 호스트형 실행기 네트워크 연결 확인

자체 호스팅 러너 애플리케이션의 run 스크립트에 --check 매개 변수를 사용하여 자체 호스팅 러너가 GitHub Enterprise Server 인스턴스에서 필요한 모든 네트워크 서비스에 액세스할 수 있는지 확인할 수 있습니다.

--check 이외에 스크립트에 다음 인수 두 개를 제공해야 합니다.

• --url: GitHub 리포지토리, 조직 또는 엔터프라이즈에 대한 URL과 함께 제공합니다. 예: --url https://github.com/octo-org/octo-repo.
• --pat의 값과 함께 workflow 범위가 있는 personal access token 또는 fine-grained personal access token가 있어야 합니다. 예: --pat ghp_abcd1234. 자세한 내용은 "개인용 액세스 토큰 관리"을 참조하세요.

예:

./run.sh --check --url URL --pat ghp_abcd1234

./run.sh --check --url URL --pat ghp_abcd1234

run.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat GHP_ABCD1234

스크립트는 각 서비스를 테스트하고 각 서비스에 대해 PASS 또는 FAIL을 출력합니다. 실패한 검사가 있는 경우 해당 검사에 대한 로그 파일에서 문제에 관한 자세한 내용을 볼 수 있습니다. 로그 파일은 실행기 애플리케이션을 설치한 _diag 디렉터리에 있으며 각 검사에 대한 로그 파일의 경로는 스크립트의 콘솔 출력에 표시됩니다.

실패한 검사가 있는 경우 자체 호스트형 실행기 컴퓨터가 모든 통신 요구 사항을 충족하는지 확인해야 합니다. 자세한 내용은 "자체 호스트형 실행기 정보"을 참조하세요.

TLS 인증서 확인 사용 안 함

기본적으로 자체 호스트형 실행기 애플리케이션은 GitHub Enterprise Server에 대한 TLS 인증서를 확인합니다. GitHub Enterprise Server에 자체 서명되거나 내부적으로 발급된 인증서가 있는 경우 테스트 목적으로 TLS 인증서 확인을 사용하지 않도록 설정할 수 있습니다.

자체 호스트형 실행기 애플리케이션에서 TLS 인증 확인을 사용하지 않도록 설정하려면 자체 호스트형 실행기 애플리케이션을 구성하고 실행하기 전에 GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY 환경 변수를 1로 설정합니다.

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

자체 호스트형 실행기 애플리케이션 로그 파일 검토

자체 호스트형 실행기 애플리케이션의 상태 및 해당 활동을 모니터링할 수 있습니다. 로그 파일은 실행기 애플리케이션을 설치한 _diag 디렉터리에 보관되며 애플리케이션이 시작될 때마다 새 로그가 생성됩니다. 파일 이름은 Runner_로 시작하며, 그 뒤에는 애플리케이션이 시작된 시점의 UTC 타임스탬프가 있습니다.

워크플로 작업 실행에 대한 자세한 로그는 다음 섹션에서 Worker_ 파일에 대해 설명합니다.

작업의 로그 파일 검토

자체 호스트형 실행기 애플리케이션은 처리하는 각 작업에 대한 자세한 로그 파일을 생성합니다. 이 파일은 러너 애플리케이션을 설치한 _diag 디렉터리에 저장되며 파일 이름은 Worker_로 시작합니다.

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

$ systemctl --type=service | grep actions.runner
actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

Feb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started running service
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Name                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Running

PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded
     135 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:34Z: Running job: testAction
     134 Mar 17 13:41  Information ActionsRunnerService          100 2020-03-17 13:41:54Z: Listening for Jobs
     133 Mar 17 13:41  Information ActionsRunnerService          100 û Connected to GitHub
     132 Mar 17 13:41  Information ActionsRunnerService            0 Service started successfully.
     131 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner listener
     130 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner Service
     129 Mar 17 13:41  Information ActionsRunnerService          100 create event log trace source for actions-runner service

자동 업데이트 프로세스 모니터링

자체 호스트형 실행기는 특정 버전 임계값보다 낮은 경우 작업을 처리할 수 없기 때문에 자동 업데이트 프로세스를 정기적으로 확인하는 것이 좋습니다. 자체 호스트형 실행기 애플리케이션은 자동으로 업데이트되지만 이 프로세스에는 운영 체제 또는 기타 소프트웨어에 대한 업데이트가 포함되지 않기 때문에 해당 업데이트는 별도로 관리해야 합니다.

Runner_ 로그 파일에서 업데이트 활동을 볼 수 있습니다. 예시:

[Feb 12 12:37:07 INFO SelfUpdater] An update is available.

또한 실행기 애플리케이션을 설치한 _diag 디렉터리에 있는 SelfUpdate 로그 파일에서 자세한 정보를 찾을 수 있습니다.

$ sudo systemctl is-active docker.service
active

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.
[2020-02-13 16:56:10Z ERR  StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'

dial unix /var/run/docker.sock: connect: permission denied

$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user

GitHub Enterprise Server 인스턴스의 업그레이드 후 오프라인 상태인 러너 확인 중

임시 실행기를 사용하고 자동 업데이트를 비활성화한 경우 GitHub Enterprise Server 인스턴스을 업그레이드하기 전에 먼저 자체 호스팅 실행기를 업그레이드한 인스턴스가 실행될 실행기 애플리케이션 버전으로 업그레이드해야 합니다. 임시 실행기를 업그레이드하기 전에 GitHub Enterprise Server 인스턴스을 업그레이드하면 실행기가 오프라인 상태가 될 수 있습니다. 자세한 내용은 "GitHub Enterprise 서버 업그레이드"을 참조하세요.

이러한 이유로 실행기가 오프라인 상태인 경우 실행기를 수동으로 업데이트합니다. 자세한 내용은 작업/실행기 리포지토리에서 최신 릴리스에 대한 설치 지침을 참조하세요.

러너에 설치된 Docker 엔진 확인

다음 오류와 함께 빌드가 실패하는 경우:

Error: Input required and not supplied: java-version

자체 호스팅 러너에 어떤 Docker 엔진이 설치되어 있는지 확인하세요. 러너는 작업의 입력을 Docker 컨테이너로 전달하기 위해 이름에 대시가 포함될 수 있는 환경 변수를 사용합니다. Docker 엔진이 바이너리 실행 파일이 아니라 셸 래퍼 또는 링크인 경우(예: snap을 사용하는 Linux에 설치된 Docker 엔진) 작업에서 입력을 가져오지 못할 수 있습니다. 이 오류를 해결하려면 자체 호스팅 러너가 다른 Docker 엔진을 사용하도록 구성하세요.

snap을 사용하여 Docker 엔진이 설치되었는지 확인하려면 which 명령을 사용하세요. 다음 예에서는 snap을 사용하여 Docker 엔진이 설치되었습니다:

$ which docker
/snap/bin/docker