Github Actions 괜찮네

개인 프로젝트를 진행하면서 코드 변경 사항을 테스트, 빌드하고 빠르게 배포하고자 간단한 CI/CD 를 구축할 필요가 있었다.

 

파이프라인을 무엇으로 구축해볼까... 하다가 관성적으로 Jenkins 가 먼저 떠올랐는데, 살짝 지루할 것 같기도 했고 개념적으로만 이해하던 Github Actions 을 이번 기회에 직접 써볼까 해서 사용하게 되었다.

 

 

이번에 Github Actions 를 도입하면서 내가 확인해보고 싶었던 것들은 아래 두 가지고

1. Github Acitons workflow 작성 방법의 간결함 (-> 문법이 익숙하지 않은 동료들에게 설명하기 쉬운가)

2. Github Actions 을 통한 파이프라인(workflow) 구축 속도 및 확장성 (-> 파이프라인을 추상적으로 구축하기 쉬운가)

 

이것 외에 성능도 고려하지만 이건 runner 를 직접 배포할 수 있는 것을 확인 했고, 추후 운영 단계에서 필요한 만큼 스케일 아웃 하는데 문제는 없겠다고 생각했다.

 

 

이제부터 내가 Github Actions 를 쓰면서 느낀점을 이야기 해보겠다

 

생각하기 쉽다

일반적인 CI/CD 도구들은 Github 과 동일한 환경에서 동작하지 않기 때문에 보통 첫 번째 스텝으로 Github 에서 파일들을 가져오는 과정을 거친다. 인증, 디렉토리 구조 등등 한번 세팅해두면 크게 신경 안써도 되긴 하지만, 나처럼 새로운 프로젝트에서 빠르게 빌드업하고 싶은 경우 Github Actions 는 이 과정을 손쉽게 구현 가능하다.

 

아래에 추가적으로 설명하겠지만 workflow 구성을 도와주는 다양한 플러그인(action)들이 있다. Github Actions 는 기본적으로 Github 에서 생성된 Context 를 사용할 수 있기 때문에 'checkout' 플러그인을 사용하기만 하면 프로젝트 파일들을 작업 경로에 가져올 수 있고 이 모든 작업이 Github 내에서 정의 가능하기 때문에 과정을 생각하기 쉽다.(파일을 관리하기 쉽다)

 

workflow 는 적당히 작성하기 편리하다

workflow 는 yml 파일로 작성하고 크게 'on' 으로 workflow 트리거를 설정하고 'job'(또 세부 'step' 으로 나뉜다) 으로 실행할 명령을 정의한다. 여기서 job 과 step 을 작성하고 workflow 를 실행하면 Github Actions 페이지에서 UI 로 실행 과정을 보여주는데 이걸 확인해보면 workflow 구조가 얼마나 직관적인지 알 수 있다.

 

workflow 구성에 사용되는 플러그인도 너무 강력하다. docker registry 커넥션을 구축하고 클라우드(VM 혹은 k8s cluster) 에 배포하는 과정을 별도의 스크립트 작성 없이 플러그인(+ 몇 줄의 코드) 만으로 구성이 가능하다.

 

개인적으로 한 가지 아쉬운 점은 yml 로 스크립트를 작성하는 것이 (가끔) 불편하다는 것이다. 대부분의 경우에는 간단한 스크립트를 작성하기에 불편함이 전혀 없지만 스크립트 내부에 분기(조건문, 반복문 등등)를 포함하게 되면 파일이 상당히 지저분해질 수 있다. 이를 위해 custom action 을 정의하고 import 하는 방식으로 어느 정도 해결할 수는 있지만 코드를 작성하다 보면 속도감이 떨어진다는 생각이 들곤 한다.

 

따라서, 지금은 스크립트를 custom action 으로 손쉽게 추출하고, workflow 자동 완성을 도와주는 도구가 있으면 어떨까 하는 생각이 든다(웹에서 제공하는 작성 도구는 살짝 아쉽다...). 사실 이건 helm chart(yml + go) 를 작성하면서도 비슷하게 느낀 것이기도 한데, 지금 상태로도 충분히 쓸만하기도 해서.. 발전시키는데 드는 리소스가 더 비효율적일 것 같다는 생각도 든다.

 

파이프라인 구성이 용이하다

workflow 는 job 단위로 파이프라인을 구축하는데 job 을 명시하는 것만으로 병렬 처리가 가능하고, 순서가 보장되어야 하는 job 또한 손쉽게 설정(needs) 할 수 있다. 병렬 처리의 경우 jenkins 는 별도로 스크립트 내에서 parallel 설정을 해줘야 한다.

 

개인적으로는 병렬 처리를 기본으로 한 Github Actions 이 유용하다고 생각한다. 왜냐하면 순차 처리가 기본이면 병렬 처리하는 코드가 순차적인 코드 내에 작성되는(A - (B, C, D) - E) 반면, 병렬 처리가 기본이면 (A, B, C, D, E) 작업을 아무 순서(정확히 말하면 관리하기 쉬운 순서)로 정의하고 의존하는 작업을 명시해주기만 하면 되기 때문에 작업을 관리하기 보다 효율적이라고 생각하기 때문이다.

 

마무리

프로젝트를 진행하면서 코드 변경 사항을 테스트하고 EC2 에 컨테이너로 배포하는 과정을 도입하는데 Github Actions 을 사용해봤다. 퇴근 후에 개인적인 시간을 내서 진행하는 프로젝트이니 만큼 상대적으로 많은 시간을 쏟지 못하는 상태라 인프라 측면에서 간결하고 직관적인 세팅을 하고자 하는데 Github Actions 은 그 목적을 달성하는데 굉장히 유용한 도구다.

 

Jenkins 인스턴스를 구성하고 파이프라인을 구축하는데 익숙한 덕도 있지만, workflow 문법을 파악하고 Github Actions 에서 제공하는 public runner(스크립트 실행 주체) 를 이용해 파이프라인을 구축하는데 반나절이 안 걸린 만큼 프로젝트 초기에 도입하기에 좋은 기술이라고 생각한다. 또한, 배포가 아니더라도 Github 에서 생성되는 다양한 이벤트를 손쉽게 핸들링할 수 있다는 점을 기억하고 있으면 여러 방면으로 활용 가능하다고 생각한다.

 

어떤 툴을 채택할 때면 일정 수준 이상의 필요성이 수반되어야 한다고 생각하는데, 최근 새로운 기술은 익숙하지 않다는 이유로 너무 낮은 점수를 주는 것은 아닌가 생각했고 이 부분은 반성할 필요가 있다고 생각하기도 했다. (물론 여전히 기간이 넉넉하지 않을 때에는 내가 잘 마무리할 수 있는 기술을 사용함에는 이견이 없다)

 

오랜 기간 사용한 기술에 대한 리뷰가 아닌 기술을 사용한 첫 느낌을 정리한 글이라 다소 틀린 내용이 포함되어 있을 수 있습니다.

혹시라도 내용에 오류가 있거나 더 좋은 방법이 있다면 알려주시면 감사하겠습니다!