📌 작성하게 된 이유?
- 레거시 시스템으로 이루어진 젠킨스 아키텍처 및 CICD 파이프라인을 고도화하여 보다 효율적으로 운영하고자 합니다.
📌 젠킨스란?
젠킨스는 소프트웨어 개발 시 지속적 통합(continuous integration) 서비스를 제공하는오픈소스 서버입니다.
다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 공유 영역에 있는 Git등의 저장소에 빈번히 업로드함으로써 지속적 통합이 가능하도록 만들어 줍니다.
📌 레거시 문제점
👉 01. Infrastructure 관점
✅ Before
젠킨스 인스턴스를 단일로 운영하고 있습니다.
스케쥴 관리 및 빌드를 포함한 모든 Job을 하나의 인스턴스에서 처리하기 때문에, 프로젝트 빌드 중 추가적인 이벤트 발생시 대응하기 어려운 환경입니다.
실제로 빌드 진행중 Cron 이벤트 발생시 서버가 다운되어 요청한 시간에 이벤트가 발생하지 않는 경우가 발생하고 있습니다.
✅ After
현재 인프라를 개선하고자, 기존 Controller는 유지하되, 스케줄링과 job을 컨트롤하고 build 또는 cron을 위한 Agent를 별도로 생성하고자 합니다.
👉 02. CI/CD 파이프라인
✅ Before
Job으로 구성되어 있거나, 파이프라인으로 구축되어 있는 현재 상황에서 새로운 서비스가 요청되면, 동일한 구성으로 3번의 작업이 진행되고 있습니다. ( dev, stage, prod )
- Job 별도의 쉘 스크립트를 실행하는 방식으로 구성되어 있습니다. 내부 변수들이 하드코딩 되어있어, 프로젝트 생성시 하나하나 변수를 재작성해야 합니다. Github 코드 내부에 스크립트가 작성되어 있지 않고, 수동으로 작성된 프로젝트를 복제함으로서 관리하고 있습니다. 이로인해 workspace가 초기화 되면 모든 작업을 잃어버리는 불상사가 발생할 우려가 있습니다. 또한, 별도의 Agent를 이용해서 작업할 경우 agent 마다 해당 스크립트를 일일히 복제해야하는 번거로움이 존재합니다.
- Pipeline 일부 적용되어 있으며, 서비스별 환경변수가 하드코딩 되어 있습니다. 브랜치별로 새로운 파이프라인 작업공간을 할당하고 있어, 서비스가 확장해 나감에 따라 관리의 포인트가 기하급수적으로 늘어나게 됩니다.
✅ After
작은 규모의 서비스를 구축할때는 이러한 구성으로 관리가 용이했지만, 서비스가 확장됨에따라 3n 개 수 만큼의 파이프라인이 만들어져서, 파이프라인을 관리하기가 힘들어집니다.
멀티브랜치 파이프라인으로 구성하여 prod, dev, stag로 구성된 현재 소스코드를 서비스별로 파이프라인을 일원화하여 관리 및 유지보수를 효율적으로 달성하고자 합니다.
📌 Continue...
젠킨스 개선 과정을 시리즈로 작성하여 공유하고자 합니다.
다음은 하나의 젠킨스를 Controller - agent 구조로 개선하는 과정을 포스팅 하겠습니다.
