내용 요약

CI/CD를 바꾸게 된 배경

  • 많은 팀이 젠킨스 하나를 공유하여 사용하고 있었음 > 젠킨스에 부하가 많이 걸렸음
    • 많은 잡을 관리하다보니 빌드 환경 구성 문제나 배치 작업 누락등으로 인한 이슈와 디스크가 꽉 차는 등의 이슈가 발생하곤 했음
  • 그러다가 쿠버네티스를 도입하면서 새로운 CI/CD 툴을 이용한 배포 파이프라인으로의 변경을 고려하게 됨

시행착오

  • Jenkins X, Tekton, Jenkins on Kubernetes 세가지 후보를 고려함
  • Jenkins X > 온프레미스 쿠버네티스 클러스터 보다는 매니지드 클러스터 사용 시 더 권장 되기 때문에 제외
  • Tekton > 젠킨스에서보다 빌드가 비교적 느리고, 리소스를 비교적 많이 사용했기 때문에 제외
  • Jenkins on Kubernetes > 쿠버네티스를 사용하는것의 초기 러닝커브는 있지만 사용하던 젠킨스 설정들을 그대로 사용 가능했기 때문에 해당 툴 선택

개선된 내용

  • 기존에 하나의 젠킨스를 사용하던 것에서 환경 별로 빌드 클러스터를 구성하여 분리된 젠킨스 환경을 구성함
  • 젠킨스 slave agent 들을 필요 시에만 띄우고 사용하지 않을 때는 정리하여 리소스 효율적으로 구성함
  • 기존에 UI 를 통해서 관리하던 설정들을, CasC 코드로써 젠킨스 설정 들을 관리할 수 있었음
    • Plugin, Tool, Security, 추가 Agent 설정 > Yaml 파일로 관리 (Helm 차트)
    • Job 설정 > 잡 생성 Wrapper 클래스

Jenkins on Kubernetes

  • 기존에는 플러그인 설치를 하려면 Jenkins 버전 문제나 젠킨스를 재시작 해줘야 했음 > 툴 변경 이후에는 주기적으로 플러그인 설치나 업데이트 할 수 있게 되었음 (업데이트도 두렵지 않다!)
  • 서버 스케일 업 등 빌드 환경 업데이트를 빠르게 할 수 있게 되었음
  • Job, config 에 들어가야 하는 공통 설정을 강제화 할 수 있었음 (아무래도 사람이 직접 하다보면 누락되는 부분이 있다보니,,)



느낀점

  1. 젠킨스나 잡 설정들을 코드로써 관리할 수 있다는 점과 agent 들을 리소스 효율적으로 운영할 수 있다는 점이 매력적으로 느껴졌고, 쿠버네티스를 사용하고 있다면 도입해볼만한 솔루션인 것 같음 (기회가 된다면 업무에서나 개인적으로 적용해보고 싶음)
  2. 실제로 어떤 점을 고려해서 툴을 선택했고, 어떤 좋은 점이 있었는지 알 수 있어서 좋았음