Jenkins vs Github Action 어떤걸 쓰는게 좋을까?

개요

IT-Hermes 프로젝트 개발 과정에서, 배포를 업데이트 하는 과정에 너무 오랜시간이 걸렸습니다.
특히 이번 프로젝트의 경우 주요 서버들이 너무 많았습니다.
프로젝트에 필요한 서버는 다음과 같았습니다.

• 프론트서버(+Nginx를 통한 웹 서버 기능 겸용)
• 백엔드서버(SpringBoot)
• 배치서버(SpringBoot)
• 크롤링서버(Node.js)

문제상황

프로젝트를 하나 할 때는 "에이 몇개 코드 넣는게 그렇게 오래걸리겠어?" 라는 생각으로 했었지만, 서버가 4개 이상 되다보니, 생각보다 배포하는 과정을 위한 비용이 큰 편이었습니다.
따라서 해당 작업을 커밋하는 시점부터 자동화를 시켜 배포하는 과정에서 생산성을 높이는게 좋을거라 판단했습니다.
(솔직히 말하면.. 배포하는 과정이 반복적이라 너무 귀찮고 시간이 오래걸렸습니다.. 개발하는거도 시간이 없는데...)

고민

배포를 자동화를 시켜주는 툴은 많은 편이었습니다. 유명한 툴인 Jenkins나 Bamboo 등도 있고, 최근에(?) 저도 몰랐지만 Github Action도 있어, 여러가지 툴 중 하나를 선택해야 되는 이슈가 있었습니다.

Bamboo

예전에, Bamboo를 쓴 경험이 있었는데, 가장 큰 장점은, Bitbucket, Jira와 같은 아틀라시안에서 만든 툴이라 그런지 호환성에 장점이 있는 것이 큰 장점입니다.
하지만, It-hermes 프로젝트는 Bitbucket가 아닌 github로 하기 때문에, 큰 메리트가 없다고 판단했습니다.

Github Action vs Jenkins

이 두가지 중, 하나를 선택하는거로 고민을 했고,
처리속도와 생산성과 자료가 많은지 등을 검토했습니다.

여러 자료 등을 참고한 결과, 결국 이렇게 2가지 차이가 있는거를 알 수 있었습니다.
참고할 자료의 경우 충분히 저 역시 이해가 되었지만, CI/CD를 구성하는게 쉽고 어려운건 잘 이해가 안갔습니다. 그래서 직접, CI/CD를 둘 다 구성해보고 더 나은걸 하는 선택하는거로 결론을 지었습니다.

Github Action 적용해보기

깃허브 Action을 직접 해보니까, 실제로 CI/CD를 구성하는게 쉬운 편이었습니다.

위의 코드는 CI 시에 코드입니다.

아래의 코드는 CD작업 시 작성한 코드입니다.

Github Action 특징

Github Action의 꽃은 Action이다 라는 말이 있었는데, 괜히 그 말이 있는게 아니었던것 같습니다. 그냥 Action을 쓰고 예제코드에 맞게 custom을 하면 CI/CD를 구축하는게 어렵지 않았기 때문입니다.

Jenkins 적용해보기

Jenkin의 환경설정을 하는 것 역시, 처음엔 쉬울거라 판단 했는데.. 생각보다 오랜시간이 걸렸습니다. Jenkins를 적용시킬 때, 도커 컨테이너 Java버전 문제로 인해 재대로 작동이 안되거나(Jenkins를 설치할 때, Java17용으로 설치를 안한게 문제였습니다.) WebHook 설정 등 생각보다 해야될 작업들이 많았고, 파이프라인을 설정하는 것 역시 쉽지 않았습니다..

Jenkins 특징

우선, CI/CD 작업을 하는게, 생각보다 오래 걸렸습니다...
하지만, 장점이 Jenkins 파이프라인을 한 곳에서 관리할 수 있다는 점과, 세팅하는 것은 어렵지만, UI에서 관리하기에는 Github Action보다 편했습니다.

Github Action vs Jenkins

직접 해보고 느낀점은 처리속도를 보면, Jenkins가 더 빠른 것을 알 수 있습니다.


GithubAction의 경우 약 1분33초의 실행시간이 걸리는 반면,
Jenkins의 경우 성공할 때를 기준으로 약 56초정도의 실행시간이 걸리는 것을 볼 수 있습니다.
즉 처리속도 상으로 약 40%이상 Jenkins가 더 빠른 것을 알 수 있습니다.
이유를 생각해보니까, Action을 외부에서 받아 오는 과정으로 인해 처리속도상에 차이가 있을거라 보여집니다. Jenkins의 경우 빌드를 실행할 때는 이미 내부에 파이프라인을 위한 라이브러리가 저장이 되어있는 것을 가져오기 때문에, 이 과정이 원인이라 생각이 듭니다.

Jenkins를 CD, Github Action을 CI하는거로 결정

처리속도 상으로 아쉬움이 있음에도 CI작업에서 Github Action을 놓치기 아쉬웠던 이유는 Action에서 제공하는 시각화 Action이 맘에 들었기 때문입니다.
PR을 하는 과정에서 테스트코드가 재대로 작동되는지 확인하는 점이, 생각보다 프로젝트에 배포하는 과정에서 런타임 오류와 같은 이슈를 줄이는데 큰 도움이 되었기 때문에, CI작업을 할 때는 Github Action을 적용했습니다.


CD작업을 Jenkins를 도입한 이유는 처리속도 측면에서의 이유도 있지만, 여러 서버들을 public IP로 설정해야 된다는 점이 가장 큰 이유였습니다.
제가 원하는 CI/CD 프로세스는

이런 식으로 public IP 하나를 통해 내부 서버는 private IP로 통신을 하여 Application 서버를 Client에 접근을 막는 것이었습니다.
하지만 Github Action을 프로젝트에 적용 시, 치명적인 보안 이슈가 발생하게 됩니다.
Github Action의 경우, NCP의 환경과 다른 외부 환경이기 때문에, Application 서버의 프로젝트를 자동화 시키기 위해선, 모든 자동화를 위한 서버를 public IP로 설정해야 합니다. 따라서 아래의 그림과 같이 CI/CD가 구성됩니다.

public IP로 모든 IP를 설정할 경우 Application 서버는 Client가 알 수 있게 됩니다. 따라서, Client에 의해 바이러스나 해킹 등의 보안 이슈가 발생할 수 있기 때문에, CD작업은 Jenkins를 적용하는게 좋을거라 판단했습니다.

결론

프로젝트 상황에 따라 툴을 쓰는 것이 좋을거라 생각합니다.
만약 저와 같이 여러 서버를 구성하고 관리를 해야되는 측면에서는 Jenkins를 하는게 처음은 힘들 수 있지만, 기능적으로 제공해주는 것도 많고, 라이브러리나 일부 데이터들을 여러 파이프라인에서 공유할 수 있는 측면에서 장점이 있어, 대규모 시스템엔 Jenkins가 적합하다고 생각이 듭니다.
하지만, 서버가 한대만 있고, 배포를 빠르게 해야 되는 상황이 발생한다면, 저의 경우 Github Action을 쓸 것 같습니다.