ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 세마포어 CI로 Github CI/CD 구축하기 - 1.Intro & CI/CD 툴 비교
    Project/CICD 2022. 5. 25. 00:25
    728x90
    반응형

     

     젠킨스로 시작한 CI/CD 프로젝트는 불가항력적인 이유로 마무리하지 못했다. 다행히 또 CI/CD 구축 업무를 맡게 되어 이번에는 툴 비교부터 시작해보았다 (그때는 돈 주고 할 정도의 중요한 프로젝트는 아니었기 때문에 그냥 젠킨스 + EC2 프리티어를 썼다).

     

     일단 구축 목표는 데이터 엔지니어링 협업 platform을 구축하는 거다 (다른 회사들은 어떻게 구축했는지 궁금.. 혹시 보시는 분들 중 엔지니어 분 계시다면 댓글 달아주세요)

     따라서 Github repository에 merge event가 발생했을 때 변경된 코드가 build, test되고 최종 서버에 배포되는 과정까지를 자동화하는 것이 이번 프로젝트의 목표이다.

     나의 짧은 웹 개발 지식으로 생각했을 때 웹 개발 CI/CD와 특별히 다른 점이 있다면,

    • 웹 개발에서는 배포해야하는 서버가 한 군데이지만 데이터 엔지니어링 파이프라인에서는 여러군데이다 (AWS Lambda, AWS S3, AWS Glue, Airflow server 등등)
    • 웹 개발에서는 배포하는 곳이 서버이지만 데이터 엔지니어링 파이프라인에서는 소프트웨어 일 수 있다. 이럴 경우, 빌드 코드를 따로 작성해야하는 등 빌드 과정에 대한 논의가 필요할 수 있다.
    • 웹 개발에서는 각 코드 파일이 유기적으로 작동하지만 데이터 엔지니어링 레포지토리안의 각 코드는 독립적일 수 있다. 이럴 경우, 배포 시 전체 파일이 아닌 변경된 파일만 인식해서 업데이트 하는 것이 효율적이다.

     예를 들어, github repository에 올린 코드를 AWS Lambda에다 올리는 경우, 올리는 파일은 python 파일일 수 있지만 해당 파일에서 Lambda에서 제공하는 다른 모듈을 사용하거나 gateway를 통해 받은 값들을 전달받아 돌리는 코드가 있을 수 있으므로 CI툴을 통해 빌드 테스트를 할 때는 fail할 수 있다는 점을 고려해야한다. 나와있는 대부분의 자료들이 웹 개발 기준이기 때문에 이 부분들을 어떻게 데이터 엔지니어링에 맞게 효율적으로 적용할 수 있을지 고민 중이다.

     

    CI/CD 툴 비교

    1. Jenkins

     전통적인 강자로 Java기반이다. 실제로 우분투 EC2에 구축했을 때 큰 어려움 없이 설치할 수 있었다. Github webhook과 연동해서 사용하면 되고, build가 fail되었을 때 merge가 안되고 success하면 자동으로 merge 시켜주는 등 다양한 기능들을 제공한다. Plugin도 엄청 많아서 나한테 필요한 게 있는지 검색해서 쓰는게 더 빠를 정도이다. 그리고 전통적인 강자라 한국어 자료가 엄청나게 많다. 단점은 plugin 버전, java 버전 관리를 직접 해줘야하며 서버 관리도 직접 해야한다. 즉 젠킨스 서버 상태 tracking을 위한 슬랙 push 알람이나 이런 설정들이 추가로 필요하다. 일단 Severless를 지향했기때문에 젠킨스는 제외했다 (Bamboo도 동일한 이유로 추가로 알아보지 않았다).

     

    2. AWS Codepipeline

     Codecommit + Codebuild + Codedeploy로 이루어진 서비스로 github을 사용하지 않고 codecommit에서 코드 관리를 할 수도 있다. Github이랑 연동하고 싶다면 Codebuild + Codedeploy만 사용하면 되며 각각 이름과 같은 역할을 한다. AWS기반이기때문에 역시 AWS기반의 다른 서비스들과 호환 및 연동이 용이하다. Build나 Deploy 결과 수신 위해서는 lambda함수를 추가로 설정해줘야하는 번거로움이 있기는 하다. 참고로 Github과는 연동이 되지만 Bitbucket과는 연동이 안된다고한다. 해당 파이프라인 관련해서는 브랜디의 블로그 포스팅을 참고하면 좋을 것 같다. 우리도 주로 Lambda 함수를 위한 구축이었기 때문에 해당 파이프라인은 제외했다.

    (비용 문서)

     

    3. Github action vs Semaphore CI

     가장 main으로 비교했던 두 가지 툴이고 큰 차이점이 없다. 속도도 어떤 블로그 자료에서는 github action이 빠르다고 하고 semaphore ci 홈페이지에 가보면 자기들이 더 빠르다고 되어있다.

     결국 Semaphore CI로 선택했던 이유는 다른 팀에서 SemaphoreCI를 이미 사용중이라 계정이 있었고, 계정당 비용을 청구하기 때문이었다. 그렇지 않고 github기반으로 CI/CD를 구축하고자 한다면 비용 비교를 해서 저렴한 쪽으로 가는 것이 좋은 선택일 것 같다.

     

     둘 다 직접 서버관리를 할 필요가 없고, yaml로 파이프라인을 작성하면 자체적으로 VM을 띄워 build테스트를 한 후 배포하는 방식이다. Github action의 장점은 아무래도 github 관련 호환성이 더 좋고 marketplace가 있다는 점이 있고, Semaphore CI는 GUI로 간편하게 설정할 수 있어 set up이 쉽고 뭔가 막히면 service desk에 메일 보내서 물어보면 답장이 바로 온다 (..!!).

     

     사용하면서 알게된 Semaphore CI의 엄청난 단점이 있는데 쓰는 곳이 없는지 자료가 진짜 없다...(한국어로 찾는건 아예 포기함) 하지만 홈페이지에 document가 잘 적혀있어서 참고하면서 꾸역꾸역 나아가고 있는 중이다. 구축하는 중에 느낀건데 Build test 과정을 안 해도 되면 Github webhook + Lambda로만 구축하는 옵션도 생각해봐야할 것 같다. 이 방법이 훨씬 저렴할 수도..

     

    참고하면 좋은 사례들

    728x90
    반응형

    댓글