기존 Runner 방식과 다른점은 Workflow가 동시에 발생하더라도 병렬적으로 수용할 수 있도록 RunnerSet에 AutoScaling 개념이 적용되어 있다는 점과, 모두 Ephemeral 하게 Running되어 모든 Job이 Clean하게 종료되고 Clean한 상태에서 Startup된다는 것이다.
설치되는 컴포넌트는 크게 두개의 Chart이다.
- RunnerSetController : https://github.com/actions/actions-runner-controller/tree/master/charts/gha-runner-scale-set
- RunnerSet : https://github.com/actions/actions-runner-controller/tree/master/charts/gha-runner-scale-set
1) Actions Runner Controller is installed using the supplied Helm charts, and the controller manager pod is deployed in the specified namespace. A new AutoScalingRunnerSet resource is deployed via the supplied Helm charts or a customized manifest file. The AutoScalingRunnerSet Controller calls GitHub's APIs to fetch the runner group ID that the runner scale set will belong to.
: Actions Runner Controller는 제공된 Helm 차트를 사용하여 설치되고 컨트롤러 관리자 Pod는 지정된 네임스페이스에 배포됩니다. 새로운 AutoScalingRunnerSet 리소스는 제공된 Helm 차트 또는 사용자 정의된 매니페스트 파일을 통해 배포됩니다. AutoScalingRunnerSet 컨트롤러는 GitHub의 API를 호출하여 runner scale set이 속할 runner group ID를 가져옵니다.
2) The AutoScalingRunnerSet Controller calls the APIs one more time to either fetch or create a runner scale set in the GitHub Actions service before creating the Runner ScaleSet Listener resource.
: AutoScalingRunnerSet Controller는 Runner ScaleSet Listener 리소스를 만들기 전에 GitHub Actions 서비스에서 runner scale set을 가져오거나 만들기 위해 API를 한 번 더 호출합니다.
3) A Runner ScaleSet Listener pod is deployed by the AutoScalingListener Controller. In this pod, the listener application connects to the GitHub Actions Service to authenticate and establish an HTTPS long poll connection. The listener stays idle until it receives a Job Available message from the GitHub Actions Service.
: Runner ScaleSet Listener Pod는 AutoScalingListener Controller에 의해 배포됩니다. 이 Pod에서 Listener 애플리케이션은 GitHub Actions Service에 연결하여 HTTPS 긴 폴링 연결을 인증하고 설정합니다. Listener는 GitHub Actions Service에서 Job Available 메시지를 받을 때까지 유휴 상태를 유지합니다.
4) When a workflow run is triggered from a repository, the GitHub Actions Service dispatches individual job runs to the runners or runner scalesets where the runs-on key matches the name of the runner scaleset or labels of self-hosted runners.
: 워크플로 실행이 리포지토리에서 트리거되면 GitHub Actions 서비스는 실행 키가 runner scalesets의 이름 또는 self-hosted runners의 lable과 일치하는 runner 또는 runner scaleset에 개별 작업 실행을 전달합니다.
5) When the Runner ScaleSet Listener receives the Job Available message, it checks whether it can scale up to the desired count. If it can, the Runner ScaleSet Listener acknowledges the message.
: Runner ScaleSet Listener는 Job Available 메시지를 수신하면 원하는 수까지 확장할 수 있는지 확인합니다. 가능한 경우 Runner ScaleSet Listener는 메시지를 확인합니다.
Runner ScaleSet Listener는 서비스 계정과 해당 계정에 바인딩된 역할을 사용하여 Kubernetes API를 통해 HTTPS 호출을 수행하여 원하는 복제본 수로 Ephemeral RunnerSet 리소스를 패치합니다.
6) The Runner ScaleSet Listener uses a Service Account and a Role bound to that account to make an HTTPS call through the Kubernetes APIs to patch the Ephemeral RunnerSet resource with the number of desired replicas count.
: Ephemeral RunnerSet는 새 Runner를 생성하려고 시도하고 EphemeralRunner 컨트롤러는 이러한 Runner를 등록하기 위해 JIT(Just-in-Time) 구성 토큰을 요청합니다. Controller가 Runner Pods 생성을 시도합니다. Pod 상태가 Fail인 경우 Contoller는 최대 5번까지 재시도합니다. 24시간 후 실행자가 수락하지 않으면 GitHub Actions 서비스가 작업 할당을 취소합니다.
7) The Ephemeral RunnerSet attempts to create new runners and the EphemeralRunner Controller requests a Just-in-Time (JIT) configuration token to register these runners. The controller attempts to create runner pods. If the pod's status is failed, the controller retries up to 5 times. After 24 hours the GitHub Actions Service unassigns the job if no runner accepts it.
: Runner Pod가 생성되면 Pod의 러너 애플리케이션은 JIT 구성 토큰을 사용하여 GitHub Actions 서비스에 등록됩니다. 그런 다음 실행해야 하는 작업 세부 정보를 수신하기 위해 또 다른 HTTPS 긴 폴링 연결을 설정합니다.
8) Once the runner pod is created, the runner application in the pod uses the JIT configuration token to register itself with the GitHub Actions Service. It then establishes another HTTPS long poll connection to receive the job details it needs to execute.
The GitHub Actions Service acknowledges the runner registration and dispatches the job run details.
Throughout the job run execution, the runner continuously communicates the logs and job run status back to the GitHub Actions Service.
When the runner completes its job successfully, the EphemeralRunner Controller checks with the GitHub Actions Service to see if runner can be deleted. If it can, the Ephemeral RunnerSet deletes the runner.
: GitHub Actions 서비스는 Runner 등록을 승인하고 작업 실행 세부 정보를 전달합니다.
작업 실행 전반에 걸쳐 Runner는 로그 및 작업 실행 상태를 GitHub Actions 서비스에 지속적으로 전달합니다.
Runner가 작업을 성공적으로 완료하면 EphemeralRunner Controller는 GitHub Actions 서비스를 확인하여 Runner를 삭제할 수 있는지 확인합니다. 가능하다면 Ephemeral RunnerSet는 Runner를 삭제합니다.
'PaaS > CI CD' 카테고리의 다른 글
| Github Actions) Workflow 자동실행 조건에 Tag와 Branch 모두 걸기 (0) | 2024.02.20 |
|---|---|
| Github Actions) 성능제고를 위한 방안 cache (0) | 2024.02.20 |
| Github Actions) Github-hosted와 self-hosted runner의 차이점 (0) | 2024.01.03 |
| (Gitlab) Merge Request시 delete source branch가 체크되어 있는 경우 (1) | 2023.12.14 |
| Gitlab 의 Project내의 특정 파일을 Access Token 만으로 접근하여 다운로드 (1) | 2023.12.08 |