이러한 과정을 거쳐서 만들어지는 소프트웨어는 이 과정 사이에 가시성이 필요하다. 그러한 이점을 젠킨스와 같은 CICD 툴이 제공 한다. 어느 시점에 어떤 에러를 통해서 빌드나 테스트가 실패했는지를 추적관리 할수 있으며 , 디버깅에 용이하다.
BUILD - TEST - RELEASE 의 전범위적인 단계에서 젠킨스를 사용하는것이 가능하며 CI/CD 툴을 이용하는 것의 가장 큰 장점은 이러한 일련의 과정들에 대한 가시성과 멱등성을 제공한다는 것이다.
모놀리스 어플리케이션에도 Jenkins를 썼었어요!
CI/CD를 필자는 쿠버네티스와 연동하여 도커 컨테이너 이미지를 빌드하고 private Docker Registry와 연동하고 Kubernetes 클러스터에 배포하는 과정을 위해 CI/CD 툴 (젠킨스)를 사용하지만, 과거에 개발팀에 있을때는 이러한 모놀리스식 어플리케이션을 배포하는데도 젠킨스를 사용했다. 그때 당시에는 git에 코드를 커밋하게 되면, 자동으로 서버에 JAR파일을 drop 해주는 젠킨스 로직을 사용하였었다.
하지만 , 젠킨스에는 어마어마한 숨겨진 장점이 있었던것! 도커와 쿠버네티스를 플러그인으로 컨트롤 할수 있었던 것!
여러가지 플러그인들이 탑재되어 있어서,
메이븐을 통해 빌드해주는 역할 도커를 통해 컨테이너화 해주는 역할, 도커 컨테이너를 이미지 저장소까지 안전하게 push 해주는 역할
그뿐만 아니라, 컨테이너화 하기 전에 젠킨스 파이프라인을 통해 빌드-테스트-릴리즈 부분을 처리할 수 있다. Sonarqube를 통해 정적분석을 할수도 있고, Junit을 통해 유닛test를 젠킨스에서 할수 있다.
서비스가 커질수록 더더욱 중요해집니다!!
마이크로 서비스 (MSA) 는 현재 IT 시장의 큰 골자이다. 모든 MSP 사업자들은 그동안의 모놀리스식 어플리케이션에서 MSA 아키텍쳐로의 전환이 핵심적인 요지이다.
애플리케이션 개발 초기에는 전체 애플리케이션의 소스 코드를 하나의 배포 유닛(war 또는 Jar)으로 내장시키는 '모놀리식' 방식을 이용하였다. 하지만 기존 애플리케이션에 최소한의 변경 사항이 있어도 자체적인 QA(Quality Assurance) 주기에 따라 대규모 업데이트를 해야 하거나 일부 애플리케이션의 업데이트로 오류가 발생한 경우 전체를 오프라인으로 전환하고 문제를 해결하는 등 다운타임이 발생하게 되었다. 그래서 보통 은행이나 게임서버 같은 경우 점검시간(12:00~12:30) 등을 정해놓고 사용자가 가장 적게 접속하는 시간을 이용하여 패치 등을 진행하였다.
이러한 문제점을 해결하기 위해 전통적인 모놀리식(monolithic) 접근 방식과 다르게 애플리케이션을 핵심 기능으로 세분화하여 하는 MicroService(MS)라는 아키텍처 기반의 접근 방식이 탄생하게 되었다. 여기서 각 기능을 서비스라고 부르며, 독립적으로 구축하고 배포할 수 있게 되었다.
즉 도메인의 기능별로 서비스를 세부화 시키고 예를 들어 , 회원가입 서비스 , 예약 서비스, 결제 서비스 등 그러한 서비스들을 컨테이너와 쿠버네티스를 통해 관리하는 아키텍쳐를 그리게 된것이다.
이러한 MSA 구조에서 또한 중요하게 생각되는 것은 CI/CD 개념이다. GIT( CI 툴 ) 에서 코드들을 통합하고 형상관리 하며 젠킨스에서 그 코드들을 가져와서 Docker 플러그인을 통해서 docker file을 빌드한다.
그리고 CD 측면의 단계에서는 Dockerhub나 Harbor 과 같은 Docker Private Registry에 빌드된 도커이미지를 저장하고 Kubernetes를 통해 배포,수정,삭제 등 (라이프사이클 관리) 등을 한다.
