[2-3] 배포를 시작하기 전에 반드시 알아야 할 것들

📗 관리 방식 및 운영 정책

 

• 각각 역할을 구성하는 관리 담담자가 다를 수 있음
• -> 프로젝트가 시작될 때 기능 요구 사항들만 있는 상태에서 담당자들이 먼저 정해지고 기능을 만들어가기 때문
• 관리 담당자별로 구성을 나누는게 업무 분담 측면이나 관리 책임적인 면에서 효율적

 

• 배포는 ArgoCD를 사용
• 배포와 인프라 관계를 일대다 or 일대일로 구축할 수 있음(후자 방식을 더 많이 사용)
• 일대일 방식은 ArgoCD를 이중 관리해야 하지만 개발환경에 문제가 생겨도 운영 환경에는 영향이 없음

관리 편의를 중시할거냐 vs 장애 영향도를 중시할거냐

 

• 관리 편의를 중시하더라도 장애가 나도 된다는 아님..
• -> 새로운 배포를 못할 뿐 현재 서비스에 문저가 되는 건 아니기 때문이다
• -> 안전을 중시하기 위한 비용이 만만치 않음

 

 

---

 

 

📕 CI/CD 제품 선정 기준

1. 온라인, 오프라인

• 온라인은 인터넷 환경에 연결해서 쓰기에  CI/CD 서버를 별도로 만들 필요가 없음
• GitHub와 같은 글로벌 제품들은 보안이 잘 되어 있어 기업에서 사용해도 문제 없음
• 기업이라고 무조건 내부의 서버실을 만들어서 서비스를 운영할 필요는 없음
• 금융권, 의료기관, 공공기관은 자사의 시스템이 인터넷 상에 있으면 안됨
• 시스템에 제한이 있는 것이 아니라 데이터가 중요하기에 인터넷 영역으로 데이터를 올리면 안됨

JenkinsX : 컨테이너 환경에 맞춰 새롭게 만들었음
TEKTON : 컨테이너 환경에 최적화된 CI/CD를 목적으로 만들어진 도구

 

 

2. 레퍼런스

 

3. 유지보수 업체

• 회사 내부에 해당 제품을 직접 다루는 사람이 없음 or 유지보수 인원에 비해 엄청 많은 제품들을 사용하고 있는 상태
• 한번 설치한 이후에 관리가 별로 필요 없다면 필요할 때만 전문가를 부르는게 낫다

 

 

---

 

 

🤔 Docker 대체?

• Docker의 단점 : 무겁다,  Daemon이 항상 띄워져 있어야함
• -> 자원을 많이 사용함
• -> BUT, 컨테이너 빌드 속도가 느린건 아니다

Daemon : 리눅스의 백그라운드로 항상 돌아가고 있어야지 실행 가능한 제품
-> 도커 데몬이 죽으면 모든 컨테이너가 같이 다운됨
-> CI/CD에서 컨테이너 빌드용으로만 쓸 때는 큰 문제는 안됨
Daemonless : 명령어 한번 실행하고 끝

 

buildah

• 데몬리스앱
• RedHat에서 밀고 있는 구성
• OpenShift와 관은 관리형 쿠버네티스 제품에 포함되어 있음
• podman과 skopeo를 함께 사용해야 함

podman을 이용해 도커 로그인 및 이미지 pull
skopeo를 통한 이미지 push

 

Kaniko

• 하나만 있으면 돼서 시도해 볼만함

• docker 대세는 끝나지 않았다!

 

 

---

 

 

⭐ 배포 전략

 

Recreate와 RollingUpdate

• Recreate : 먼저 기존 버전 삭제 후 배포
• RollingUpdate : 기존 파드 및 신규 파드 동시 호출 발생
• Deployment만 업데이트 하면 되기에 배포 작업이 간단함
• 에러나면 롤백 가능
• 트래픽 제어는 불가(n분의 1로 골고루 받게 됨)

 

기존 Blue/Green

• L4 연결된 vm2끊고 패치 이후 트래픽 전환
• 이후 vm1에도 패치하고 다시 이중화 시킴

 

쿠버네티스를 활용한 Blue/Green

• 배포 담당자만 새벽에 출근
• 수동 배포시 롤백이 매우 빠름(1초)
• RollingUpdate(3~4분) -> 마음이 초조해짐
• 스크립트를 통한 자동 배포 가능
• V2에 과도한 트래픽 유입시 문제 발생 가능

처음 트래픽이 들어오면 앱 내부적으로 메모리나 DB 커넥션을 최적화시키느라 CPU를 많이 쓰는 경우가 많음
이 시점에 블루그린 배포를 하게 되면 서비스가 바로 뻗어버림
사전에 부하 테스트를 해서 어느 정도 트래픽 상에서 배포를 해도 문제가 없는지 확인해야함

 

개인정보와 같이 운영DB에서만 테스트가 가능한 경우
V2 Deployment만 생성한 후 새로운 Service를 만들어서 V2 버전에 연결
-> QA 담당자는 이 서비스에 붙어서 테스트
-> 문제가 없다면 전환
-> 이런 상황은 블루 그린 배포가 유리

 

 

Canary 배포

• V2 파드에서 새로운 서비스를 생성
• 인그레스 컨트롤러인 Nginx랑 각 서비스에 인그레스 리소스 생성

 

장점

• 인그레스에서 트래픽량을 조절할 수 있게 됨
• 특정 헤더 값에 한해서만 V2로 트래픽 유입 가능
• -> 트래픽을 보내는 주체에 IP로 특정 PC에서만 접속 가능
• -> 유저 정보를 걸어서 특정 사용자만 V2 접속
• -> 사용하는 언어별로 나눔
• 콜드 스타트 방지(10프로만 보내기 때문에 웜업 가능)
• 두 버전 비교 가능

A/B 테스트
배포 전략은 아니고 Canary 배포 상황에서 V1과 V2를 비교하기 위한 테스트 방법론

 

 

배포 순서
1. V2 Deployment, Ingress, Service 한번에 생성
2. V1, V2 Ingress 가중치 변경
3. 일부분만 V2로 유입하여 문제가 없는지 모니터링
4. 이후 V1 Deployment, Ingress, Service 삭제

 

 

 

---

 

 

 

☀️ 단계별로 구축해보는 배포 파이프라인

 

Level 1

• 명령어와 Jenkins UI를 통해 만든다
• 파이프라인을 가장 직관적인 형태로 만들 수 있음
• 툴이나 플러그인 사용들은 지양하고 완성을 목표로 생성

 

Level 2

• Jekins 파이프라인 사용 이유
• -> 시각적인 스테이지 뷰 제공
• -> Jenkinsfile을 릴리즈로 관리 가능(관리 측면에서 매우 유리)
• -> 스크립트 작성이 오래걸림...

 

 Level 3

• kubectl -> kustomize랑 HELM으로 변경
• 단순 파일을 가져오는 게 아니라 패키지를 가져온다고 한다
• 패키지를 사용하면 Yaml 파일을 동적으로 구성 가능

HELM?
일일이 복사를 해서 네임이나 env를 수정하는 것도 귀찮아짐..
name, env 부분에 변수를 넣고 배포
수정 사항이 있을 경우 하나만 수정하면 됨
마찬가지로 시간이 걸리는 작업이라 이전 단계부터 순차적으로 진행 권장

 

 

Level 4

• CI/CD 환경에서는 빌드까지
• 인프라 환경에서 ArgoCD 설치 후 HELM 패키지를 가져와 배포
• -> 릴리즈 파일을 수정하는게 배포 행위가 된다..

 

장점

• 첫 배포 이후 ArgoCD는 Git 허브에 있는 파일과 배포한 Yaml 파일들에 대해 동기화를 시킴
• -> Git Hub 패키지가 수정이 되면 자동으로 k8s 리소스를 변경
• -> 반대로 누군가 k8s 리소스 옵션을 직접 변경하면 Github 내용 업데이트
• k8s 리소르를 편하게 볼 수 있는 UI를 제공해줌
• -> k8s 대시보드보다 편의 기능이 많아 k8s 대시보드 필요가 없을 정도
• -> 블루그린, 카나리 배포 쉽게 쓸 수 있게 기능 제공

 

 

---

출처

[인프런] 쿠버네티스 어나더 클래스 (지상편) - Sprint 1, 2

저자 : 일프로