Deployment

1. Jenkins란

• 젠킨스란 소프트웨어 개발 시 지속적으로 통합 서비스를 제공하는 (Continuous Integration) 툴 이다.
• 다수의 개발자들이 하나의 프로그램을 개발할 때 버전 충돌을 방지하기 위해 각자 작업한 내용을 '공유 저장소'에 빈번히 업로드하는데, 젠킨스에 의해 지속적 통합을 가능케한다.
• 젠킨스와 같은 CI툴이 등장하기 전에는 일정시간마다 빌드를 실행하는 방식이 일반적이었다. 특히 개발자들이 당일 작성한 소스들의 커밋이 모드 끝난 심야 시간대에 이러한 빌드가 타이머에 의해 집중적으로 진행되었는데, 이를 nightly-build라 한다. 하지만, 젠킨스는 정기적인 빌드에서 한발 나아가 서브버전, Git 과 같은 버전관리시스템과 연동하여 소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동되도록 설정할 수 있다.

젠킨스가 주는 이점

• 프로젝트 표준 컴파일 환경에서의 컴파일 오류 검출
• 테스트 코드 자동 수행
• 정적 코드 분석에 의한 코딩 규약 준수여부 체크
• 프로파일링 툴을 이용한 소스 변경에 따른 성능 변화 감시
• 결합 테스트 환경에 대한 배포작업
• 각종 배치 작업의 간략화 (DB셋업, 환경설정, 배포, 라이브러리 릴리즈 등)
  • 보통 젠킨스 톰캣을 띄우고, 젠킨스 서버에서 스케줄러에 의해 해당 시간대에 배치 파일을 읽어서 실행한다.
• 이 외에도 젠킨스는 500여가지가 넘는 플러그인을 온라인으로 간단히 인스톨 할 수 있는 기능을 제공하고 있으며 파이썬과 같은 스크립트를 이용해 손쉽게 자신에게 필요한 기능을 추가 할 수도 있다.

2. VM 배포 시스템

1. Build Jenkins Server에서
   • [1] github에서 특정 브랜치 or 태그 or 릴리즈를 fetch하고 -> 소스 코드를 가져오고
   • [2] build tool(maven, gradle 등)로 소스파일 빌드하고 -> 실행 파일(war, jar etc)을 생성하고
   • [3] 결과물을 특정 저장소로 배치한다. -> 공유 저장소에 푸시하고 (추후에 롤백시 이 파일로 바로 배포)
2. Target Server에서
   • [5] 타겟서버에서 빌드 [3] 결과물을 갖고온 후
   • [6] 지정된 스크립트로, 실행중인 프로세스 종료 후, 결과물을 start한다. (타겟 서버에 배포하는데 배포 방식에 따라 롤링, 블루그린 배포가 있다.)
   • [7] 새롭게 배포된 버전이 문제 있을 경우 빌드된 결과물을[3] 갖고와 재배포한다.

3. Kubernetes 배포 시스템

1. DockerFile에 작성된 내용을 토대로, 실행 파일 이미지를(컨테이너가 이해할) Docker Registry에 푸시한다.
2. 배포할 Worker Node에서 [1]에서 푸시한 이미지를 가져온 후, 각각의 컨테이너에서 해당 이미지를 실행한다.
3. 쿠버네티스의 리소스를 활용하여 다음과 같은 작업을 추가로 수행한다.
   • Service, Ingress : 배포 후 각각의 파드는 IP 주소가 변경되는데, 외부에서 바라보는 IP 주소를 배포 후에도 변경없이 맞춰준다.
   • Deployment : Rolling, Blue-Green 등 개발자가 선언한 형식으로 무중단 배포를 지원한다.
   • Readness probe : VM 방식보다 배포 시간이 빠르다고 할지라도, 약간의 지연이 있을 수 있는데, 준비되지 않은 컨테이너는 요청을 처리하지 않도록 대기시킨다.
   • Statefulset : 기본적으로 파드는 Stateless하게 구성하는데, 특정 프로그램은 이전 내용을 공유할 필요가 있다. 즉, 이전 내용을 기억해야한다면 Statefulset 리소스에 의해 배포 전 파드의 내용을 배포 후의 파드에도 동일하게 기억한다.

4. 무중단 업데이트 배포 방법

[1] Rolling

• 구버전에서 신버전으로 트래픽을 점진적으로 전환하는 배포방식이다.
• 하나씩 옮기므로 롤백이 수월하지만, 구/신 버전이 동시에 실행되도 괜찮은 환경에서만 사용해야한다.
  

[2] Blue-Green

• 운영중인 구버전과 동일하게 신버전의 인스턴스를 구성한 뒤 로드밸런서를 통해 모든 트래픽을 한번에 신버전 쪽으로 전환하는 방식이다.
• 구버전의 인스턴스가 그대로 남아있어서 좀 더 손쉽게 롤백이 가능하며, 구버전의 환경을 다음 배포에 재사용할 수 있다. 또한 운영환경에 영향을 주지 않고 새 버전 테스트가 가능하다.
• 시스템 자원이 두배로 필요하며, 시스템 환경에 대한 테스트가 전제되어야한다.
  

[3] Canary

• 신버전을 소슈의 유저들에게만 배포를 해보고, 문제가 없는것을 확인해가며 점차 많은 유저들에게 배포하는 기법이다.
• 블루그린 배포와 유사하지만 블루그린처럼 트래픽을 한번에 확 바꾸는 거이 아니라 단계적으로 안전한지 체크하기 때문에, 부정적 영향을 최소화하고 상황에 따라 트래픽 양을 조절하며 롤백할 수 있다.
• 문제 상황을 빠르게 감지할 수 있지만, 네트워크 트래픽을 제어해야 되는 단점이 있다.