배포를 시작하기 전에 반드시 알아야 할 것들
CI/CD 파이프라인을 구성할 때 고려해야 하는 요소
[CI/CD환경]
빌드-> 컨테이너 빌드 -> kubectl , helm으로 배포
Jenkins로 파이프라인을 구축( 빌드-> 컨테이너 빌드 -> 배포)
개발자 빌드 -> DevOps엔지니어 Jenkins 파이프라인 구축
2번이 편한 것처럼 보이지만 수정할 일이 생겼을 때 1번처럼 담당하는 사람에 따라 분리하는 것이 좋다.
1번으로 구성하고 각 과정에 트리거만 걸어놓으면 자동 배포가 된다.
[배포와 인프라 환경 관계]
1:N
Jenkins (소스빌드 컨테이너 빌드) -> ArgoCD를 통해 배포(kubectl, helm)
장점: 관리 편의성 / 단점: 장애시 운영 환경에 영향도 높음
1:1(더 많이 사용)
개발, 운영 환경마다 ArogoCD를 두기
장점: 운영 환경에서 장애 영향 없음 / 단점: 이중 관리에 대한 부담
[CI/CD Tool]
온라인: 깃허브 액션------------------------> 보안 good
오프라인: jenkins , jenkinsX, Tekton------> 공공, 의료, 금융기관은 데이터가 인터넷 영역으로 올라가면 안됨. 그래서 오프라인 툴을 사용한다.
[Docker 대체]
도커 대체 이유: 무겁다, Daemon 필요(리눅스의 background에서 항상 돌아가야 사용 가능하다)
대체제: buildah
podman과 skopeo 함께 사용
배포 전략을 세울 때 고려해야 하는 요소
[Recreate]
v1->v2 하고싶으면 기존 pod 삭제시킨다. 이때 downtime발생한다. 그리고 v2 새로운 파드가 만들어진다.
배포는 Deployment 업데이트 하면 된다. / 에러 롤백 가능,트래픽 제어 불가능
[RollingUpdate]
v1 서비스 진행->v2
동시에 파드가 호출되는 구간있고 v2파드로 전환된다.
배포는 Deployment 업데이트 하면 된다. / 에러 롤백 가능,트래픽 제어 불가능, 서비스 중단 없음
[Bule/Green]
v2 deployment 만든다. label은 v2로 만든다. 서비스 셀렉터는 v1에서 v2로 수정한다. 트래픽이 v2으로만 들어가게 된다.
수동 배포 시 롤백 빠름 / 스크립트를 통해 자동 배포 가능 / v2에 과도한 트래픽 유입시 문제 발생
운영에서만 테스트한다--> blue/green 배포 쓰세요~
[Canary]
배포용으로 새 서비스 만든다. Ingress 컨트롤러인 엔진 X 랑 각 서비스에 Ingress라는 리소스도 만들어 준다.
트래픽 양을 조절할 수 있다.
특정 헤더 값에 한해서만 v2 트래픽 유입
콜드 스타트 방지, 두 버전 비교 가능 (A/B 테스트)
단계별로 구축해보는 배포 파이프라인
Level1: 초반 구성할 때는 간단하고 직관적인 형태로 완성하기
Level2: Jenkins Pipeline 사용
Level3: Kustomize, Helm 배포
쿠버네티스 앱들을 늘리기는 쉬워졌다. 하지만 하나씩 복사해서 네임이나 env를 수정하는 것도 귀찮다
이렇게 동적 구성으로 한다면 조금 더 편해집니다.
출처: [인프런 쿠버네티스 어나더 클래스] 강좌 자료
Level4: ArgoCD 배포 분리
댓글을 작성해보세요.
