일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- jgrp000032 #ocp #
- Node #POD #Container
- lenova #레노버 #노트북
- PODS #POD #pods #pod #파드 #재기동 #롤링재기동 #rolling
- Python #pakage
- OCP
- jmap #jstack
- function #사용자 정의 함수
- Kafka #카프카
- publishnotreadyaddress
- istio #k8s #kubernetes
- EFK
- EKS
- bootstrap #css #CSS
- Swap Memory
- shell #shell script
- dify
- dump #jattach
- DB #mariaDB #SQL
- 네트워크 #NW
- CI #CD #CI/CD
- test #비교
- 오블완
- 티스토리챌린지
- Linux #wc
- lvm #lv #vg #pv
- NameSpace #NS
- Excel #엑셀
- 백준 #10430
- Grid #CSS
- Today
- Total
BEOM_IT
빌드배포 자동화 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(마이크로서비스아키텍쳐) 는 서비스를 더 작게 만들어 보다 많은 서비스가 존재하고 빠른 개발주기를 위해 더 자주 배포해야한다.
배포기법 | 롤링 업데이트 | 블루 그린 | 카나리 |
내용 |
|
|
|
고려사항 | base image 가 변경되는 등의 전체 서비스가 동시에 영향을 받는 작업의 경우, 무중단이 아닌 Recreate를 통한 중단 후 재 배포가 필요할 수 있음 | Blue/Green 배포를 위한 이중화를 감당할 수 있는 충분한 자원을 확보하는 것이 관건. |
|
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) 통하여 통신
'DevOps > Kubernetes' 카테고리의 다른 글
retry (재시작) 설정 (0) | 2023.07.18 |
---|---|
쿠버네티스 컴포넌트 (0) | 2023.07.18 |
Kibana (0) | 2023.07.18 |
Fluentd (0) | 2023.07.18 |
ElasticSearch (0) | 2023.07.18 |