GitOps의 정의
Weaveworks 에서 처음으로 사용한 용어로 데브옵스를 적용하는 방법 중 하나다. Git을 통해 코드로 인프라와 애플리케이션을 관리하는 방식이다. Git을 소스 제어 시스템으로 사용해서 Git 저장소에 시스템의 원하는 상태(Desired State)를 코드로 정의하고, 원하는 상태가 되도록 클러스터와 애플리케이션의 배포 상태를 비교해서 지속적으로 동기화하는 과정을 자동화한다. 이를 통해 클라우드 네티이브 환경의 애플리케이션에 대한 배포와 운영을 자동화한다.
GitOps의 원칙
- Git을 단일 정보 소스(Single Source of Truth, SSOT)로 활용해 Git 저장소에 저장된 클러스터 설정(매니페스트 파일)을 기준으로 대상 배포 환경(개발, 운영, 스테이징 등)에 배포한다.
※ Git을 통해 관리되기 때문에 버전 관리가 가능해지고, 배포 실패나 필요에 의해 이전 버전으로 복구하는 것이 가능해진다. - 승인된 변경 사항(이미지 변경)을 자동으로 시스템에 적용한다.
- 배포 환경에 대해 원하는 상태를 선언적인 방식으로 코드(매니페스트 파일)에 정의해서 실제 배포 환경에 구성된 상태와 선언된 상태를 비교하고 지속적으로 동기화 한다.
- 배포 실패 시 사용자에게 경고할 수 있어야 한다.
- CI와 CD를 분리해서 구성하여 CI 프로세스에서는 코드의 변경사항 통합과 테스트에 집중하고, CD에서 Git 저장소를 통해 배포 환경의 상태를 관리한다.
GitOps 구현 패턴
① Push 패턴
소스 코드 저장소가 변경되었을 때 전체 CI/CD 파이프라인이 트리거되어 배포까지 진행되는 구조다. 소스 코드가 통합되고 테스트가 끝나면 컨테이너 이미지의 버전을 업데이트한다. 그 다음 빌드 파이프라인의 마지막 단계에서 쿠버네티스 설정 저장소의 매니페스트 파일에 선언된 컨테이너 이미지 버전을 업데이트 하면서 CD 단계로 이어진다. 마지막으로 배포는 kubectl apply 명령과 같이 명령형으로 배포 작업이 이루어진다.
Push 패턴은 권장되지 않는 방법이다. 배포 환경과의 연결에 따라서 배포가 실패하게 될 수도 있는데, 이 때 배포 환경을 선언된 매니페스트 파일과 동기화를 위해서 별도로 양쪽을 모니터링하는 시스템을 직접 구현해야 한다.
② Pull 패턴
배포 대상 환경에 Operator를 구성한 다음 배포 파이프라인을 대신 수행하는 구조다. Operator가 쿠버네티스 설정 저장소의 매니페스트 파일을 기준으로 배포 환경의 상태와 지속적으로 비교하고 차이가 발생하면 쿠버네티스 설정 저장소의 매니페스트 파일을 기준으로 배포 환경을 동기화 시킨다.
Pull Pattern Architecture 1
빌드 파이프라인 단계 마지막에 컨테이너 이미지를 새롭게 빌드하고, 쿠버네티스 설정 저장소의 매니페스트 파일에 선언된 컨테이너 이미지의 버전을 업데이트 하면서 CD 단계로 이어진다. 이 과정은 기존의 Push 방식과 동일하다. 하지만 선언된 상태 값을 기반으로 Operator가 배포 환경과 동기화 하는 방식을 사용하기 때문에 배포 파이프 라인의 구성이 다르다.
Pull Pattern Architecture 2 - (권장)
앞에서 설명한 Pull Pattern 방식은 빌드 파이프라인에서 쿠버네티스 설정 저장소에 직접 접근하여 매니페스트 파일을 수정한다. 그 과정에서 배포 환경에 접근하기 위한 자격증명이 외부로 노출될 우려가 있다. 그래서 컨테이너 이미지 저장소에 변경사항을 감지하고 쿠버네티스 설정 저장소의 매니페스트 파일을 수정하는 작업을 Operator의 Image Updater를 통해 수행할 수 있도록 구성하는 방식이 가장 권장된다.
'CICD' 카테고리의 다른 글
[CICD] CI/ CD의 기본 개요 (0) | 2025.04.07 |
---|