빌드배포 자동화 CI/CD

개발자 -> git (형상관리)-> 배포 파이프 라인 ->git merge 승인 -> Jenkins의 pipeline을 호출 -> (두가지 방식)

• VM 배포) .jar 형식의 패키지 파일로 배포 될 VM 서버에 파일을 전송해 변경사항 적용

 

• 컨테이너 배포) build를 통해 생성된.jar 형식의 패키지 파일을 Dokerfile을 통해 어플리케이션 동작을 수행한 컨테이너 이미지 생성 -> 해당 이미지 파일에 버전 정보를 가지는 tag를 달아 Container Image Registy에 Release -> Registry 의 컨테이너 이미지는 yaml 파일을 통해 PaaS 환경에서 POD 형태로 배포

서버구분	VM	PaaS(컨테이너)
배포단위	jar 패키지 파일 단위 배포	컨테이너 이미지 단위 배포
배포절차 (소스 흐름)	1. 개발 요청/접수 2. 개발(git 형상관리) 3.어플리케이션 빌드 4. 배포(deploy) 5.롤백	1. 개발 요청/접수 2. 개발(git 형상관리) 3.어플리케이션 빌드 4.도커(Doker)빌드 5.릴리즈 6. 배포 7.롤백
품질/ 보안 절차	정적분석 보안검수(자동화 제외) 단위테스트(자동화제외) 기능테스트(자동화제외) 성능테스트(자동화제외) 통합테스트(자동화제외) 모니터링/관제	정적분석 보안검수(자동화 제외) 단위테스트 기능테스트 Contract테스트 통합테스트(자동화제외) E2E테스트(자동화제외) 컨테이너 이미지 취약점 스캐닝(자동화제외) 운영/배포 후 사용자 테스트 (자동화제외) 성능테스트(자동화제외) 모니터링/관제
승인절차	코드리뷰 소스 merge 승인	코드리뷰 소스 merge 승인 PaaS 운영배포/롤백 승인

 

One 브랜치 전략 = 하나의 Master브랜치에서 개발환경,테스트환경,운영환경까지 하나의 이미지로 만들어 배포

• Master -> Dev -> Stg ->prod

 

Two 브랜치 전략 =Develop/Master 2개의 브랜치로만 구성한 브랜치 전략

• 개발자 ->Feature 브랜치에 test-> (git)push ->Develop -> Dev

(merge)↘Master -> Stg ->Prod

Three 브랜치 전략 = 개발환경,테스트환경,운영환경 브랜치를 각각 구성해 배포하는 전략으로 많은 레거시 시스템에서 사용하는 브랜치 전략과 유사하다. 

• 개발자 ->Feature 브랜치에 test-> (git)push ->Develop -> Dev

(merge)↘Master -> Stg

(merge)↘Prod -> Prod

배포 기법 = MSA(마이크로서비스아키텍쳐) 는 서비스를 더 작게 만들어 보다 많은 서비스가 존재하고 빠른 개발주기를 위해 더 자주 배포해야한다.

배포기법	롤링 업데이트	블루 그린	카나리
내용	단순하게 한대씩 재 시작 구성이 간단 서버의 제약이 있을 시 사용가능 저 위험 프로젝트 또는 개발환경에서 사용	새로운 버전을 배포 후 새 버전으로 스위칭 코드 변경에 따른 사이드 이펙트 X 운영 환경 또는 무중단 필요시 사용	특정 유저에게 배포 후 이상 없을 시 전체 배포 구현 난이도 높음 소스코드 변경이 많아 영향도 파악이 어려울 때 사용(무중단 가능)
고려사항	base image 가 변경되는 등의 전체 서비스가 동시에 영향을 받는 작업의 경우, 무중단이 아닌 Recreate를 통한 중단 후 재 배포가 필요할 수 있음	Blue/Green 배포를 위한 이중화를 감당할 수 있는 충분한 자원을 확보하는 것이 관건.	Canary 배포 이후 어느 시점에 점진적인 전체 배포로 변경할 것인지에 대한 판단이 필요 동시에 두 개의 서로 다른 버전이 운영될 수 있음 DB 스키마 변경에 따른 배포시 문제 발생 Service mesh 구현에 따른 traffic의 라우팅 서비스가 필요

 

 

Public Cloud 구성

Jenkins 의 Plugin 을 이용해 Multi Cloud 환경을 구성하고 AWS 의 ECR(Elastic Container Registry)에 컨테이너 이미지를 배포하여 EKS(Elastic Kubernetes Service)에 신규 pod 가 배포될 수 있도록 서비스를 구성

 

Private 망의 VM 내에 설치된 Jenkins 에서 aws cli 명령을 통해 ECR 및 helm 이용해 kubernetes object를 배포하는 구조로 구성

AWS API 명령은 public network 에서 인증 통해서 호출 가능, 실제 배포 파일이나 이미지 전송 등의 작업은 전용선(Direct connect) 통하여 통신