Motivation
프로젝트 준비 중 쿠버네티스 환경에서의 CI/CD 파이프라인을 구성 중이었는데 GitOps에 대해서 알게 되었다.
데브옵스는 종종 들어봤지만 GitOps는 처음 들어 관심을 가지게 되었다.
쿠버네티스 환경에서는 GitOps 방식의 CD가 더욱 적합하다고 하여 정확한 개념 이해를 기반으로 해당 이유를 알아내보고자 한다.
GitOps?
DevOps의 실천 방법 중 하나로 애플리케이션의 배포와 운영에 관련된 모든 요소들을 Git에서 관리하는 것을 의미한다. 결국 GitOps는 Kubernetes Manifest 파일을 Git에서 관리하고 배포시 해당 파일을 통해 클러스터에 배포하는 과정을 말한다. Git에 저장된 코드로 시스템의 구성 요소들을 정의하고, 코드를 신뢰할 수 있는 하나의 원천으로 삼고 현재 배포된 상태와 일치시키며 배포를 유지하는 것이다.
예시를 들자면 Git에 저장되어있는 쿠버네티스 YAML 파일은 현재 쿠버네티스 클러스터에 배포된 리소스를 그대로 반영하고 있다는 것이다. 서로 동기화되어있어야 한다.
GitOps의 원칙
1. 모든 시스템은 선언적으로 선언되어야 한다.
가장 많이 사용되는 툴인 Jenkins를 생각해보자.
실제로 작성했던 Jenkinsfile이다. 이를 보면 Stage가 순차적으로 정의되어있고 정해진 순서에 따라 실행이 되는 것을 알 수 있다. 또한 각 단계 안에서 명령어가 적혀있고 적힌 순서대로 실행됨을 알 수 있다. 이는 절차형 코드이다. 절차형 코드는 복잡한 로직을 구현하고, 다양한 시나리오에 따라 다르게 동작할 수 있도록 구성할 수 있다는 장점이 있으나 사용자가 모든 로직을 구현하는 방법을 알고 있어야 한다는 단점이 있다.
선언형 코드는 이와 달리 사용자가 도달해야하는 최종 상태를 명시하면 이를 달성하는 방법은 도구가 알아서 처리한다.
예시로는 쿠버네티스 YAML 파일이다.
해당 코드를 살펴보면 직접적인 명령어나 순서가 없고, 모든 자원의 버전과 동작을 상태로 명시한다. 이러한 상태를 유지하는 것은 시스템의 몫이 된다.
2. 시스템의 상태는 Git의 버전을 따라간다.
이러한 선언형 코드는 Git에 업로드되고, Git에 올려져있는 manifest를 기준으로 시스템에 배포가 진행된다. 만약 시스템을 이전 버전으로 롤백하여 배포하고 싶다면 Git revert 명령어를 사용하면 된다. 이를 가능하게 하기 위해서는 이미 기록된 상태는 변하지 않는 불변성을 지니고 있어야 한다.
3. 승인된 변화는 자동으로 시스템에 적용된다.
manifest는 Git에 등록 후 변화가 생길 때마다 자동으로 변화를 감지하고 시스템에 적용된다. 결국 가장 중요한 것은 manifest를 통해서 시스템의 리소스에 대한 관리가 이루어지고, 시스템과 동기화된다. 시스템의 상태를 알고 싶다면 manifest를 통해서 간단하게 알아낼 수 있어야 한다.
4. 배포에 실패하면 이를 사용자에게 경고해야 함
코드의 변화에 따라 새로운 배포가 진행될 때 만약 실패하게 되면 사용자에게 경고할 수 있는 시스템을 마련해야 한다.
GitOps Repository
GitOps pipeline을 설계할 때에는 Git Repository를 최소 두 개 이상 사용하는 것이 좋다.
1. App Repo : Application 소스코드와 배포를 위한 Manifest 파일(여기서 말하는 배포용 Manifest 파일은 환경에 따라 달라지는 이미지 버전이나 환경 변수 부분을 제외한 공통의 부분을 정의하는 파일이다)
2. 배포 환경 구성용 Repo : 배포 환경에 대한 모든 manifest들이 어떤 버전으로 어떻게 구성되어 있는지 포함
GitOps 배포 전략
Push Type
Git Repository가 변경되었을 때 파이프라인을 실행시키는 구조이다.
배포 환경의 개수에 영향을 받지 않고 Git에 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있다.
그러나 항상 연결되어 있는 상태가 아니기 때문에 실제 배포 작업이 수행되는 시점에 실패할 수도 있다. 배포 환경과 형상이 달라지는 경우 이에 대한 알림을 받을 수 있도록 모니터링을 추가해야 한다. 또한 보안 정보가 외부로 노출될 수 있다는 단점이 있다.
젠킨스가 제공하는 것이 바로 Push Type의 CD이다.
Pull Type
배포 환경에 위치한 별도의 오퍼레이터가 배포 파이프라인을 대신한다. 이 오퍼레이터는 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생한 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지해준다. 풀 타입의 경우 오퍼레이터가 애플리케이션과 동일한 환경에서 동작 중이라 자격 증명 정보가 외부에 노출될 일이 없어 보안성 측면에서 좋다. 이를 제공해주는 기술이 바로 ArgoCD이다.
ArgoCD
GitOps를 구현하기 위한 도구 중 하나로 Kubernetes 애플리케이션의 자동 배포를 위한 오픈소스 도구이다.
쿠버네티스 클러스터에 배포된 애플리케이션의 CI/CD 파이프라인에서 CD 부분을 담당하며 Git 저장소에서 변경 사항을 감지하여 자동으로 쿠버네티스 클러스터에 애플리케이션을 배포 가능하다.
이를 구축하는 과정을 다음 포스팅에서 다뤄보도록 하겠다.
