[DevOps] CICD - Github Actions 알아보기

GitHub Actions라고 하는 것은 구체적으로 어떤 것일까?

 

GitHub Actions는 GitHub에서 코드와 함께 실행되는 기본 CI/CD 툴입니다. 실제로 GitHub 저장소(힌트: GitHub Actions가 있는 곳)에 "Actions"라고 표시된 탭이 있습니다.

[출처] GitHub의 CI/CD 및 자동화 초보자 가이드 제1장|작성자 단군소프트

Github 한국 총판인 단군소프트에서는 위와 같이 Github Actions에 대해서 설명을 시작하고 있습니다.

Microservice-based SaaS Product

GitHub Cloud(또는 GitHub.com)는 Git-Server-Engine를 Public SaaS 로 제공되는 서비스입니다.
Git repository와 organization, user 등 다양한 도메인에 대한 Microservice로 구성되어 있습니다.

Product Type & Version

1. Microsoft 인수 이후, 고가용성/내결함성을 위하여 Azure Cloud 위에서 동작합니다.
2. GitHub Enterprise 는 Business 계약을 통해서 적용되는 Enterprise 전용 Cloud 서비스입니다. 내부망 에서 사설 도메인 사용으로 관리하기 위한 설치형 GitHub Enterprise Server 도 선택 가능합니다.
3. (더 자세한 GitHub Product Type과 Pricing Plan 관계는 이 문서를 참조하세요)

 

Repository part

아래 Git Repo를 위한 의존 서비스에서 발생한 Event를 Webhooks 이나 Workflows 등으로 전달합니다.

1. 개발팀이 소스코드에 대한 형상을 관리하는 Repository는 Git Operation 서비스에 의존합니다.
2. 개별 브랜치를 하나의 브랜치로 합치는 Pull Request는 Pull Requests 서비스에 의존합니다.

 

Actions part

GitHub Actions wofklow 구성 요소 ( https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions#the-components-of-github-actions )

 

 

 

빌드/패키지 등의 일련의 자동화된 과정을 ‘workflow’라 부르며 GitHub Actions 서비스에 의존합니다.

1. Actions Dashboard: 각 Repository에 귀속된 workflows의 상태와 결과를 보여줍니다.
2. Actions Queue: Event를 기준으로 workflow를 동작시키기 위해 workflow queue를 관리합니다.
3. Actions Runner: job을 내려받고(polling) 수행(run)할 runner runtime을 의미합니다.

workflows 파일은 크게 다음과 같이 구성됩니다.

1. 개별 Repository 에 .github/workflows 디렉토리 하위에 YAML 형식으로 보관됩니다.
2. name: 단일 workflow를 Actions Dashboard 에 표시할 이름
3. on: 단일 workflow를 실행하는 기준 (event trigger)
4. jobs: 단일 workflow 안에서 실행할 일의 단위 (개별 job의 의존 관계 설정 가능)
   1. runs-on: 단일 job을 Polling하기 위해 Runner가 보유해야하는 Label 목록
   2. steps: 단일 job 안에서 순서대로 수행할 일의 단위 (복수의 Step을 단일 Step으로 모듈 설정가능)
5. Reference.
   1. GitHub Docs - Using workflows
   2. GitHub Docs - Using jobs

GitHub-hosted Runners vs. Self-hosted Runners

Runner Runtime은 크게 Hosting 위치에 따라 2가지로 구분됩니다.

1. GitHub-hosted Runner: Actions 버전과 함께 GitHub에서 호스팅 및 관리 (Runner SaaS)
2. Self-hosted Runner: 사용자의 Compute machine에서 호스팅 및 사용자 측 관리
3. Reference: GitHub Docs - Differences between GitHub-hosted and self-hosted runners

About self-hosted runners - GitHub Docs

 

 

 

self-hosted Runner 채택시 장/단점

장점 | AWS Cloud Native 보안 적용 가능

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

단점 | Runner Runtime version 관리 포인트 발생

GitHub-hosted Runner와 동일하게 Self-hosted Runner를 사용하려면 Runner의 상시 구동이 요구

구체적으로 다음과 같은 문제를 해결해야 하며, 이는 (GitHub-hosted 대비) 단점에 해당하게 된다.

1. Runner version 관리
   1. 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의 환경에서 동작하므로 완벽한 캐싱 관리가 어려움

 

비교 요약

 

	GitHub Actions +  GitHub-hosted Runner	GitHub Actions +  Self-hosted Runner(on EKS)	AWS CodePipeline + AWS CodeBuild (비교군)
장점	GitHub Actions와 인증된 Marketplace 플러그 + 간편한 YAML형식 빌드 프로세스 정규식을 포함한 Branch 기반, Event 기반 개별 정책 정의 가능 일정 시각마다 반복되는 프로세스 설정 용이 적용된 워크 플로우에 대한 시각 정보 실시간 제공 (GitHub Actions Workflow)		완전관리형 빌드 테스트 도구 Build Script에 대한 자동화 리소스 기반 권한 부여로 보안 강화 컴퓨팅 파워에 대한 선택 옵션 제공
	Runner 관리 범위 없음 (개발 생산성 향상만 집중)	MSA 운영에 사용되는 EKS 기술과 동일한 기술 스택 공유 Cloud Native 보안, 자원 최적화, 운영 효율화 적용 가능
단점	Workflow 수행 이력 정보 최대 90일까지만 저장		GitHub Webhook 연동 과정 공수 소요 멀티 브랜치에 대한 동적 대응을 위하여 APN Solution Trek10 별도 구성 필요 CodeBuild 조합으로 Pipeline 직접 구성
	상당히 비싼 Computing Power 단가로 조직 규모에 따라 관리 포인트와 비용 간 고려 필요	DevOps Engineer 관리 포인트로 Self-hosted Runner Chart 포함 (운영과 동일한 기술 스택)
동작방식	즉각적인 Job 실행 (GitHub Action Push 지원) GitHub-hosted Runner Poll 지원	Polling 주기에 따라 Job 실행 Job Scanner 및 신규 Runner 배포 Polling 까지 짧은 지연	(Serverless)
호스팅 관리	(관리 없음 - Serverless)	Runner가 실행될 컴퓨팅 자원 관리 Runner 등록 프로세스 관리	(관리 없음 - Serverless)
Runner 버전관리	(관리 없음 - 완전 관리형 Runner)	버전 최신 관리 및 자동화를 위한 별도 구성 필요	(기본값 관리없음 - Serverless)
호스팅	GitHub 측 내부망에서 상시 Idle (필요시 외부 통신 가능)	Private 망에서 NAT Gateway를 통한 Egress 통신
컴퓨팅	Azure Cloud 상에서 완전관리	EKS Node Group 구성시 고가용성, 내결함성을 가진 상시 Idle 구현 가능 Webhook-driven Scaling 기능 이용시 한정적으로 zero-to/from Scaling 이용 가능 (비용관리 극대화)
컴퓨팅 비용	GitHub EE 기준 매 월 50,000 mins 무료 초과시 Linux: USD 0.008/1min MacOS: USD 0.080/10mins Windows: USD 0.016/2mins	최대 동시에 실행되는 Job 개수에 대한 제한 가능 Runner 할당 자원에 대한 세밀한 설정 가능 Node Group 선택 및 최적화 개선 가능	프리 티어만 매월 최소 사양 100min 무료 최소 사양 3GB, 2vCPU는(Linux 기준) 0.005 $/min
스토리지 비용	GitHub EE 기준 매 월 50 GB 무료 및 100 GB 전송 초과시 Storage 비용: USD 0.25/GB Egress 비용: USD 0.50/GB GitHub-hosted 한정 내부 전송 비용 무료	Amazon S3, ECR 등 저렴한 대안 옵션 선택 가능
비용 관련 참조	About billing for GitHub Actions About bllling for GitHub Packages Pricing calculator	RI/Saving Plan을 통한 할인 추가 가능 Spot Instance를 통한 비용 효율성 극대화 가능	AWS CodeBuild pricing
보안	GitHub Secret 혹은 Third Party에 권한을 가진 AWS Credential 등록 필요 (AWS 외부에 Credential 정보가 저장되어야 동작)	EKS Node Role 또는 IRSA 를 적용하여 효율적인 최소 권한 관리 가능 (Credentials 발급 없이 AWS 내부에서 권한 제어)	AWS Secrets Manager 와 연동하여 CodeBuild가 해당 암호화 정보를 호출할 수 있는 권한 부여 Source Code에서 CI 프로세스 스크립트를 분리하여 Build Machine에서 일괄 관리 가능

단점 극복 방안 | Self-hosted Runner Cluster as Modernized Builder Platform

GitHub 측에서는 Runner 고가용성을 위해 아래 2가지 방법으로 현대화된 빌더 플랫폼을 사용하도록 권장합니다.

1. Amazon EC2 Instance 나 ECS cluster 같은 Instance/Container Runtime 환경인 경우:
   1. AutoScaling Group과 Launch Template를 이용해서 고가용성과 내결함성 확보
   2. 기민한 확장성을 위해서 바로 Runner 가 설치된 배포 단위를 관리 (AMI 혹은 Runner Container Image로 버전관리)
      1. PAT 기반으로 각 Runner들이 직접 받아가는 polling 방식만 지원하므로 Latency 소폭 발생 가능
   3. 위 시스템을 영속가능한 불변 구조(Immutable Architecture)를 모두 IaC 도구로 관리 (Terraform, etc)
      1. 참조:

         

         GitHub - philips-labs/terraform-aws-github-runner: Terraform module for scalable GitHub action runners on AWS
2. Amazon EKS cluster 와 같은 Kubernetes Runtime 환경인 경우:
   1. Kubernetes 환경에서 배포되는 Runner Pod를 이용하여 고가용성과 내결함성 확보
   2. ARC 도입 및 GitHub App 적용하여 기민함 확보
      1. 참조: actions-runner-controller/actions-runner-controller
      2. Read more:Actions Runner Controller(ARC) on EKS
   3. GitHub Enterprise Server를 내부망에 존재하는 경우, 빌드/배포의 전 과정을 내부망에서 수행 가능

참고 사항

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

 

AWS 환경에서 Self-hosted Runner 운영시 선택 가능한 옵션

 

 

 

Runs on	EC2 Instance	ECS		EKS
on EC2 Node	on Fargate	on Managed Nodegroup	on Fargate
관리 범위	Launch Template & Auto Scaling Group	Launch Template & Auto Scaling Group	(없음 - Serverless)	Launch Template & Auto Scaling Group	(없음 - Serverless)
	OS Image	OS Image		OS Image
	Runner Process	Runner Container Image, ECR		ARC & Runner Chart, Runner Container Image, ECR
자동화 방안	Amazon Linux 2 기반 AMI & LT 관리		(완전 관리형 - Serverless)	EKS Opt. Image 기반 LT 관리	(완전 관리형 - Serverless)
	Auto Scaling Group 기반 EC2 Instance Provisioning	Auto Scaling Group 기반 EC2 Nodes Provisioning		Cluster Autoscaler 혹은 Kapenter 도입
	실행 후 User Data를 통한 Runner 자동 실행	Task 배포		Helm Chart 배포	Fargate Profile 관리 및 Helm Chart 배포
장점	Container Image 관리 불필요	EC2 내 여러 Container 배포로 비용 효율성 확보 Task 정의가 포함된 IaC로 관리 일원화 가능	전용 Node 사용을 통한 환경 무결성 보장	EKS cluster 내 여유 자원 이용시 Helm chart 만 관리 가능	전용 Node 사용을 통한 환경 무결성 보장
단점	EC2 서버 장애 대비 ASG 필요 각 Runner LT 관리를 위해 IaC 학습 요망	ECS 스택 문법 (task)을 익혀야 함	전용 Node 부팅 시간으로 기민성 소폭 저하	EKS 버전 업그레이드 시 CRD 검토 필수	전용 Node 부팅 시간으로 기민성 소폭 저하