참고: GitHub 호스트 실행기는 현재 GitHub Enterprise Server에서 지원되지 않습니다. GitHub public roadmap에 예정된 향후 지원에 대해 자세히 알아볼 수 있습니다.
자동 스케일링 정보
특정 레이블을 사용하여 수신하는 웹후크 이벤트에 대한 응답으로 환경에서 자체 호스트형 실행기 수를 자동으로 늘리거나 줄일 수 있습니다. 예를 들어 queued 활동과 함께 workflow_job 웹후크 이벤트를 받을 때마다 새 자체 호스트형 실행기를 추가하는 자동화를 만들어 새 작업을 처리할 준비가 되었다는 알림을 받을 수 있습니다. 웹후크 페이로드는 레이블 데이터를 포함하므로 작업이 요청하는 실행기 유형을 식별할 수 있습니다. 작업이 완료되면 workflow_job completed 작업에 대한 응답으로 실행기를 제거하는 자동화를 만들 수 있습니다.
지원되는 자동 크기 조정 솔루션
actions/actions-runner-controller (ARC) 프로젝트는 Kubernetes 기반 실행기의 자동크 조정기입니다. GitHub는 배포하는 팀에 전문적인 Kubernetes 지식과 경험이 있는 경우 ARC를 권장합니다.
자세한 내용은 "Actions Runner Controller 정보" 및 "Actions Runner Controller 지원 정보" 항목을 참조하세요.
자동 스케일링에 임시 실행기 사용
GitHub은(는) 임시 자체 호스트형 실행기를 사용하여 자동 스케일링을 구현할 것을 권장합니다. 영구 자체 호스트형 실행기를 사용한 자동 스케일링은 권장되지 않습니다. 경우에 따라 GitHub은(는) 작업이 종료되는 동안 영구 실행기에 할당되지 않음을 보장할 수 없습니다. 임시 실행기를 사용하면 GitHub이(가) 실행기에 하나의 작업만 할당하기 때문에 이를 보장할 수 있습니다.
이 방법을 사용하면 자동화를 사용하여 각 작업에 대한 정리된 환경을 제공할 수 있으므로 실행기를 임시 시스템으로 관리할 수 있습니다. 이렇게 하면 이전 작업에서 중요한 리소스의 노출을 제한하고 새 작업을 받는 손상된 실행기의 위험을 완화하는 데 도움이 됩니다.
Warning
임시 실행기의 애플리케이션 로그 파일은 문제 해결 및 진단을 위해 외부 로그 스토리지 솔루션으로 전달해야 합니다. 임시 실행기를 배포할 필요는 없지만, GitHub에서는 프로덕션 환경에 임시 실행기 자동 확장 솔루션을 배포하기 전에 실행기 로그가 외부로 전달하고 보존하는 것을 권장합니다. 자세한 내용은 "자체 호스트형 실행기 모니터링 및 문제 해결"을(를) 참조하세요.
사용 중인 환경에 임시 실행기를 추가하려면 config.sh를 사용하여 실행기를 등록할 때 --ephemeral 매개 변수를 포함합니다. 예:
./config.sh --url https://github.com/octo-org --token example-token --ephemeral
그러면 GitHub Actions 서비스가 하나의 작업을 처리한 후 실행기를 자동으로 등록 해제합니다. 그런 다음, 등록이 해제된 후 실행기를 초기화하는 고유한 자동화를 만들 수 있습니다.
Note
특정 유형의 실행기에서 작업에 레이블이 지정되어 있지만 해당 형식과 일치하는 항목이 없는 경우 큐에 대기할 때 작업이 즉시 실패하지는 않습니다. 대신 24시간 제한 시간이 만료될 때까지 작업이 큐에 대기 상태로 유지됩니다.
또는 REST API를 사용하여 임시 Just-In-Time 실행기를 만들 수 있습니다. 자세한 내용은 "자체 호스트형 실행기에 대한 REST API 엔드포인트"을(를) 참조하세요.
자체 호스트형 실행기에서 실행기 소프트웨어 업데이트 제어
기본적으로 자체 호스트형 실행기는 새 버전의 실행기 소프트웨어를 사용할 수 있을 때마다 자동으로 소프트웨어 업데이트를 수행합니다. 컨테이너에서 임시 실행기를 사용하는 경우 새 실행기 버전이 릴리스될 때 소프트웨어 업데이트가 반복될 수 있습니다. 자동 업데이트를 해제하면 자체 일정에 따라 컨테이너 이미지의 실행기 버전을 직접 업데이트할 수 있습니다.
자동 소프트웨어 업데이트를 해제하고 소프트웨어 업데이트를 직접 설치하려면 config.sh를 사용하여 실행기를 등록할 때 --disableupdate 플래그를 지정합니다. 예:
./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate
자동 업데이트를 사용하지 않도록 설정하는 경우 실행기 버전을 정기적으로 업데이트해야 합니다. GitHub Actions의 새로운 기능을 사용하려면 GitHub Actions 서비스_와_ 실행기 소프트웨어를 모두 변경해야 합니다. 실행기는 소프트웨어 업데이트 없이 GitHub Actions의 새로운 기능을 활용하는 작업을 올바르게 처리하지 못할 수 있습니다.
자동 업데이트를 사용하지 않도록 설정하는 경우 새 버전을 사용할 수 있게 된 후 30일 이내에 실행기 버전을 업데이트해야 합니다. actions/runner리포지토리의 릴리스에 대한 알림을 구독하는 것이 좋습니다. 자세한 내용은 "알림 구성"을 참조하세요.
최신 실행기 버전을 설치하는 방법에 대한 지침은 최신 릴리스의 설치 지침을 참조하세요.
Warning
주요, 부 버전 또는 패치 릴리스를 포함하여 소프트웨어용으로 릴리스된 모든 업데이트는 사용 가능한 업데이트로 간주됩니다. 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 범위가 필요합니다.