////
Search

5장 - 지속적 통합과 배포 자동화, 젠킨스

Created
2022/09/03 11:25
Tags
4장에서 진행한 과정을 정리하면
1.
깃허브 등의 저장소에 저장해 둔 애플리케이션 소스 코드를 내려받아 도커 컨테이너 이미지로 빌드
2.
빌드한 컨테이너 이미지를 쿠버네티스에서 사용할 수 있도로 레지스트리에 등록
3.
레지스트리에 등록된 이미지를 기반으로 쿠버네티스 오브젝트를 생성
4.
생성한 오브젝트를 외부에서 접속할 수 있도록 서비스 형태로 노출
이런 과정을 파이프파인이라고 함
대부분 IT 작업은 파이프라인을 통해 결과를 만들어 냄
기존에는 사람이 수작업으로 했지만 이제는 도구를 이용해 자동화가 가능
자동화는 크게 지속적 통합(CI, Continuous Integration), 지속적 배포(CD, Continuous Deloyment) 두 가지로 정의

5.1 컨테이너 인프라 환경에서 CI/CD

일반적으로 CI는 코드를 커밋하고 빌드했을 때 정상적으로 작동하는지 반복적으로 검증해 어플리케이션의 신뢰성을 높히는 작업
CI 과정을 마친 어플리케이션은 신뢰할 수 있는 상태가 됨
CI/CD 컨테이너 인프라 관점으로는
소스를 커밋하고 푸시하면 CI 단계로 들어감
CI는 테스트, 빌드 등의 과정을 거침
이후 CD로 넘어가게 됨
CD는 파드, 디플로이먼트, 스테이트풀셋 등 다양한 오브젝트 조건에 맞춰 미리 설정한 파일을 통해 배포

5.1.1 CI/CD 도구 비교

구분
팀시티
깃허브 액션
뱀부
젠킨스
설치 방식
직접 설치
깃허브 연동
직접 설치
직접 설치
연계 기능
보통
보통
부족
매우 많음
가격
무료/유료
무료/유료
유료
무료
기능 추가
보통
매우 다양함
보통
매우 다양함
범용성
보통
매우 큼
보통
매우 큼
정보량
부족함
많음
많음
매우 많음
팀시티
젯브레인즈에서 만든 CI/CD 도구
깃허브 액션
깃허브에서 지원하는 워크플로 기반의 CI/CD 도구
뱀부
아틀라시안에서 만든 CI/CD 도구
젠킨스
오픈소스 CI/CD 도구
원래 이름은 허드슨이었으나 2004년에 변경됨
특정 환경이나 언어에 구애바지 않고 범용적으로 무난하게 사용 가능

5.1.2 젠킨스로 쿠버네티스 운영 환경 개선하기

애플리케이션 배포 영역에 쿠버네티스를 사용하면 개발자는 어플리케이션 개발에만 집중 가능
CI/CD 도구와 컨테이너 이미지를 활용해 어떤 환경에서도 일관성 있는 애플리케이션 배포 가능
개발자가 작성한 애플리케이션 코드를 소스 코드 저장소에 푸시하면 , 쿠버네티스 내부에 설치된 젠킨스는 애플리케이션 코드를 빌드/레지스트리에 푸시/쿠버네티스에 배포를 진행함
젠킨스는 작업 내용을 아이템(Item) 단위로 정의하고 조건에 따라 자동으로 작업을 수행해 효율을 높이고 실수를 줄임
컨테이너 인프라 환경에서 젠킨스를 사용하는 주된 이유는 애플리케이션을 컨테이너로 만들고 배포하는 과정을 자동화하기 위해서임
애플리케이션을 배포하기 위한 환경을 하나하나 구성하는 것은 매우 복잡/번거로운 일이며고정된 값이 아니기 때문에 매니페스트로 작성해 그대로 사용할 수가 없음
동적 변경 사항을 빠르고 간편하게 적용할 수 있도록 도와주는 두가지 도구는 커스터마이즈(kustomize)와 헬름(Helm)임

5.2 젠킨스 설치를 위한 간편화 도구 살펴보기

MetalLB를 구동하는 데 필요한 수많은 오브젝트를 미리 정의된 하나의 매티페스트에 넣고 실행했음
모든 환경에서 단순히 오브젝트를 정의한 대로만 사용한다면 젠킨스나 커스터마이즈, 헬름 등을 알 필요가 없음
하지만 사용자마다 필요한 환경적 요소가 모두 다르므로 이를 요구 사항에 맞게 바꾸어야 함

5.2.1 배포 간편화 도구 비교하기

구분
큐브시티엘
커스터마이즈
헬름
설치 방법
쿠버네티스에 기본 포함
별도 실행 파일 또는 쿠버네티스에 통합
별도 설치
배포 대상
정적인 야믈 파일
커스터마이즈 파일
패키치(차트)
주 용도
오브젝트 관리 및 배포
오브젝트의 가변적 배포
패키지 단위 오브젝트 배포 및 관리
가변적 사용
대응 힘듦(야믈 수정 필요)
간단한 대응 가능
복잡한 대응 가능
기능 복잡도
단순함
보통
복잡함

5.2.2 커스터마이즈로 배포 간편화하기

커스터마이즈를 통한 배포는 kubectl에 구성돼 있는 매니페스트를 고정적으로 이용해야 하는 기존 방식을 유연하게 만듦

커스터마이즈의 작동 원리

kustomize로 MetalLB를 배포하는 과정
커스터마이즈는 야믈 파일에 정의된 값을 사용자가 원하는 값으로 변경 가능
쿠버네티스에서 오브젝트에 대한 수정 사항을 반영하려면 사용자가 직접 야믈 파일을 편집기 프로그램으로 수정해야 함
일반적으로 이런 방식은 큰 문제가 발생하지 않음
하지만 수정해야하는 야믈파일이 매우 많거나 복잡하다면?
매번 일일이 고치는데 많은 노력이 듬
커스터마이즈는 kustomize 명령을 통해서 create 옵션으로 kustomization.yaml 이라는 기본 매니페스트를 만들고 이 파일에 변경해야 하는 값들을 적용함
최종적으로 build 옵션으로 변경할 내용이 적용된 최종 야믈 파일을 저장하거나 변경된 내용이 바로 실행되도록 지정함

5.2.3 헬름으로 배포 간편화하기

커스터마이즈는 사용자가 직접 kustomization.yaml 에 추가하고 최종적으로 필요한 매티페스트를 만들어 배포해야 함
이러한 다소 수동적인 작성 방식이 아닌 선언적으로 필요한 내용를 제공하고 이에 맞게 바로 배포, 커스터마이즈에서 변경할 수 없는 주소할당 영역과 같은 값도 배포시 변경하려면?
헬름을 써야한다!

헬름의 작동 원리

플랫폼
패키지 매니저
저장소
사용 목적
리눅스
yum, apt
배포판 저장소
소프트웨어 의존성 관리
파이썬
pip
pypi.org
파이썬 모듈 의존성 관리
자바
maven
mvnrepository.com
자바 라이브러리 의존성 관리
쿠버네티스
helm
artifacthub.io
쿠버네티스 패키지 관리
패키지 매너지의 역할
패키지 검색 : 설정한 저장소에서 패키지를 검색하는 기능을 제공
패키지 관리 : 저장소에서 패키지 정보를 확인하고, 사용자 시스템에 패키지 설치/삭제/업그레이드/되돌리기 등을 제공
패키지 의존성 관리 : 패키지를 설치할 때 의존하는 소프트웨어를 같이 설치/삭제하는 기능 제공
패키지 보안 관리 : 디지털 인증서와 패키지에 고유하게 발행되는 체크섬이라는 값으로 해당 패키지의 소프트웨어나 의존성이 변조되었는지 검사하는 기능
커스터마이즈를 통해 많은 부분을 환경에 맞춰 변경이 가능하지만, 주소 할당 영역과 같은 정보는 값의 형태가 아니라서 변경이 불가함
이런 경우에는 헬름을 사용하면 주소 할당 영역도 변경이 가능함

기타 헬름의 장점

다수의 오브젝트 배포 야믈은 파일 구분자인 --- 로 묶어 단일 야믈로 작성해 배포 가능
이런 경우 변경 사항을 추적할 때 모든 내용이 한 야믈에 담겨 동시 작업시 충돌 발생
문제 해결을 위해 목적에 맞게 디렉터리를 분리하여 관리
But 디렉터리가 늘어날수록 관리 영역도 늘어남
위와 같은 상황일때 헬름을 사용하면 요구 조건별로 리소스를 편집하거나 변수를 넘겨 처리하는 패키지를 만들 수 있음
다양한 요구 조건을 처리할 수 있는 패키지를 차트라고 함
이를 헬름 저장소에 공개해 여러 사용자와 공유 가능
각 사용자는 공개된 저장소에 등록된 차트를 이용해 애플리케이션을 원하는 형태로 쿠버네티스에 배포 가능

헬름의 전반적 흐름

생산자 영역
생산자가 헬름 명령으로 작업 공간을 생성하면 templates 디렉터리로 애플리케이션 배포에 필요한 여러 야믈 파일과 구성 파일을 작성할 수 있음
이때 tempaltes 디렉터리에서 조견별 분기, 값 전달 등을 처리할 수 있도록 values.yaml에 설정된 키를 사용
아티팩트허브 영역
아티팩트허브 검색을 통해 사용자가 찾고자 하는 애플리케이션 패키지를 검색하면 해당 패키지가 저장된 주소를 확인함
헬름v2 에서는 이러한 차트 저장소를 개인이 아닌 CNCF가 관리했으나 헬름v3가 배포되고 나서는 CNCF가 관리해야 하는 차트가 많아지면서 모든 차트 저장소는 개인 및 단체에서 직접 관리하도록 정책을 변경함
사용자 영역
사용자는 설치하려는 애플리케이션의 차트 저장소 주소를 아티팩트허브에서 얻으면 헬름을 통해 주소를 등록함
헬름을 통해 쿠버네티스에 설치된 애플리케이션 패키지를 릴리스라고 함