2023 09 23 OSS argo workflows 모임에서 발표한 자료입니다. 자유롭게 사용가능하지만 공유시 출처만 남겨주세요!

1. 23.09.03 created by newdeal.
Github Actions 쿠버네티스에서
self-hosted로 설치&운영하기

2. Drone CI를 떠나며 …

3. Drone CI에 대한 간단한 소개.
컨테이너 기반의 CI 도구로, Docker 컨테이너 내에서 작동하는 모든 언어, 데이터베이스, 서비스와 호환됩니다.
이로 인해 사용자는 수천 개의 공개 Docker 이미지 중에서 선택하거나, 자신만의 이미지를 사용하면
Drone이 자동으로 환경을 프로비저닝합니다.
예를들어, 하나의 job에 각각의 step에서 image를 선택하면 kubernetes에서는 1개의 pod가 생성되는데,
그 pod의 컨테이너는 각 step의 image로 이루어져 있습니다.
당시 팀은 가장 큰 장점으로 “all the developers use CI (Continuous Integration) by themselves.” 를 꼽았었습니다.

4. 이것이 차세대 CI 도구다! (희망편)

5. 이것이 차세대 CI 도구다! (절망편)
https://github.com/harness/drone/graphs/contributors

6. Github Actions을 쓰자!

7. Github Actions 도구를 운영하기 위한 여러가지 방법들.
Github-Hosted Self-Hosted Self-Hosted
따로 운영 비용 발생 X
Github의 VM위에서 실행됨
Github이 지원하는 OS,HW만 가능
최대 2vCPU, AMD, 7GB
Azure 서버 다운타임 발생 가능
운영 비용 발생
K8s 운영 장점이 그대로 적용
더 나은 보안, 관찰가능성
Resource,OS 할당 자유롭게 선택
Pod 단위의 격리된 실행
운영 비용 발생
디테일한 설정이 까다로움
더 나은 보안
OS 할당 자유롭게 선택
job의 설정값을 서버에 구축 가능

8. kubernetes에서 self-hosted 사용!
결정에 큰 고민은 없었습니다.
이유1: Drone CI가 컨테이너 기반이라 엔지니어들이 익숙함
이유2: CI 도구를 쿠버네티스 기반해 운영한 경험
이유3: 단일 인스턴스로 도구 설치&운영 너~무 별로다..
이유4: 가장 비용효율적인 결정이기도..

9. Actions Runner Controller
(ARC)

10. Actions Runner Controller!

11. 우선 helm으로 ARC 설치부터
ARC를 chart를 참고해 helm을 통해 설치해야 합니다.
values가 다양하고 많아서 첫 구성에 시간이 걸릴 수 있습니다.
추가로 cert-manager 와 ingress 설치도 필요합니다.
설치가 완료되었다면, Github API로 인증하기 위해 Github
App을 등록해야 합니다. (문서 참고)

12. Runner를 실행시킬 CRD를 생성합니다.
• helm으로 설치되진 않고 추가
적으로 설치해줘야 합니다.
• job이 실행될 pod의 replica
나 resources 등을 정의해줍니
다.
• RunnerDeployment or
RunnerSet으로 설치합니다.

13. job이 실행되는 예시!
https://github-actions.newdeal.com

14. 스케일링 방법은 어떻게 할까요?
스케일-아웃과 스케일-인을 포함해서 지칭합니다.

15. 스케일링 구성을 안 해준다면 …
기본적인 ARC 구조에서는, workflow job이 들어올 때마다,
실행 가능한 runner에 job을 배치합니다.
즉, runner가 모두 실행되고 있으면, 큐에 쌓여져 대기해야 …

16. Runner를 스케일링 할 CRD의 다양한 종류
• 그래서 ARC에서는
`HorizontalRunnerAutoscaler`
(이하 HRA) 라는 CRD를 제공합니
다.
• 이 HRA의 옵션으로 다양한 오토 스
케일링 방식을 사용할 수 있습니다.
• 단, 각 방식마다 구현 방식이 달라 그
에 따른 장단점이 존재합니다.
Github
API
ARC Github
API
ARC
Pull-Driven Scaling Webhook-Driven Scaling

17. 알맞은 스케일링 방법을 찾아보자!
주의) 살짝 지루할 수 있음.

18. Pull-Driven Scaling - TotalNumberofQueued
• “TotalNumberofQueued…” 메트릭은
주어진 repo 집합에 대해 Pending 상태
의 모든 워크플로 개수를 폴링합니다.
• Pending 개수에 따라 최대
maxReplicas 값까지 러너 수를 확장합
니다.
1. OSS-work
fl
ows 레포에서 4개의 워크플로가
pending 상태
2. HRA가 이 정보를 폴링 (interval은 설정 가능)
3. 4개의 runner를 추가로 올림.
4. “scaleDownDelaySecondsAfterScaleOut”
시간 후에 pending 상태의 runner가 없다면 스
케일 다운,
예시)

19. Pull-Driven Scaling - TotalNumberofQueued
장점
1. 특정 리포지토리를 지정해서 지정된 리포지토리 집합으로
제한할 수 있습니다. (즉, 화이트리스팅 방식)
2. 작업 대기열의 깊이에 따라 러너 수를 스케일링합니다. 즉,
대기 중인 작업에 대해 러너의 1:1 스케일링입니다.
단점
1. 리포지토리 목록이 확장 메트릭에 포함되어야 합니다. 즉, 화
이트리스팅 방식이므로 대규모 환경이나 셀프 서비스 환경
에서는 리포지토리 목록을 유지 관리하는 것이 실행 가능하
지 않을 수 있습니다. (레포지토리 목록을 일일이 추가해줘
야 합니다.)
2. 충분히 빠르게 확장되지 않을 수 있습니다. 이 메트릭은 풀
기반으로 동작하므로 interval 주기에 따라 설정된 러너 수
를 폴링하므로, 결과적으로 확장 성능은 이 interval 주기에
한정되어 스케일링에 지연이 발생할 수 있습니다.
3. 이 메트릭을 유지하려면 비교적 많은 양의 API 요청이 필요
하므로 환경 규모와 동기화 기간 구성이에 따라 API 속도 제
한 문제가 발생할 수 있습니다.

20. Pull-Driven Scaling - PercentageRunnersBusy
• “PercentageRunnersBusy” 메트릭은
Github API 정보를 폴링해 Running 상
태의 runner의 개수가 얼마나 존재하는
지 확인한 다음 스케일링 합니다.
1. 전체 10개 runner 중 8개의 runner가 “Running"
상태
2. “scaleUpThreshold” 값인 75%를 넘었으므로
“scaleUpAdjustment” 값인 2만큼 runner를
늘림
3. 전체 12개 runner 중 3개의 runner가 “Running”
상태
4. “scaleDownThreshold” 값인 30% 보다 적으
므로 “scaleDownAdjustment” 값인 1만큼
runner를 줄임
예시)

21. Pull-Driven Scaling - PercentageRunnersBusy
장점
1. TotalNumberOfQueuedAndInProgressWorkflowRuns 메트릭과
동일하게 “지정된 repo로만 제한 기능”을 (화이트리스팅) 지원합니다.
2. 뿐만 아니라, organization 단위로 GitHub 조직 전체의 확장을 지원
해서 특히 대규모로 작업하는 팀에 유용합니다.
3. 러너 카운트를 확장하기 위한 구성 방식으로 백분율 증가/감소 기준과
고정 증가/감소 카운트 기준 모두 지원
단점
1. 충분히 빠르게 확장되지 않을 수 있습니다. 이 메트릭은 풀 기반으로 동
작하므로 interval 주기에 따라 설정된 러너 수를 폴링하므로, 결과적으
로 확장 성능은 이 interval 주기에 한정되어 스케일링에 지연이 발생
할 수 있습니다.
2. 실제 Pending 중인 작업 수에 대한 카운트가 아닌 여러 필드값을 기반
으로 확장,축소를 수행하므로 원하는 러너 수가 실제 워크플로 큐 길이
에 비해 새 러너를 오버 프로비저닝하거나 언더 프로비저닝할 가능성
이 있으며, 이것이 문제가 될 수도 있습니다.

22. Webhook-Driven Scaling
• Web hook driven 방식의 가장 큰 장점은 스케일링
이 필요하다는 사실을 즉시 ARC에 알린다는 점입니
다.
• work
fl
ows 이벤트가 수신되면 각 러너를 더하거나
빼는 형식으로 스케일링 됩니다.
1. Github는 status가 ‘queued’ 로 work
fl
ow_job 이벤
트를 ARC로 전달합니다.
2. HRA는 capacityReservation 목록에 “현재 시간 +
duration” 시간에 만료되도록 예약을 추가합니다.
A. 실행 중인 runner가 maxReplicas보다 적은 경우,
HRA는 capacityReservation 목록에서 예약을
꺼내 runner를 추가합니다.
B. 실행 중인 runner가 maxReplicas에 도달한 경우,
work
fl
ow_job이 ‘completed’되었다는 이벤트를
받고 capacityReservation 목록에서 가장 오랫
동안 존재한 예약을 꺼내 runner를 추가합니다.
예시)

23. Webhook Driven 방식을 채택했습니다.
Duration 값만 잘 정하면 단점이 없어보였습니다. droneCI에서도 같은 방식을 사용하기도 했구요.

24. PoC, 테스트 단계까진 수월했습니다 ..
“그 공지”를 발견하기 전까진 …

25. 평화롭던 ARC에서 발견한 공지 한 통 📮

26. Runner Scale Sets 모드?
평화롭게 ARC 설치 카드를 DONE으로 넘기고, 다른 업무를 처리하던 도중,
ARC에 추가하고 싶은 issues가 있어 discussions을 탐방하는데,
다음과 같은 따끈따끈한 공지를 발견합니다.

27. 작년 12월 즈음 예고가 있긴 했습니다.
Moving to a new home! 이라는 공지와 함께,
ARC 프로젝트가 완전한 Github 프로젝트로 이관됨을 발표했습니다.
그 첫 시작이 새로운 스케일링 모드 였구요.

28. 왜 큰일인가?
• 먼저, 기존의 ARC는 Github 공식 지원&관리 대상이 아니였습니다.
• Github가 공식적으로 ARC에 대해 새로운 아키텍처를 들고 나왔습니다.
• 새로운 아키텍처란:
• K8s CRD API가 완전히 바뀌었습니다. ( actions.summerwind.net/v1alpha1 -> apis/actions.github.com/v1alpha1 )
• Helm chart가 완전히 바뀌었습니다.
• 앞서 설명한 스케일링 방식이 Runner Sets 라는 모드로 통합되었습니다.
• Runner pod 이미지도 바뀌었습니다.
• 공식 문서도 완전히 바뀌었습니다. (Runner Sets 모드 위주)
• Github의 공식 지원으로 커뮤니티 드라이븐 소스는 deprecated될 가능성이 큽니다.

29. 다시 설치 … 해야겠지?
Github이 관리해서 더 안정적일 것이고, 기존 아키텍처의 여러 단점을 보완했기에 그대로 두면 기술부채행

30. Actions Runner Controller
(ARC)
season 2

31. Actions Runner Controller!

32. 복잡하니까… 천천히 하나씩…
우린 이해할 수 있습니다.

33. 우선 helm으로 ARC 설치부터 (데자뷰?)
controller-manager를 chart를 참고해 helm을 통해 배포해야
합니다.
runner-scale-set이라는 CRD도 helm으로 설치해줘야 합니
다. (이전의 RunnerDeployment와 비슷한 친구)
설치가 완료되었다면, Github API로 인증하기 위해 Github
App을 등록해야 합니다. (문서 참고)

34. 그럼 여기까지 한 거에요.
helm으로 설치 완료!
Github API 인증
Github Actions 서버와 https long-poll 연결
Runner Listener 만들기 위해
API 호출 한번 더
짜잔!

35. ci를 작성하고 트리거 하면?
`runs-on` self-hosted로 설정 후 트리거
트리거 메시지를 받고 배치 여부 가능 확인
Api server 요청을 보내 desired
replicas count 업데이트
컨트롤러가 pod 생성 시도

36. Runner pod가 생성되고 시작되는 워크플로
컨트롤러가 runner pod 생성,
단시간 만료되는 임시 권한 토큰 할당
Pod가 생성되면 토큰으로 GA 서버와
https long-poll 연결
GA 서버는 승인 후 작업 정보 전달
작업 과정에 대해 GA 서버로 지속적으로 push
작업 완료 후 삭제 가능 확인 후
runner pod 삭제

37. 새로워진 ARC, 뭐가 좋아졌는가?
• 더 이상 필요조건으로 cert-manager가 필요하지 않습니다.
• 이전에는 client가 GitHub server였지만, 이제는
controller-manger pod가 client가 되었기 때문입니다.
• (Pull driven 스케일링 경우) 스케일링 시간이 단축되고
github api 속도 제한 문제가 발생하지 않습니다.
• GitHub app token이 더 이상 Pod로 전달되지 않아 보안성
이 우수합니다.
• 알 수 없는 오류에 대해 디버깅하기 훨씬 좋아졌습니다.

38. 하지만, 완전히 안정적이진 않을 수 있습니다.
Github 운영&관리 이지만, 여러 버그나 부족한 점이 있을 수 있습니다. 지속적으로 이슈와 토론에 관심을 가져야 운영할 수 있습니다.

39. Github Actions 사내 베타 출시! 🎉

40. PoC, 테스트와 가이드 문서 작성 후 베타 오픈

41. CI 모니터링 대시보드는 DataDog으로
• CI 도구의 지속적인 관리가 없으면 장애 대응시 핫픽스 배포
& DX에 치명적인 결함을 줄 수 있습니다.
• 따라서 파이프라인,잡 성공률과 실행시간 &
• 실패 비율과 실패율 높은 job 필터링 등등 모니터링과 SLO
관리가 필요합니다.
• Prometheus-grafana 등의 모니터링 구축을 고민했지만
• Datadog - Github Integrations이 워낙 강력해서 매우 쉽
게 대시보드를 구축할 수 있었습니다.

42. 킹짱 Dog - 대시보드

43. 킹짱 Dog - 파이프라인 살펴보기

44. 킹짱 Dog - 에러 트레이싱

45. DataDog (멍뭉이) 잘 쓰기!
• 그 외에도 간편하게 Github Actions에서 synthetics 테스트를 구현, 대시보드
를 구축할 수도 있고
• Ci test에서 코드 커버리지 수집&관리, flaky test 관리, E2E test visibility 관리
등
• Intelligent Test Runner (특정 커밋에 대해 영향을 받는 테스트만 실행, 나머
지는 스킵)
• 빌드 이벤트&로그 수집으로 문제 원인의 빠른 파악 …
• CI 뿐만 아니라 전체적인 기능에 대해 “DataDog 잘쓰기” 에 관심이 많습니다.
• 비용만 아니면 …

46. 끝-!
항상 마무리는 어렵네요. 무슨 말로 끝내는 게 좋을까요.
46

47. (공포의) Q&A