자체 호스팅 실행기 참조

자체 호스팅 실행기 컴퓨터에 대한 요구 사항

다음 요구 사항을 충족한다면 머신을 자체 호스팅 실행기로 사용할 수 있습니다.

컴퓨터에 자체 호스팅 실행기 애플리케이션을 설치하고 실행할 수 있습니다. 지원되는 운영 체제 및 지원되는 프로세서 아키텍처를 참조하세요.
기계는 GitHub Actions와 통신할 수 있습니다.
머신에는 실행하려는 워크플로 유형에 대한 충분한 하드웨어 리소스가 있습니다. 자체 호스팅 실행기 애플리케이션 자체에는 최소한의 리소스만 필요합니다.
Docker 컨테이너 작업 또는 서비스 컨테이너를 사용하는 워크플로를 실행하려면 Linux 컴퓨터를 사용해야 하며 Docker를 설치해야 합니다.

지원되는 운영 체제

Linux

Red Hat Enterprise Linux 8 이상
CentOS 8 이상
Oracle Linux 8 이상
Fedora 29 이상
Debian 10 이상
Ubuntu 20.04 이상
Linux Mint 20 이상
openSUSE 15.2 이상
SLES(SUSE Enterprise Linux) 15 SP2 이상

Windows

Windows 10 64비트
Windows 11 64비트
Windows Server 2016 64비트
Windows Server 2019 64비트
Windows Server 2022 64비트

지원되는 프로세서 아키텍처

x64 - Linux, macOS, Windows.
ARM64 - Linux, macOS.
ARM32 -리눅스.

자체 호스팅 실행기의 라우팅 우선 순위

작업을 자체 호스팅 러너로 라우팅할 때 GitHub는 작업의 runs-on 레이블 및 그룹과 일치하는 러너를 찾습니다.

GitHub가 작업의 runs-on 레이블 및 그룹과 일치하는 온라인 상태이고 유휴 상태인 실행기를 찾으면, 해당 작업이 그 실행기에 할당되고 전달됩니다.
- 해당 실행기가 할당된 작업을 60초 이내에 선택하지 않으면 새 실행기가 수락할 수 있도록 작업이 다시 큐에 대기됩니다.
GitHub이 작업의 runs-on 레이블과 그룹에 일치하는 온라인 상태의 유휴 실행기를 찾지 못하면, 실행기가 온라인 상태가 될 때까지 해당 작업은 대기열에 남아 있습니다.
24시간 넘게 큐에서 대기한 작업은 실패합니다.

자동 크기 조정을 사용하면 수요에 따라 자가 호스팅 런너 수를 동적으로 조정할 수 있습니다. 이렇게 하면 리소스 사용률을 최적화하고 사용량이 많은 시간에 충분한 실행기 용량을 보장하면서 활동량이 적은 기간 동안 비용을 절감할 수 있습니다. 자체 호스팅 실행기용 자동 크기 조정을 구현하는 방법에는 여러 가지가 있으며, 각각 복잡성, 안정성 및 응답성 측면에서 서로 다른 장차가 있습니다.

Actions Runner Controller

Actions Runner Controller (ARC)는 GitHub의 스케일 세트 API에 대한 참조 구현이자 자체 호스팅 러너의 오토스케일링을 위한 권장 Kubernetes 기반 솔루션입니다. ARC는 Kubernetes 환경에서 실행되는 GitHub Actions 팀을 위한 완전한 프로덕션 준비 자동 크기 조정 솔루션을 제공합니다.

GitHub 는 Kubernetes 인프라가 있는 조직 및 Kubernetes 전문 지식이 있는 팀에 ARC를 권장합니다. ARC는 프로비전에서 작업 실행, 정리에 이르기까지 클러스터 내 실행기의 전체 수명 주기를 처리합니다.

자세한 내용은 Actions Runner 컨트롤러 및 Actions Runner Controller 지원을(를) 참조하세요.

GitHub Actions Runner Scale Set 클라이언트

GitHub Actions Runner Scale Set 클라이언트는 플랫폼 팀, 통합자 및 인프라 공급자가 Windows, Linux 및 macOS 플랫폼을 지원하는 VM, 컨테이너, 온-프레미스 인프라 및 클라우드 서비스에서 GitHub Actions 실행기를 위한 사용자 지정 자동 크기 조정 솔루션을 빌드할 수 있도록 하는 독립 실행형 Go 기반 모듈입니다.

클라이언트는 확장 집합에 대한 API 상호작용을 조정GitHub하고, 인프라 프로비저닝은 사용자에게 맡깁니다. 실행기를 만들고, 크기를 조정하고, 소멸하는 방법을 정의하고, 유연한 작업 라우팅 및 대상 지정을 위해 여러 레이블이 있는 실행기를 구성합니다. 이를 통해 조직은 실행기 수명 주기 관리 및 작업 실행을 위한 실시간 원격 분석을 세부적으로 제어할 수 있습니다.

클라이언트는 기본 구성을 사용하여 기본적으로 작동하도록 설계되어 팀이 자동 크기 조정을 신속하게 구현할 수 있도록 합니다. 그러나 그 진정한 힘은 유연성에 있습니다. 클라이언트는 각 조직의 특정 인프라 요구 사항, 규정 준수 제약 조건 및 운영 워크플로를 충족하도록 확장되고 사용자 지정되도록 빌드됩니다. 간단한 크기 조정 논리 또는 복잡한 다중 환경 프로비저닝 전략이 필요한지 여부에 관계없이 클라이언트는 요구 사항에 맞게 조정됩니다.

GitHub Actions Runner Scale Set 클라이언트는 오픈 소스 프로젝트입니다. actions/scaleset 리포지토리에는 시작하는 데 유용한 전체 소스 코드, 포괄적인 설명서 및 실용적인 예시가 모두 포함되어 있습니다. 구현 가이드, 다양한 인프라 시나리오에 대한 샘플 구성 및 클라이언트를 다른 프로비저닝 시스템과 통합하는 방법을 보여주는 참조 아키텍처를 찾을 수 있습니다. 리포지토리에는 클라이언트를 확장하거나 자동 크기 조정 패턴을 커뮤니티와 공유하는 데 관심이 있는 팀을 위한 지침도 포함되어 있습니다.

참고: Runner Scale Set Client는 Actions Runner Controller (ARC)를 대체하는 것이 아니며, ARC는 계속해서 스케일 세트 API의 참조 구현이자 러너 자동 크기 조정을 위한 권장 Kubernetes 솔루션으로 남아 있습니다. 대신 클라이언트는 Kubernetes 외부에서 사용자 지정 자동 크기 조정 솔루션을 빌드하기 위해 동일한 확장 집합 API와 상호 작용하기 위한 보완 도구입니다.

자동 크기 조정을 위한 임시 실행기

GitHub 는 임시 자체 호스팅 실행기를 사용하여 자동 크기 조정을 구현하는 것이 좋습니다. 영구 자체 호스팅 실행기를 사용한 자동 크기 조정은 권장되지 않습니다. 특정한 경우에는 GitHub가 지속 실행기가 종료되는 동안 작업이 해당 실행기에 할당되지 않는다고 보장할 수 없습니다. 임시 러너를 사용하면 GitHub 러너에 작업 하나만 할당되므로 이를 보장할 수 있습니다.

이 방법을 사용하면 자동화를 사용하여 각 작업에 대한 정리된 환경을 제공할 수 있으므로 실행기를 임시 시스템으로 관리할 수 있습니다. 이렇게 하면 이전 작업에서 중요한 리소스의 노출을 제한하고 새 작업을 받는 손상된 실행기의 위험을 완화하는 데 도움이 됩니다.

경고

임시 실행기의 실행기 애플리케이션 로그 파일은 문제 해결과 진단을 위해 외부 로그 스토리지 솔루션으로 전달되어야 합니다. 임시 실행기를 배포할 필요는 없지만 프로덕션 GitHub 환경에서 임시 실행기 자동 크기 조정 솔루션을 배포하기 전에 실행기 로그를 외부적으로 전달하고 보존하는 것이 좋습니다. 자세한 내용은 자체 호스트형 실행기 모니터링 및 문제 해결을(를) 참조하세요.

사용 중인 환경에 임시 실행기를 추가하려면 --ephemeral를 사용하여 실행기를 등록할 때 config.sh 매개 변수를 포함합니다. 예를 들면 다음과 같습니다.

./config.sh --url https://github.com/octo-org --token example-token --ephemeral

GitHub Actions 서비스는 작업 하나를 처리한 후 실행기의 등록을 자동으로 해제합니다. 그런 다음, 등록이 해제된 후 실행기를 초기화하는 고유한 자동화를 만들 수 있습니다.

참고

작업이 특정 유형의 실행기에 대해 레이블이 지정되어 있으나 해당 유형과 일치하는 항목이 없는 경우, 대기 상태일 때 즉시 실패하지는 않습니다. 대신 24시간 제한 시간이 만료될 때까지 작업이 큐에 대기 상태로 유지됩니다.

또는 REST API를 사용하여 임시 Just-In-Time 실행기를 생성할 수 있습니다. 자세한 내용은 자체 호스트형 실행기에 대한 REST API 엔드포인트을(를) 참조하세요.

자체 호스팅 실행기에서 실행기 소프트웨어 업데이트

기본적으로 자체 호스팅 실행기는 새 버전의 실행기 소프트웨어를 사용할 수 있을 때마다 자동으로 소프트웨어 업데이트를 수행합니다. 컨테이너에서 임시 실행기를 사용하는 경우 새 실행기 버전이 릴리스될 때 소프트웨어 업데이트가 반복될 수 있습니다. 자동 업데이트를 해제하면 자체 일정에 따라 컨테이너 이미지의 실행기 버전을 직접 업데이트할 수 있습니다.

자동 소프트웨어 업데이트를 해제하고 소프트웨어 업데이트를 직접 설치하려면 --disableupdate를 사용하여 실행기를 등록할 때 config.sh 플래그를 지정합니다. 예를 들면 다음과 같습니다.

./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate

자동 업데이트를 사용하지 않도록 설정하는 경우 실행기 버전을 정기적으로 업데이트해야 합니다. GitHub Actions의 새로운 기능에는 GitHub Actions 서비스 및 러너 소프트웨어 모두에 변경이 필요합니다. 러너는 소프트웨어를 업데이트하지 않으면 GitHub Actions의 새로운 기능을 활용하는 작업을 올바르게 처리하지 못할 수 있습니다.

자동 업데이트를 사용하지 않도록 설정하는 경우 새 버전을 사용할 수 있게 된 후 30일 이내에 실행기 버전을 업데이트해야 합니다. actions/runner 리포지토리의 릴리스에 대한 알림을 구독하는 것이 좋습니다. 자세한 내용은 알림 구성을(를) 참조하세요.

최신 실행기 버전을 설치하는 방법에 대한 지침은 최신 릴리스의 설치 지침을 참조하세요.

경고

주요, 부 버전 또는 패치 릴리스를 포함하여 소프트웨어용으로 릴리스된 모든 업데이트는 사용 가능한 업데이트로 간주됩니다. 30일 이내에 소프트웨어 업데이트를 수행하지 않으면 GitHub Actions 서비스가 실행기의 큐에 작업을 추가하지 않습니다. 또한 중요한 보안 업데이트가 필요한 경우 GitHub Actions 서비스는 업데이트될 때까지 실행기의 큐에 작업을 추가하지 않습니다.

자동 크기 조정을 위한 웹후크

workflow_job 웹후크에서 받은 페이로드를 사용하여 고유한 자동 크기 조정 환경을 만들 수 있습니다. 이 웹후크는 리포지토리, 조직 및 엔터프라이즈 수준에서 사용할 수 있으며, 이 이벤트의 페이로드에는 워크플로 작업의 수명 주기 단계에 해당하는 action 키(예: 작업이 queued, in_progress 및 completed인 경우)가 포함됩니다. 그런 다음, 해당 웹후크 페이로드에 대한 응답으로 고유한 스케일링 자동화를 만들어야 합니다.

workflow_job 웹후크에 대한 자세한 내용은 웹후크 이벤트 및 페이로드을(를) 참조하세요.
웹후크 사용 방법을 알아보려면 웹후크 설명서을(를) 참조하세요.

참고: 이 방법은 크기 조정 결정을 내리기 위한 웹후크 배달의 타임라인에 의존하며, 이로 인해 지연 및 안정성 문제가 발생할 수 있습니다. 더 큰 볼륨 자동 크기 조정 시나리오에는 작업 컨트롤러 또는 확장 집합 클라이언트를 사용하는 것이 좋습니다.

인증 요구 사항

API를 사용하여 리포지토리 및 조직 자체 호스팅 실행기를 등록하고 삭제할 수 있습니다. API에 인증하기 위해 자동 크기 조정 구현은 액세스 토큰 또는 GitHub 앱을 사용할 수 있습니다.

액세스 토큰에는 다음 범위가 필요합니다.

프라이빗 리포지토리의 경우 repo범위가 있는 액세스 토큰을 사용합니다.
퍼블릭 리포지토리의 경우 public_repo범위가 있는 액세스 토큰을 사용합니다.
조직의 경우 admin:org범위가 있는 액세스 토큰을 사용합니다.

앱을 사용하여 GitHub 인증하려면 다음 권한이 할당되어야 합니다.

리포지토리의 경우 administration 권한을 할당합니다.
조직의 경우 organization_self_hosted_runners 권한을 할당합니다.

API를 사용하여 엔터프라이즈 자체 호스팅 실행기를 등록하고 삭제할 수 있습니다. API에 인증하기 위해 액세스 토큰을 사용하여 자동 스케일링을 구현할 수 있습니다.

액세스 토큰에는 manage_runners:enterprise 범위가 필요합니다.

커뮤니케이션

자체 호스팅 실행기는 GitHub Enterprise Server 인스턴스에 연결하여 작업 할당을 수신하고 실행기 애플리케이션의 새 버전을 다운로드합니다.

GitHub Actions 실행기 애플리케이션이 오픈 소스입니다. 실행기 리포지토리에서 기여하고 문제를 제출할 수 있습니다. 새 버전이 릴리스되면 실행기 애플리케이션은 24시간 이내에 자동으로 업데이트됩니다.

와 GitHub Enterprise Server 인스턴스와의 통신 요구 사항

작업을 수락하고 실행하려면 자체 호스팅 실행기 애플리케이션이 호스트 컴퓨터에서 실행 GitHub Actions 중이어야 합니다.
GitHub Enterprise Server는 GitHub Enterprise Server 인스턴스의 호스트 이름 및 API 하위 도메인에서 HTTP(S)를 통해 러너의 인바운드 연결을 수락해야 하며, 러너는 GitHub Enterprise Server 인스턴스의 호스트 이름 및 API 하위 도메인에 대해 HTTP(S)를 통한 아웃바운드 연결을 허용해야 합니다.
캐싱이 작동하려면 실행기에서 Blob Storage와 통신하고, Blob Storage에서 콘텐츠를 직접 다운로드할 수 있어야 합니다.

GitHub.com와의 통신

자체 호스팅 실행기는 GitHub.com에 대해 GitHub.com 액션에 대한 자동 액세스를 사용하도록 설정한 경우가 아니라면 GitHub Enterprise Server에 연결할 필요가 없습니다. 자세한 내용은 엔터프라이즈에서 작업 사용 정보을(를) 참조하세요.

러너가 GitHub.com에 연결되게 하려면 호스트 컴퓨터가 포트 80으로 외부 HTTP 연결을 하거나 포트 443으로 HTTPS 연결을 할 수 있어야 합니다. HTTPS를 통한 연결을 보장하려면 GitHub Enterprise Server에 대해 TLS를 구성합니다. TLS 구성을(를) 참조하세요.

GitHub.com 작업에 대한 자동 액세스를 사용하도록 설정한 경우, 자체 호스팅 러너가 작업을 다운로드하기 위해 GitHub.com에 직접 연결합니다. 컴퓨터에 아래 나열된 URL과 GitHub 통신할 수 있는 적절한 네트워크 액세스 권한이 있는지 확인해야 합니다.

Shell

github.com
api.github.com
codeload.github.com

github.com
api.github.com
codeload.github.com

REST API를 사용하여 서비스에 대한 GitHubIP 주소 및 도메인 세부 정보를 GitHub 포함하여 메타 정보를 가져올 수 있습니다. API의 actions_inbound 섹션은 정규화된 도메인과 와일드카드 도메인을 모두 지원합니다. 완전히 정규화된 도메인은 완전한 도메인 이름(예: example.github.com)을 지정하는 반면, 와일드카드 도메인은 *을(를) 사용하여 여러 개의 가능한 하위 도메인(예: *.github.com)을 나타냅니다. 와일드카드 도메인을 사용하는 자체 호스팅 실행기 요구 사항의 예시는 아래에 나열되어 있습니다. 자세한 내용은 메타 데이터에 대한 REST API 엔드포인트을(를) 참조하세요.