Github-hosted Runner는 간단하고 빠르게 Workflow를 운영할 수 있다. 반면에 self-hosted Runner는 당신의 환경에 맞추어 커스터마이징할수 있는 여지가 많다.
GitHub-hosted runners
Github으로부터 관리되는 가상환경이며 매 Job 실행마다 Clean한 인스턴스가 제공된다. 무료로 제공되는 몇분이 있고 그이후에는 분단위로 과금된다.
Self-hosted runners
Runner에 대한 업데이트는 비활성화하면서도 Runner 어플리케이션만 자동업데이트를 하게된다. 이러한 Runner S/W 업데이트에 대한 자세한 내용은 이 링크를 참조바란다.
그리고 직접 관리하는 로컬머신이나 Cloud 서비스에서 운영하므로 당신은 해당 OS와 관련 S/W에 대한 책임이 생긴다. 대신 당신의 인프라 자원을 커스터마이징 할 수 있기에 응용성이 높다. 매번 Job실행시에도 인스턴스가 초기화 되지않아 연속성을 지닌다. 당신의 Runner가 작동하는 Machine에 대한 비용이 발생할 뿐 Github Actions는 무료로 사용가능하다.
아래의 요구사항만 맞다면 당신은 self-hosted Runner를 사용할 수 있다.
- 지원되는 아키텍처와 OS. 자세한 내용은 링크 참조
- Runner가 돌아갈 인스턴스는 Github Actions와 통신할 수 있어야 한다. 자세한 내용은 링크 참조
- Runner가 돌아갈 인스턴스는 Workflow를 돌리기에 충분한 Hardware 스펙을 가져야한다.
- 만약 Docker 컨테이너를 사용할 경우 반드시 Linux+Docker 로 사용해야 한다.
self-hosted Runner를 AutoScaling하기
Github은 임시 self-hosted Runner방식으로 Auto Scaling을 사용토록 권장하고 있다. (영구가 아닌)
동시다발적으로 발생하는 Runner가 각각 Clean한 인스턴스로 올라오게 해야 상호간섭이 없다.
Autoscaling with self-hosted runners - GitHub Docs
You can automatically increase or decrease the number of self-hosted runners in your environment in response to the webhook events you receive with a particular label. For example, you can create automation that adds a new self-hosted runner each time you
docs.github.com
Usage limits
- Workflow의 실행시간은 최장 35일이다. 만약 이 한계를 넘으면 자동으로 취소된다.
- Job의 Queue 발생시간이 24시간을 넘어가면 취소된다.
- 시간당 최대 1000개의 Request까지 API호출이 가능하다. 만약 초과하면 초과된 API 콜은 FAIL로 처리된다.
- WorkFlow당 최대 256개의 Job을 생성할 수 있다.
- 레포지토리당, 10초당 500개 이상의 Workflow가 Queue가 발생할 수는 없다. 만약 이 한계치에 도달하면 그 Workflow는 종료되고 FAIL처리된다.
- 당신은 Runner 그룹당 최대 10000개의 self-hosted Runner 등록이 가능하다.
'PaaS > CI CD' 카테고리의 다른 글
| Github Actions) 성능제고를 위한 방안 cache (0) | 2024.02.20 |
|---|---|
| Github Actions) AutoScaling Runner Controller 아키텍처 설명 (0) | 2024.01.28 |
| (Gitlab) Merge Request시 delete source branch가 체크되어 있는 경우 (1) | 2023.12.14 |
| Gitlab 의 Project내의 특정 파일을 Access Token 만으로 접근하여 다운로드 (1) | 2023.12.08 |
| Github Actions의 Workflow에서 GCP(Google Cloud Platform) 인증받기 (1) | 2023.12.07 |