이번에 개발 동아리 시리우스 에 들어가게 되었습니다!!! 무야호~~ 백엔드 PO(Project Owner) 역할을 맡았고 처음 맡은 역할은 CI/CD 구축입니다. 이번에 CI/CD를 구축하면서 많은 고민을 했었는데 어떤걸 고민했고 그에 대한 저의 답은 무엇인지 기록하기위해 글을 작성했습니다.
대표적인 CI/CD 툴 🤔
-
깃허브 액션
-
젠킨스
젠킨스와 깃허브액션에 대한 비교는 이미 블로그에 많이 존재하기에 제가 각각 사용해보면서 느낀점을 말씀드리겠습니다.
깃허브 액션
- yml 파일 기반의 workflow를 작성을 하는데 구문이 상대적으로 간단하고 쉬웠습니다.
- 또한 ci/cd용 서버를 따로 설치를 할 필요없고 깃허브 내장 컴퓨터로 실행을 하기에 아키텍쳐도 간단합니다.
- 젠킨스에 비해 늦게 출시가 되어있기에 레퍼런스 자료가 젠킨스에 비해 부족합니다.
- 공개 리포지토리에 대해서는 깃헙 액션에 대해 과금을 부여하지 않습니다.
- 프라이빗 리포지토리에서는 한달에 500MB, 2,000분까지 무료로 사용가능하지만, 그 이상은 밑의 표에 따라 과금이 발생하기에 이점을 유의해야합니다.
젠킨스
- 파이프라인을 통해 CI/CD를 구동을하는데 개인적으로 파이프라인을 작성 할 때 구문이 깃허브 액션에 비해 상대적으로 어려웠습니다.
- 옛날부터 자바 기반의 대표적인 CI/CD 툴로 아직까지 인기가 많고 레퍼런스 자료가 많습니다.
- 젠킨스를 위한 서버를 따로 구축을 해야하기에 아키텍처 및 비용적인 요소를 고려해야 합니다.
- 프리티어 ec2에 도커로 젠킨스, 스프링 컨테이너로 실행하다가 서버가 죽은적이 많습니다 😭😭
어떤 툴을 선택?? 🧐
두구두구두구.... 깃헙 액션..!!! 해당 툴을 선택한 이유는 프리티어 EC2를 사용하기에 비용적인 문제가 컸습니다.
젠킨스를 도입한다면 따로 서버를 구축을 해야하는데 저희는 프리티어 ec2를 사용하기에 성능이 좋진 않습니다. 이전 프로젝트에서 spring과 jenkins를 컨테이너로 실행했을 때 jenkins 파이프라인을 실행하다가 ec2가 죽어버린 상황이있었습니다😭😭
그래서 jenkins는 CI/CD용 서버를 따로 구축을 하는게 맞다고 판단이 들었습니다.
또한 jenkins와 spring이 하나의 인스턴스에 docker compose로 컨테이너로 실행해서 문제가 없다고 해도 무중단 배포에서 비효율성을 보이는데요. Spring 코드를 갱신해서 새로운 버전을 띄울때 인스턴스를 새로 생성한다고해도 이때 jenkins 컨테이너도 다시 띄워지는 비효율성이 존재합니다.
이러한 점으로 인해 깃헙 액션 을 택했습니다.
CI/CD 통합 VS CI/CD 분리 🧐
CI/CD 파이프라인을 구성 할 때 꼭 이렇게 workflow를 구성해야한다라는건 없지만 CI와 CD의 역할에 맞게 구성을 합니다.
CI의 역할
- 테스트 코드 및 빌드 과정에서 문제가 없는 지 확인
- 빌드된 아티펙트를 레지스트리에 저장
CD의 역할
- 레지스트리에 있는 아티팩트를 서버에 가져와서 실행
- 배포에 집중
처음 CI/CD를 공부 할 때 대부분 프로젝트에서 CI에 테스트 코드 실행 및 빌드, CD에서는 다시 빌드를 해서 레지스트리에 아티팩트를 업로드하고 해당 아티팩트를 가져와서 서버에 실행하는 코드를 많이 보았습니다. 그래서 그게 관례거니... 생각하고있었는데 CI/CD를 꼭 분리해야하는가에 집중을했습니다.
CI/CD 통합
CI/CD가 통합했더라도 하나의 파이프라인으로 CI와 CD가 자연스럽게 진행한다고 생각하시면 됩니다.
예를 들자면 pr을 보낼 때 CI 발동, push(merge) 할 때 CD 발동을 많이 구성합니다.
통합했을 때 동작과정은 아래와 같이 생각했습니다.
- feat 브랜치에서 개발을 하고 develop 브랜치로 pr
- 본인이 개발한 브랜치에서 작성한 테스트 코드가 문제가 없는 지 빌드 과정에서 문제가 없는 지 검증하는 pr용 workflow 발동
- develop 브랜치로 push(merge) 했을 때 ci-cd workflow 발동
- feat 브랜치에 문제 없다고 develop 브랜치가 문제없는건 아니고 develop 브랜치로 개발 서버에서 구동하기에 똑같이 테스트 코드 및 빌드를 해서 아티팩트 생성
- 아티팩트를 레지스트리에 업로드
- ec2에 컨테이너로 해당 아티팩트를 구동
CI/CD 분리
CI/CD를 분리한다는것은 각 역할의 명확성 뿐 아니라 복잡하기 때문입니다.
배포전략(블루-그린, 카나리, 롤백 등) 이 존재 할 때 CI와 CD를 분리한다고 합니다. 왜 분리를 하는게 좋을까요??
블루-그린을 예시로 들자면 새로운 버전의 서버를 구동을하고 기존 서버로 향하던 트래픽을 새로운 서버 쪽으로 바꿔야합니다. 이 과정에서 코드 상의 오류가 아닌 네트워크 또는 예상치 못한 오류로 인해 다시 기존 서버로 롤백 등 복잡한 과정이 있습니다. 이를 CI와 CD를 하나로 묶어놓으면 많이 복잡하기에 분리를 합니다. 또한 코드상의 오류가 아니기에 다시 CI를 할 필요가 없는데 workflow를 하나로 구성했기에 CI를 다시 실행하는 비효율성도 존재하겠죠.
<블루-그린 배포 이미지>
그렇다고 CI 자동화가 성공했다고 CD도 자동화를 하지 않습니다. 그 이유는 비즈니스에 직접적인 영향을 줄수도 있고 개발의 최종 단계이기에 많은 승인이 필요합니다. 또한 마케팅 일정, 피크 시간 외 배포 등 비즈니스적 판단이 필요한 경우도 있습니다. 이러한 이유들로 인해 CD는 수동으로 진행을 하는 경우가 많습니다.
분리했을 때 동작과정은 아래와 같이 생각했습니다.
pr까지는 통합 할 때와 같습니다. 하지만 기존의 CI/CD를 하나의 파일로 구동을 했습니다. 아티팩트를 레지스트리에 업로드하는걸 CI 파일, 그 이후를 CD 파일로 구성을 합니다.
