시작하기 전

회사에서 CI/CD를 위해서 젠킨스를 적극적으로 활용하고 있다. 개인적으로 젠킨스는 여러모로 불편하다고 생각한다. 젠킨스를 깃허브액션으로 모두 대체하고 싶다. 팀원들을 설득하기 위해서는 깃허브 액션에 대한 깊은 이해가 필요하다고 생각했고 공부한 내용을 포스팅으로 남기고자 한다.

깃허브액션 컨셉

깃허브 액션은 깃허브에서 제공하는 CI/CD 플랫폼이다. 따라서, 반드시 깃허브와 사용해야한다. 깃허브 액션이 지향하는 것은 단순히 데브옵스를 넘어서 우리의 프로젝트 레포지토리에서 이벤트가 발생하면 workflow를 수행하는 것이다. workflow 는 깃허브액션의 컴포넌트 중 하나이다. 차근차근 알아보자.

컴포넌트

깃허브 액션을 이루고 있는 컴포넌트들을 살펴봅시다.

Event

깃허브 액션을 실행시키는 트리거이다. 깃허브 액션에서는 workflow 라는 작업 단위를 가지고 있는데, 여러가지 이벤트를 통해서 트리거할 수 있다. 이벤트의 종류로는 pr 생성, issue open, push 등이 있고 크론잡과 같이 배치 작업을 스케쥴링할 수도 있다.

Workflow

가장 큰 작업의 단위이다. 특정 브랜치에 push, pr 등의 이벤트가 발생하면 트리거가 걸려있는 workflow 가 실행된다. workflow 는 하나 이상의 job 을 수행하며 각 workflow 들은 체이닝이 가능하다.

job 들은 체이닝 되어 있지 않으면 병렬적으로 수행된다. 병렬적으로 수행될 수 있는 이유는 job은 각각 독립적인 컨테이너ㅡrunner라고 부른다ㅡ에 의해서 실행되기 때문이다. 글로 설명한 내용을 그림으로 나타내면 아래와 같다.

(출처: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)

Job

Job은 step의 집합이다. 하나의 Job에 속한 step 들은 같은 runnerㅡ컨테이너ㅡ에 의해서 실행된다. step들은 하나의 컨테이너가 실행하는만큼 서로 유기적으로 동작한다. step 간 데이터를 공유할 수도 있고, step 간 의존하며 순서를 정할 수도 있다.

step은 shell script를 실행할 수도 있고 또 다른 action 을 실행할 수도 있다.

Actions

깃허브액션 플랫폼에서 동작하는 커스텀 애플리케이션이다. 쉽게 말하면 깃허브액션 플러그인이라고 표현할 수 있다. 여러 레포지토리에서 반복적으로 사용하는 Job을 Action으로 정의해서 재사용할 수 있다.

Action을 정의하고 사용하는 일은 젠킨스에 비해서 쉬운 편이다. 쉬운 Action 정의 덕분에 AWS, GCP, Azure, Slack 등의 여러 서비스들과 환상적인 시너지를 보여준다. 다음 포스팅에서는 직접 Action 을 정의해보자

Runners

workflow 를 실행하는 호스트이다. 깃허브에서는 기본적으로 우분투, 윈도우, 맥OS의 러너를 제공한다. 깃허브가 제공하는 기본 러너 외의 환경이 필요하다면 self-hosted runner라는 선택지가 있으며 우리가 원하는 환경의 머신을 준비하고, SDK를 설치하고 실행하면 손쉽게 사용할 수 있다.

runner 한번에 하나의 workflow를 수행할 수 있고, 각 workflow는 새로운 컨테이너에서 실행된다.

마치며

다음 포스팅에서는 깃허브 엔터프라이즈 환경에서 self-hosted runner를 운영하는 법에 대해서 포스팅 할 예정이다. 쿠버네티스 기반으로 self-hosted runner를 운영할 생각이고, runner의 컨디션에 따라서 auto-scaling도 가능해야한다. 갈길이 멀다.