GitOps란 무엇인가?

GitOps는 Weaveworks에서 처음으로 정의한 용어이며, Git을 활용하여 쿠버네티스 기반의 클라우드 네이티브 환경에서 소프트웨어 애플리케이션 배포하고 인프라를 관리하는 방식이다. GitOps의 관리 방식과, 이점 및 실제로 어떤 방식으로 GitOps를 구성하는지에 대해 알아보자.

 

GitOps는 애플리케이션 코드부터 시작해서 인프라, 네트워킹, CI/CD 파이프라인 등 전체적인 애플리케이션 생태계에 대한 구성들을 모두 Git에 저장하여 관리하는 방식이다. 애플리케이션 코드야 보통 Git으로 관리하지만, 인프라 환경과 네트워킹, CI/CD 파이프라인의 구성 등을 어떻게 Git으로 관리할까? 이런 구성들을 모두 Git으로 관리할 수 있는 이유는 쿠버네티스 때문이다.

 

쿠버네티스는 yaml 파일으로 작성되는 매니페스트 파일로 애플리케이션부터 시작해서 인프라 환경, 네트워킹 룰 등을 모두 yaml 파일로 작성하여 쿠버네티스로 제출하면 쿠버네티스는 자동으로 yaml에 정의한 내용대로 애플리케이션을 배포하고 인프라 환경을 구축한다. 즉, 쿠버네티스에서 제공하는 선언형 방식을 활용하여 GitOps를 할 수 있는데, 반대로 쿠버네티스 환경이 아니라면 GitOps를 채택하는 것은 어렵다. GitOps를 채택하려면 먼저 Git이 필요하며, 선언형 구성방식이 가능해야 하기 때문이다.

 

GitOps의 핵심 원칙

GitOps의 핵심 원칙은 쿠버네티스의 특징인 선언형 방식과 Git의 주요 기능인 버전관리와 PR을 결합하여 클라우드 네이티브 환경을 안전하고 효율적으로 관리하는 것으로 볼 수 있다.

 

선언형 방식

GitOps에서는 쿠버네티스와 같은 선언형 모델을 채택했는데 선언형 모델이라 함은 모든 구성들이 일련의 명령어들로 관리되는 것이 아닌 일련의 사실으로 구성하여 이러한 사실들이 실제 환경에서 보장된다는 의미이다. 쿠버네티스에서는 구성이 매니페스트 파일으로 선언할 수 있는데 매니페스트 파일을 Git으로 저장하여 관리한다고 보면 된다. 매니페스트 파일이 저장된 Git을 쿠버네티스의 단일 진실 공급원 (Single source of truth; SSOT)로 사용할 수 있다.

 

SSOT는 모든 데이터 요소들을 한 곳에서만 관리하도록 하는 관례로 보면 된다. 즉, 쿠버네티스에서 SSOT는 클러스터의 상태는 오직 Git에 저장된 매니페스트 파일로만 보장한다는 의미이다.

버전관리와 불변성

Git과 같은 버전관리 시스템에서 구성파일이 저장되기 때문에 롤백이 단순하다. git revert와 같은 명령어를 사용하여 클러스터가 언제든지 이전 상태로 되돌릴 수 있다. 그리고 버전이 저장되면 가장 좋은 점은 특정 버전은 불변성을 가진다는 의미이다. 즉, 이미 저장된 버전은 변하지 않으며 감사 추적을 설정하는 데 유용하다.

변경사항 승인과 자동 반영

일단 Git에 구성파일이 반영되면 모든 변경사항이 쿠버네티스에 자동으로 적용되도록 하는 것이 GitOps의 원칙이다. 여기서 중요한 점은 쿠버네티스 권한이 없어도 Git 레포지토리 접근만 가능하면 클러스터의 상태를 변경할 수 있다. 이러한 기능은 편리하지만, 클러스터 관리는 혼자 하는 것이 아니기 때문에 변경사항을 아무에게도 알려주지 않고 바로 git에 반영하면 자칫하면 위험할 수 있다. 잘못된 구성이 반영되면 장애로 이어질 수 있기 때문이다. 그래서 이러한 위험을 줄이기 위해서는 개발자끼리의 검토가 필요하다. Git에서는 PR(Pull Request) 기능을 제공하기 때문에 이 기능을 사용하여 변경사항을 상호 검토하여 Humman error에 대한 위험을 줄일 수 있다.

지속적 조정 및 알림

시스템의 상태를 선언하고 버전 관리를 하면 소프트웨어 에이전트는 실제 상태가 원하는 상태와 다를 때마다 사용자에게 알려줄 수 있다. 에이전트를 사용하면 전체 시스템이 자동 복구를 할 수 있다. 그리고 이는 단순히 노드나 파드 장애를 넘어 human error를 수정하는 것까지 포함한다. 이러한 상황에서, 소프트웨어 에이전트가 운영에 대한 피드백과 제어 루프 역할을 한다.

 

GitOps의 주요 이점

GitOps의 핵심 원칙에 의거하여 클라우드 환경을 관리한다면 여러 이점을 얻을 수 있다.

 

1. 생산성 향상 - 통합된 피드백 컨트롤 루프와 함께 GitOps 기반의 CI/CD 파이프라인으로 배포 자동화 방식을 구축한다면 개발자가 쉽게 배포할 수 있기 때문에 개발 생산량을 극대화시킬 수 있다.
2. 개발자 경험 향상 - GitOps를 사용하면 개발자는 쿠버네티스의 내부 작동방식과 여러 기능들을 몰라도 코드를 푸쉬하고 배포 버튼을 누르기만 하면 쿠버네티스로 쉽게 배포할 수 있다. 배포 방식이 쉽기 때문에 새로 합류한 개발자들도 며칠 내에 빠르게 적응할 수 있기 때문에 생산성을 높일 수 있다.
3. 쉬운 감사 추적 - 클러스터를 관리하기 위해 Git 워크플로를 사용한다면 쿠버네티스 외부의 모든 클러스터 변경 사항에 대한 편리한 감사 로그를 자동으로 확보할 수 있다. Git에서 기본적으로 제공해주고 있기 때문이다. 커밋 로그를 보면 되기 때문에 누가 언제 클러스터에 어떤 작업을 수행했는지에 대한 감사 추적이 쉽다.
4. 높은 신뢰성 - Git의 revert / fork 기능을 사용하면 안정적이고 재현 가능한 롤백을 얻을 수 있다. 게다가 전체 시스템이 Git에 설명되어 있으므로 장애 발생 후 복구할 수 있는 단일 소스를 확보할 수 있어 재해 복구가 빠르다.
5. 일관성 및 표준화 - GitOps는 인프라, 앱 및 쿠버네티스 애드온 변경을 위한 단일 모델을 제공하므로 필요한 경우 조직 전체에서 일관된 end-to-end 워크플로를 사용할 수 있다. CI/CD 파이프라인이 PR에 의해 구동될 뿐 아니라 운영 작업 또한 Git을 통해 완벽하게 재현할 수 있다.
6. 강력한 보안 - Git은 변경 사항을 추적하고 관리하는 데 사용되는 강력한 암호화로 뒷받침되는 강력한 정확성과 보안 가드레일을 제공한다. 이는 변경 사항에 서명하여 소유권 및 출처를 증명하고 클러스터의 원하는 상태를 안전하게 정의할 수 있다.
7. 더 빠른 배포 - GitOps 모범사례를 채택함으로써 개발자는 git과 같은 익숙한 도구를 사용하여 쿠버네티스의 업데이트와 기능을 더 빠르게 관리할 수 있다. 지속적으로 기능 업데이트를 추진함으로써 기업은 민첩성을 높이고 고객의 요구에 더 빠르게 대응할 수 있으며 시장에서 경쟁력을 높일 수 있다.
8. 쉬운 클러스터 복제 - Git에 모든 쿠버네티스 클러스터 구성이 저장되어 있기 때문에 클러스터 복제가 쉽다. 쉽게 클러스터 복제가 가능하기 때문에, 리전간 클러스터를 이중화 할 수 있다는 장점이 있다.

 

GitOps 파이프라인 구축

CI/CD 파이프라인에 필요한 모든 작업을 수행할 수 있는 단일 툴은 존재하지 않기 때문에 GitOps는 여러 기능에 적합한 툴을 자유롭게 선택할 수 있다. 여러가지 오픈소스와 상용 툴을 결합해서 GitOps 파이프라인을 구축할 수 있다. 하지만 어떤 도구를 선택하든 GitOps의 핵심 원칙을 지키는 도구를 사용해야 한다.

 

자주 사용하는 도구들

GitOps 파이프라인은 여러가지 컴포넌트로 구성된다. GitOps 파이프라인으로 자주 사용되는 툴은 다음과 같다.

 

파이프라인 구성 방식

GitOps 파이프라인의 구성 방식은 크게는 push 방식과 pull 방식인 2가지로 나뉜다.

 

Push based

Push-based 방식은 먼저 개발자가 코드 변경사항을 git에 푸쉬한 다음, 빌드 파이프라인을 실행하면 변경된 코드를 빌드하고 이미지를 생성하여 이미지 레지스트리에 푸쉬한다. 그 다음, 관련 매니페스트 파일의 이미지 태그를 변경하여 매니페스트 파일이 저장된 레포지토리에 변경사항을 푸쉬한다. 그 다음 git push webhook 등을 이용하여 푸쉬가 발생했을 때 배포 파이프라인을 실행시킨 다음 배포 파이프라인에서 변경된 매니페스트를 쿠버네티스 클러스터에 반영한다.

 

매니페스트 파일이 변경되어 git에 푸쉬하자마자 배포 파이프라인이 실행되기 때문에 Push-based 전략이라고 불린다.

 

Push-based를 지원하는 파이프라인을 구성하려면 Github actions나 Gitlab runner 등을 사용하면 된다. 핵심은 푸쉬 이벤트에 반응해 배포 파이프라인을 실행시킬 수 있는 도구라면 push-based 파이프라인을 구축할 수 있다.

 

Pull based

Pull-based는 Agent-based라고 하며, Push-based와 같이 개발자가 코드 변경사항을 git에 푸쉬한 다음, 빌드 파이프라인을 실행하면 변경된 코드를 빌드하고 이미지를 생성하여 이미지 레지스트리에 푸쉬한다. 그 다음, 관련 매니페스트 파일의 이미지 태그를 변경하여 매니페스트 파일이 저장된 레포지토리에 변경사항을 푸쉬한다. 그러나 실제 쿠버네티스 클러스터에 반영하는 방식이 다르다.

 

Pull-based는 쿠버네티스 클러스터에 있는 GitOps agent가 주기적으로 매니페스트가 저장된 git에 변경사항이 있는지 확인한다. 만약 변경사항이 발생했다면 git에 저장된 상태와 현재 클러스터의 상태를 비교한 후 차이가 있다면 git에 저장된 상태로 클러스터 상태를 변경한다. GitOps agent가 주기적으로 매니페스트 레포지토리를 pull하기 때문에 Pull-based 전략이라고 불린다.

 

Pull-based를 지원하는 파이프라인을 구성하려면 GitOps agent로는 ArgoCD나 Flux 등을 사용하면 된다.

 

참고자료

https://www.weave.works/technologies/gitops/

GitOps what you need to know