컨테이너 인프라 환경에서는 주로 CD를 강조하지만, CI와 CD는 대부분 함께 사용되기 때문에 CI/CD의 개념을 정확히 이해해야한다.
일반적으로 CI는 코드를 커밋하고 빌드했을 때 정상적으로 작동하는지 반복적으로 검증해 애플리케이션의 신뢰성을 높이는 작업이다. CI 과정을 마친 애플리케이션은 신뢰할 수 있는 상태가 된다. CD는 CI 과정에서 생성된 신뢰할 수 있는 애플리케이션을 실제 상용 환경에 자동으로 배포하는것을 의미한다.
애플리케이션을 상용 환경에 배포할 때 고려해야 할 사항이 여러가지 있는데, 이를 CD에 미리 정의하면 실수를 줄이고 실제 적용 시간도 최소화 할 수 있다.
CI/CD를 컨테이너 인프라 관점에서 정리해보자. 개발자가 소스를 커밋(commit) 하고 푸시(push)하면 CI 단계로 들어간다. CI 단계에서는 애플리케이션이 자동 빌드되고 테스트를 거쳐 배포할 수 있는 애플리케이션인지 확인한다. 테스트를 통과하면 신뢰할 수 있는 애플리캐이션으로 간주하고 CD단계로 넘어간다. CD단계에서는 애플리케이션을 컨테이너 이미지를 만들어서 파드,디플로이먼트, 스테이트풀셋 등 다양한 오브젝트 조건에 맞춰 미리 설정한 파일을 통해 배포한다.
젠킨스로 쿠버네티스 운영 환경 개선하기
애플리케이션 배포 영역에 쿠버네티스를 사용하면 개발자는 애플리케이션 개발에만 집중할 수 있게 된다. 기존에는 환경이 다른 곳에 빌드한 애플리케이션을 배포하게 되면 개발자가 개별 환경에 맞춰 매플리케이션 코드를 일일이 수정해야만 했다. 하지만 모든 배포환경을 컨테이너 인프라로 일원화하고, CI/CD 도구를 사용하면 애플리케이션에 맞는 환경을 적용해 자동으로 배포할 수 있다. 그리고 통합 과정에서 만들어진 컨테이너 이미지를 기반으로 쿠버네티스가 존재하는 어떤 환경에서도 일관성이 있는 애플리케이션을 배포할 수 있다.
개발자가 작성한 애플리케이션 코드를 소스코드 저장소에 푸시하면, 쿠버네티스 내부에 설치된 젠킨스는 애플리케이션 코드를 빌드하고 레지스트리에 푸시한 후에 쿠버네티스에서 사용가능한 형태로 배포한다. 젠킨스는 작업내용을 아이템(Item) 단위로 정의하고 조건에 따라 자동으로 작업을 수행해 효율을 높이고 실수를 줄인다.
컨테이너 인프라 환경에서 젠킨스를 사용하는 주된 이유는 애플리케이션을 컨테이너로 만들고 배포하는 과정을 자동화하기 위해서이다. 하지만 자동화 환경은 단순히 젠킨스용 파드만을 배포해서는 만들어지지 않는다. 젠킨스는 컨트롤러와 에이전트 형태로 구성한 다음 배포해야 하며 여기에 필요한 설정을 모두 넣어야한다. 애플리케이션을 배포하기 위한 환경을 하나하나 구성하는것은 매우 복잡하고 번거로운 일이며, 고정된 값이 아니기 때문에 매니페스트로 작성해 그대로 사용할 수가 없다. 구성 환경에 따라 많은 부분을 동적으로 변경해야한다.
동적인 변경 사항을 간편하고 빠르게 적용할 수 있도록 도와주는 도구가 두가지 있다. 하나는 커스터마이즈(Kustomize)이고, 다른 하나는 헬름(Helm)이다.
출처:
"컨테이너 인프라 환경 구축을 위한 쿠버네티스/도커 - 조훈,심근우,문성주 지음/길벗출판사" 책을 기반으로 실습한 내용입니다.
'DevOps > CI|CD' 카테고리의 다른 글
젠킨스 살펴보기 (0) | 2022.06.13 |
---|---|
커스터마이즈로 배포 간편화하기 (MetalLB 구성) (0) | 2022.06.13 |
젠킨스 설치를 위한 간편화 도구 (0) | 2022.06.13 |
통합 및 배포 자동화 (0) | 2022.06.13 |
쿠버네티스에 젠킨스(Jenkins) 설치하기 (2) | 2022.06.13 |