GitOps (1) - GitOps의 원칙과 도구들

※ 아래 이미지의 출처는 이 페이지임을 밝힙니다.

GitOps 는 원칙은 심플하고 구현은 복잡(?)하다. 기본적으로는 Git 에 내가 원하는 인프라/어플리케이션의 최종 상태가 선언적(declarative)으로 코드로 기술된다. 그러면 인간의 개입 없이 기계가 실제 배포 환경을 원하는 값으로 수정해준다. GitOps 가 지금으로서는 쿠버네티스 운영 관리를 위해 많이 논의되고는 있지만 본래 의미로는 쿠버네티스에 한정되지는 않는다.

핵심은 Git을 single source of truth로 둔다. Git을 딜리버리 파이프라인의 중앙에 두고, 개발자는 PR을 보내서 어플리케이션 배포와 k8s 운영 태스크들 처리하도록 한다. k8s와 다른 클라우드 네이티브 기술들의 운영 모델로, 컨테이너 클러스터와 어플리케이션들의 배포, 관리, 모니터링을 통합하여 관리하는 베스트 프랙티스로 AWS에서도 소개하고 있다. Git에 변경이 생기면 인프라에 배포되므로 어플리케이션 및 인프라의 전체 변경/배포 현황을 PR, Code review 할 수 있게 된다. 이 말은 또 한 편 무슨 의미이냐면 모든 자원들이 Immutable 해진다는 것이다. 이 Git의 내용에 의해서만 전체 환경에 변화가 가해지므로 배포 뒤의 변경에서 발생하는 리스크를 최소화하기 위해 전체 환경을 '재생산'할 수 있다.

GitOps의 원칙

GitOps 라는 말을 고안한 weaveworks 에 따르면 GitOps에는 4가지 원칙이 있다.

1. 모든 시스템을 declarative 하게 관리: Declarative 하다는 것은 가이드가 아니라 팩트로 설정이 이루어진다는 것.

2. 전체 시스템의 Desired State 가 Git에서 버전으로 관리됨

3. 승인된 변경은 자동으로 시스템에 반영 -> 배포 과정에서 사람의 개입을 최소화하여 휴먼 에러 등의 가능성을 배제함

4. 소프트웨어 에이전트를 사용해서 정확성 확보 + Git의 코드와 다른 지점이 생기면 경보를 발생시켜 관리해야 함.

어플리케이션 배포와의 통합

아래는 쿠버네티스 환경에서의 GitOps 를 어플리케이션 배포 파이프라인과 함께 고려한 모습에 대한 내용이다.

대부분의 CI/CD 도구들은 푸시 기반이다. 무슨 말이냐면 코드가 CI 시스템을 트리거해서 마지막에는 kubectl 명령어를 쳐서 배포를 하게 된다. 이 과정에서 주로 문제가 되는 게 보안 사고의 위험이다. 손으로 배포를 하든 배포 파이프라인이 배포를 하든 결국 그 배포를 위한 인증 정보가 클러스터 외부에 존재하게 된다. 물론 CI/CD 스크립트와 CLI를 안전하게 하기 위한 여러가지 방법이 있기는 하지만 운영 관리 포인트가 둘로 늘어나서 trust domain 인 클러스터도 관리하고 배포 환경 역시 관리해야 하게 된다.

푸시 기반이 그런 위험이 있다면 풀 기반 배포 파이프라인은 어떻게 동작할까? 여기에서는 '배포', 즉 Continuous Deployment 에 초점을 맞춰서 접근해야 한다. 어플리케이션의 CI 파이프라인은 별도로 독립적으로 존재해야 한다. 그 CI 파이프라인의 동작 결과 최종 빌드 아티팩트로 Image repo 에 컨테이너 이미지가 떨어지게 된다. 그 뒤에 풀 기반의 CD 관점에서는 두 가지 중요 컴포넌트가 등장하게 된다. 하나는 Deployment Automator로, 이미지 레포를 계속해서 모니터링해서 신규 이미지를 확인하는 컴포넌트다. 다른 하나는 Deployment Synchronizer로 클러스터 내에 존재하면서 전체 자원에 대한 상태값을 관리하게 된다. 이 Automator는 이미지 레지스트리의 변화를 감지하여 Config Repo 의 YAML (이미지 태그..)을 업데이트 한다. Synchronizer는 그 Config repo의 변경을 클러스터에 배포해준다.

GitOps에 대한 부정적인 의견들

이렇게 보면 굉장히 뭔가 획기적인 느낌을 준다. 사실 GitOps 는 쿠버네티스 고급 유저들 사이에서 사용되는 배포 방식이다. CRD라든지 Operator 라든지 쿠버네티스 고급 컴포넌트들을 잘 알고 있어야 하기 때문. 2019년 정도부터 도입하는 팀들이 대폭 많아지면서 개선되어야 하는 점에 대한 의견 역시 나오고 있다.

1. 대표적으로는 GitOps 툴들이 GitOps 방식으로 설치되지 않는다는 점이다. 아래에서 이야기 할 대표적인 GitOps 툴인 Flux (v1), Argo 의 설치 가이드를 보면 GitOps에서 표방하고 있는 것처럼 Desired State 를 모두 코드로 정의하지 않고 있다. 손이 개입해야 하는 부분이 어떻게든 있기 마련이지만 아이러니한 부분이기는 하다.

2. 실제로 도입할 때에는 어플리케이션 CI 프로세스들이 병렬로 일어날 때 Config Repo에서 yaml 변경이 같이 발생하게 되므로 Merge conflict가 발생하게 된다. 결국은 Jenkins Groovy 스크립트를 써서 리트라이 로직을 넣었다는 발표도 있었다.

3. 배포에 대한 가시성 확보는 사실상 가장 큰 장애물이 되고 있다. 배포가 됐는지, 실패했다면 왜 그런지 등등을 확인하기 굉장히 어려운 모양새가 됐다. 대규모 환경에서 텍스트 기반으로 모든 것을 일일이 확인해야 하는 것은 고통스럽기는 하지만, 이것보다 더 큰 어려운 점은 트러블 슈팅이다.

GitOps 의 양대 산맥: Flux vs Argo

GitOps 라는 배포 방식이 아직도 굉장히 도입 초기 단계에 있기는 하지만, 현재 k8s를 위한 GitOps 툴 양대 산맥은 Flux와 Argo 이다. 2019년 7월에 Argo Flux 로 힘을 합칠 거라고 하더니 Flux v2에 조금 더 힘을 싣기로 했다고 같은 연도 8월에 발표가 나면서 무산된 모양새다. ArgoCD가 지금 시점 기준으로는 가장 많은 유저 샵을 가진 것으로 보인다. 그렇지만 300개가 넘는 CVE가 나와 있는 상황이라 약간 흠좀무인 상황...

Flux v2는 개인적으로 기대가 많이 된다. 아직 초기 단계이기는 하지만 기존에 GitOps 툴들에 대해 많이 나오고 있었던 불만(?)들을 해결하기 위해 weaveworks에서 칼을 간 것 같다. 설치할 때도 Fluxv2 엔진 배포를 위한 내용을 담은 Git config repo 를 지정(or 생성)하게 해서 manifest를 다 담게 한다. 그리고 배포 현황과 오퍼레이터가 사용하는 자원을 모니터링할 수 있는 Grafana 대시보드도 제공을 시작했다. 대시보드는 정말 맘에 들었다.

참고문헌

https://www.youtube.com/watch?v=0v5bjysXTL8&t=0s
https://thenewstack.io/the-problems-with-gitops-and-how-to-fix-them/
https://thenewstack.io/more-problems-with-gitops-and-how-to-fix-them/
https://blog.container-solutions.com/gitops-limitations?utm_source=twitter_np&utm_medium=text&utm_campaign=blog