[DevOps] CI (Continuous Integration) 완전 정복

GitHub repository에 관리되는 Microservice의 CI(Continuous Integration)는 아래 관심사와 책임 원칙을 갖는다.

레포지토리의 관심사

실행가능한 상태의 애플리케이션을 생산하기 위해서 필요한 정적인 정보를 보관하고 추적한다.
(소스코드, CI 워크플로우 스크립트, etc)

워크플로우의 관심사

• 소스코드로부터 생산되는 아티팩트가 SOT(Source of Truth) 로 사용될 수 있도록 자동화로 CI를 완수한다.
• 자동화된 테스트 및 각종 검증 결과(pass/fail)를 PR(pull requet)에 제공한다: Gated check-in

아티팩트 생산 책임

• Containerized Application (Image Tag)
  → Saved in ECR repository
• Application Properties (Properties Schema)
  → Saved in SSM ParamterStore (or GitOps chart repository)

 

빌드머신 책임

• CI Workflow 로 선언된 내용의 일을 수행할 수 있도록 컴퓨팅 리소스를 제공한다.
• 격리된 환경으로 탄력적이고 비용 효율적이며 보안상 안전한 환경을 제공한다.
  

 

 

<GitHub Actions과 Runner의 관계와 동작 원리>

1. 각 GitHub Repository는 GitHub Actions 기능 사용 여부를 결정할 수 있다.

  a.기본적으로 활성화된 상태로 생성된다.

  b.Organization 또는 Enterprise 레벨에서 Repository 생성시 적용되는 기본값들을 일괄 제어할 수 있다.

 

2. GitHub Actions 다음 2가지 기능을 제공한다

   a. /.github/workflows : GitHub Actions에서 관리할 Workflow Spec 정의(YAML 파일)

   b. 정의된 Workflow 대로 지정된 Runner의실행 관리, 개별 job/step 별 시스템 로그 수집 및 결과 제공

   c.Workflow: GitHub Repository Event 와 jobs 를 정의

   d.Official-Ref. Understanding GitHub Actions

 

3. Actions과 Runner의 관계

  a. GitHub Actions 는 runs-on 에 정의된 Labels을 모두 포함하는 Runner에만 Job을 부여한다

  b. Runner는 GitHub Actions과 호환되는 Runtime Build Machine Software이다.

  c. GitHub Actions 탭의 Workflows dashboard 다음 2가지 버전이 호환되어 동작한 결과다.
    1) Actions 버전: GitHub에서 관리 (Repository SaaS).  
    2) Runner 버전: Runner software를 Hosting하는 위치에 따라 관리 주체 상이

  d.Runner의 종류
    1) GitHub-hosted Runner: Actions 버전과 함께 GitHub에서 호스팅 및 관리 (Runner SaaS).  
    2 )Self-hosted Runner: 사용자의 Computing machine에서 호스팅 및 Runner 버전을 포함한 사용자 관리

  e. 참조: Differences between GitHub-hosted and self-hosted runners

 

Github-hosted runner (자동 신규 Runner 제공)와 Self-hosted runner(runner container 제거/관리 수동 구현) 차이

 

(GitHub-hosted 대비) Self-hosted Runner의 장점과 단점

장점 : Cloud Native 보안

1. AWS 권한 관리 강화 가능
   a. GitHub-hosted Runner에서 AWS 리소스를 접근하려면 반드시 AWS Credentials가 필요하므로
       GitHub 측 Secrets에 암호화 저장되지만, Cloud 외부로 노출된 Credentials에 대한 관리 포인트가 발생한다.
   b. Self-hosted Runner에서는 다음과 같은 방법으로 Credentials 보안 강화 및 운영 효율성을 추구할 수 있다.
        1) Runner에서 사용되는 스크립트의 Credentials 정보를 환경변수로 할당
            → 클라우드 외부로 노출되는 문제점은 제거
             (단, GitHub Actions dashboard에서 노출되지 않도록 주의 필요)
        2)Runner가 실행되는 EC2 Instance에 IAM Role을 부여
           → Credentials 관리포인트 제거 (권장)
2. Private 운영 가능. 
   a. GitHub Actions에 대기중인 job을 Self-hosted runner가 받아오는 폴링(Polling) 방식으로 동작한다.
   b. 따라서 GitHub Actions와 연동되기 위해서는 Outbound Traffic만 필요하다. (Private subnet에서 동작)
3. 추가 비용 절감 고려 가능
   a. Reserved Instance, Saving Plan를 통해서 비용 절감된 Computing과 최적화된 Instance 배치 가능
   b. Spot instance를 통한 비용 절감 극대화 가능

단점 : Runner 관리 필요

GitHub-hosted Runner와 동일하게 Self-hosted Runner를 사용하려면 Runner의 상시 구동이 요구 된다.
구체적으로 다음과 같은 문제를 해결해야 하며, 이는 (GitHub-hosted 대비) 단점에 해당하게 된다.

1. Runner version 관리
   a. GitHub Actions에 호환되는 Runner의 버전이 적용된 Self-hosted Runner 실행 및 상태/버전 관리 필요
2. (Github-hosted Runner 와 같이) 상시 구동 가능하도록 라이프 사이클 관리 필요
   1. 개발 생산성 향상을 위하여 Self-hosted Runner를 다중 구성할 필요가 있음
   2. 언제든 Runner가 (필요시 증감) 실행/동작할 수 있도록 고가용성, 내결함성 적용된 환경 구성 필요
   3. 컴퓨팅 환경 구성 방식에 따라 관리 대상 범위 증가 (EC2, ECS, EKS, Fargate)
   4. 관리포인트 발생은 단점이나, 기업 보안 요구 사항 등을 위한 OS Image 커스터마이징 또한 가능
3. 동일 Runner 반복 사용시 발생될 수 있는 캐싱 문제
   1. GitHub-hosted Runner는 단일 Job이 수행된 이후, 깨끗한 새 Runner가 할당됨
   2. Self-hosted Runner는 Host-Machine의 환경에서 동작하므로 완벽한 캐싱 관리가 어려움

 

단점 극복 방안

1. Containerized Self-hosted Runner 적용
   1. 격리된 컨테이너 환경으로 캐싱에 의한 버그 발생 가능성 제거
   2. 인스턴스 1대 당 Runner 컨테이너를 다수 실행하여 자원 사용률 확대
   3. 컨테이너 관리형 서비스를 선택하여 운영 효율성을 위한 선택 폭 확대 (ECS, EKS, Fargate)
2. Actions-Runner-Contollor 도입
   1. 요소 정의
      1. Self-hosted Runner Container등 필요 요소를 CRD(Custom Resource Definition) 정의
   2. 인증 관리
      1. GitHub Actions API를 사용하기 위한 인증 정보를 Runner Container 배포에 주입
      2. 단, Actions-Runner-Controller에 주입되는 Access-Token에 대한 암호 적용 및 관리 필요
      3. Runner 타입 선택 지원: Repository / Organization / Enterprise 를 위한 Runner 설정 지원
   3. 수명 관리
      1. GitHub-hosted Runner 와 같이, 단일 Job이 끝나면 Pod를 재실행하도록 관리
      2. 단일 Job이 끝나면 Pod을 제거하고 동일한 이름으로 재실행하도록 수명 관리
   4. 자원 관리
      1. cpu/mem에 대한 Request/Limit 방식으로 Runner Pod에 할당되는 자원 최적화 가능
      2. HRA(Horizontal Runner Autoscaler)
         1. replica 최소값을 0개로 설정하여 비용 절감 극대화
         2. replica 최대값을 설정 가능
         3. replica 개수 증가에 대한 이벤트 규칙 지정 가능
      3. 전용 자원 격리: Node-Selector/Taint/Toleration 지원

 

Actions Runner Controller에 의해 관리는 Self-hosted Runner Pod Container와 Github Actions Workflow 간의 동작 메커니즘

 

Self-hosted Runner Chart

핵심 원리

오픈 소스로 구성된 Helm chart를 이용해서 간편 설치 및 관리

1. Actions-Runner-Contollor 도입 후 ArgoCD 를 통한 컨테이너 배포 관리
   1. 버전 관리: ArgoCD를 통한 Public registry version tracing으로 신규 Runner Version 대응 (자동화 가능)
   2. 차트 관리: 반복적인 actions-runner 컨테이너 유지관리를 차트를 선언하여 손쉽게 관리
2. Self-hosted Runner Chart 내 적용된 CI 현대화
   1. 환경 항상성
      1. Self-hosted Runner Container는 단일 Job 수행 후 해당 컨테이너는 종료
      2. RunnerDeployment에 의해 동일한 이름의 컨테이너가 재생성되어 GitHub에 재인증 및 Idle 상태로 등록
      3. Job에 사용되는 컨테이너가 자동 교체되므로 완전히 깨끗한 환경으로 빌드 수행을 보장
   2. 탄력성
      1. CI 작업을 수행하는 빌드머신에 병목이 생기면, 테스트, 검증, 출시가 모두 지연되므로 개발 생산성 저해
      2. 필요한 만큼 빌드머신의 개수를 늘리거나 줄일 수 있도록 탄력적인 병렬 빌드 환경 구성 보장 (CI 가속화)
   3. 관리 효율성
      1. 단일 관리 지점
         1. chart내 values 파일로 빌드 머신을 선언적으로 관리 (등록시 생성, 삭제시 제거)
         2. actions-runner 의 버전을 갱신한 오픈 소스의 이미지를 추적하므로 관리 포인트 축소
      2. 아래 2가지 유형으로 빌드 머신 등록 관리
         1. 유형1: 각각의 MSA 서비스가 다른 서비스 혹은 조직의 빌드 작업에 구애받지 않도록 전용 빌드 머신을 등록
         2. 유형2: Enterprise(회사) 혹은 Organization(조직) 에서 모두 공통으로 사용하는 머신으로 등록하여 공유
         3. (참고) PoC는 Organization 권한 없이 유형1을 적용 - templates
   4. 비용 효율성
      1. CI 작업 개수와 같은 metric 정보를 토대로 탄력성을 가진 유휴 상태의 컨테이너를 축소하여 비용 절감
      2. 필요한 시점에 필요한 만큼 생성/종작/제거하므로 GitHub Actions Runner와 거의 동일하게 동작
   5. 향상된 보안
      1. EKS IRSA를 이용하여 Build Container가 사용하는 AWS 리소스에 대한 권한을 부여하면 다음 장점을 가짐
      2. 장점1: IAM 권한 관리포인트 제거
         1. AWS Credentials를 발급 및 GitHub Secrets 등록하는 과정
         2. 유효 기간에 따른 재발급 및 재등록 과정과 Human 에러 등의 반복 과정
         3. (참고) AWS Credentials은 본래 사용자가 사용할 것을 고려해서 구상된 보안 인증 체계입니다.
      3. 장점2: Federation을 통한 컨테이너 전용 권한 강화
         1. Credentials가 아닌 EC2 Role로 권한을 부여받는 방식은 머신이 사용할 것을 고려한 보안 인증 체계로, actions-runner 프로세스 외 다른 프로세스 또한 EC2 Role이 가진 권한을 얻을 수 있는 문제가 발생
         2. 해당 클러스터의 해당 컨테이너가 아니면 IAM Role을 수임받을 수 없도록 Federation 구성하여(IRSA), 빌드 컨테이너에 강화된 보안 방식의 권한 할당
         3. (참고) actions-runner-controller/ EKS IRSA를 actions-runner 컨테이너에 적용하기

Self-hosted Runner Chart로 배포된 Containerdhk MSA App Ci/CD 과정

 

 

GitHub-hosted Runner & Self-hosted Runner Chart 비교

 

	GitHub Actions + GitHub-hosted Runner	GitHub Actions + Flexible Self-hosted Runner Chart on EKS
장점	•GitHub Actions와 인증된 Marketplace 플러그인을 통하여 YAML형식으로 간편한 빌드 프로세스 작성 가능 •정규식을 포함한 Branch 기반, Event 기반 개별 정책 정의 가능 •일정 시각마다 반복되는 프로세스 설정 용이 •적용된 워크 플로우에 대한 시각 정보 실시간 제공 (GitHub Actions Workflow)
	Runner 관리 범위 없이 개발 생산성 향상만 집중	•MSA 운영에 사용되는 EKS 기술과 동일한 기술 스택 공유 •Cloud Native 보안, 자원 최적화, 운영 효율화 적용 가능
단점	Workflow 수행 이력 정보 최대 90일까지만 저장
	상당히 비싼 Computing Power 단가로 조직 규모에 따라 관리 포인트와 비용 간 고려 필요	DevOps Engineer 관리 포인트로 Flexible Self-hosted Runner Chart 포함 (운영과 동일한 기술 스택으로 Learning-curve 최소화)
동작 방식	•즉각적인 Job 실행 •GitHub Action Push 지원 •GitHub-hosted Runner Poll 지원	•Job Scanner 및 신규 Runner 배포, Polling 까지 짧은 지연 •Self-hosted Runner Polling만 지원 (Polling 주기에 따라 Job 실행)
Runner 버전 관리	완전 자동화된 Runner	버전 최신 관리 및 자동화를 위해 ArgoCD & Actions-Runner-Contoller Registry 구성필요
호스팅	GitHub 내부에서 상시 Idle (필요시 외부 통신 가능)	Private 망에서 NAT Gateway를 통한 Egress 통신
컴퓨팅		EKS Node Group 구성시 고가용성, 내결함성을 가진 상시 Idle 구현 가능
비용	GitHub EE 기준 매 월50GB. 50,000 mins 무료 이후 (Linux기준) 0.008 $/min	최대 동시에 실행되는 Job 개수에 대한 제한 가능 Runner 할당 자원에 대한 세밀한 설정 가능 최적화된 인스턴스 패밀리로 Node Group 선택 및 개선 가능
	About billing for GitHub Actions	RI/Saving Plan을 통한 할인 추가 가능 Spot Instance를 통한 비용 효율성 극대화 가능
보안	GitHub Secret 혹은 Third Party에 권한을 가진 AWS Credential 등록 필요 (AWS 외부에 Credential 정보가 저장되어야 동작)	EKS Node Role 또는 IRSA 를 적용하여 효율적인 최소 권한 관리 가능 (AWS 외부로 Credentials 노출/관리 포인트 제거)

 

 

 

Notice with references

• Self-hosted runner Best Practice : YouTube & Recommended autoscaling solutions
• DinD runner support in Kubernetes 1.22

1.