1. GitOps
GitOps 란?
- GitOps는 DevOps의 실천 방법 중 하나로 애플리케이션의 배포와 운영에 관련된 모든 요소들을 Git에서 관리한다는 뜻
- GitOps는 Kubernetes Manifest 파일을 Git에서 관리하고, 배포할때에도 Git에 저장된 Manifest로 클러스터에 배포하는 일련의 과정들을 의미
※ Manifest 파일 : 쿠버네티스의 오브젝트를 생성하기 위한 메타 정보를 YAML이나 JSON으로 기술한 파일
GitOps의 원칙
1) 모든 시스템은 선언적으로 선언되어야 함
“선언적(declarative)”이라 함은 명령들의 집합이 아니라 사실(fact)들의 집합으로 구성이 되었음을 보장한다는 의미입니다.
쿠버네티스의 manifest들은 모두 선언적으로 작성되었고 이를 Git으로 관리한다면 versioning과 같은 Git의 장점과 더불어, SSOT(single source of truth)를 소유하게 됩니다.
2) 시스템의 상태는 Git의 버전을 따라감
Git에 저장된 쿠버네티스 manifest를 기준으로 시스템에 배포되기 때문에 이전 버전의 시스템을 배포하고싶으면 git revert와 같은 명령어를 사용하면 됩니다.
3) 승인된 변화는 자동으로 시스템에 적용됨
한 번 선언된 manifest가 Git에 등록되고 관리되기 시작하면 변화(코드수정 등)가 발생할때마다 자동으로 시스템에 적용되어야 하며, 클러스터에 배포할때마다 자격증명은 필요하지 않아야 합니다.
4) 배포에 실패하면 이를 사용자에게 경고해야 함
시스템 상태가 선언되고 버전 제어 하에 유지되었을 때 배포가 실패하게되면 사용자에게 경고할 수 있는 시스템을 마련해야합니다.
GitOps 저장소 전략
최소 2개 이상의 Git 저장소를 사용하는 것을 권장한다.
- 애플리케이션 저장소: 애플리케이션 소스 코드와 애플리케이션 배포를 위한 배포 매니페스트(예: kubernetes yaml)를 포함한다.
- 배포 환경 구성 저장소: 배포 환경에 대한 모든 매니페스트를 포함한다. 애플리케이션과 인프라 서비스(모니터링, 메시지 브로커 등)가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보가 들어있다.
애플리케이션 배포 매니페스트를 별도의 깃 저장소에 보관해도 되고 템플릿 형태로만 가지고 있다가 배포 시 배포 환경 구성 저장소와 합쳐서 매니페스트를 생성하는 방식으로도 사용이 가능하다.
GitOps 배포 전략
깃옵스는 푸시 타입(Push Type)과 풀 타입(Pull Type), 두 가지의 배포 전략을 가이드 하고 있다. 두 옵션 간의 차이점은 저장소에 있는 매니페스트와 배포 환경의 상태를 일치시키는 방법이다. 무엇을 선택해도 상관없으나 깃옵스는 보안상의 이유로 풀 타입 배포 전략을 권장한다. 각각에 대해 간략히 알아보겠다.
1) 푸시 타입(Push Type)
저장소에 있는 매니페스트가 변경되었을 때 배포 파이프라인을 실행시키는 구조이다. 아키텍처가 단순하여 인기있는 방법이며 젠킨스(Jenkins), 서클CI(CircleCI) 등의 구현에 사용할 수 있는 도구들도 다양하다. 가장 큰 특징으로 배포 환경(Environment)의 개수에 영향을 받지 않는다. 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있다.
그러나 항상 연결되어 있는 상태가 아니기 때문에 실제 배포 작업이 수행되는 시점에 실패할 수도 있다. 그리고 배포 환경이 손상되어 배포 환경 구성 저장소의 내용과 다를 경우 차이를 감지하고 배포 파이프라인을 다시 실행시키거나 알림을 줄 수 있는 별도의 모니터링 시스템이 필요하다.
2) 풀 타입(Pull Type)
배포 환경에 위치한 별도의 오퍼레이터가 배포 파이프라인을 대신한다. 이 오퍼레이터는 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지시켜 준다. 만약 누군가가 직접 손으로(허가 받지 않은 작업) 배포 환경을 변경했을 때도 다시 되돌려지게 되는데 이는 배포 환경의 변경은 저장소의 매니페스트를 통해서만 유효하다는 것을 보장한다. 다시 말해 배포 환경에 대한 모든 이력은 배포 환경 구성 저장소 즉, 깃에 존재한다는 것을 의미한다. 이런 방식을 지원하는 도구로는 아르고CD, 젠킨스X(JenkinsX), 그리고 깃옵스라는 용어를 만든 위브웍스에서 제작한 플럭스(Flux)가 있다.
앞에서 보안상의 이유로 깃옵스는 풀 타입 배포 전략을 권장한다고 언급했다. 이는 구조적 차이에서 발생하는 것으로 푸시 타입의 경우 배포 환경에 대한 자격 증명 정보를 외부에서 관리할 수 밖에 없다. 배포 환경 입장에서는 배포 파이프라인 자체가 외부 도메인이기 때문이다. 그리고 일반적으로 배포 파이프라인에게 배포 환경에 대한 읽기∙쓰기 권한을 부여하기 때문에 만의 하나 노출된다면 큰 피해를 볼 수도 있다.
반면 풀 타입의 경우 오퍼레이터가 애플리케이션과 동일한 환경에서 동작 중이어서 자격 증명 정보가 외부에 노출될 일이 없다. 그리고 배포 환경에 대한 자격 증명 정보도 오퍼레이터 관리를 위한 최소한의 인력으로 한정 지을 수 있다. 신경 써야 할 것은 배포 환경에서 깃 저장소와 이미지 저장소로의 접근 정도이다.
2. ArgoCD
ArgoCD 란?
- 쿠버네티스를 위한 GitOps 도구
- 쿠버네티스에 배포하려고 하는 상태를 Git에 저장하면 ArgoCD가 git에 있는 내용을 쿠버네티스 배포
- push타입과 pull타입 모두를 지원하며 pull타입 배포를 권장
"GitOps의 핵심은 Git 저장소에 저장된 쿠버네티스 매니페스트 같은 파일을 이용하여, 배포를 선언적으로 한다는 것입니다. 즉, Git에 저장된 매니페스트가 쿠버네티스 클러스터에도 똑같이 반영된다는 것입니다."
ArgoCD 장단점
GitOps의 장점을 가져갈 수 있습니다. 쿠버네티스로 관리하는 리소스를 git에 저장함으로써 코드로 관리할 수 있습니다. IAC처럼 말이죠. 하지만, GitOps를 하려면 팀의 문화가 갖추어져야 합니다. 누구는 GitOps를 쓰고 누구는 수동으로 kubectl로 관리하면 엉망진창이 됩니다.
최대 단점은 쿠버네티스에서만 ArgoCD를 사용할 수 있습니다. 쿠버네티스가 아닌 다른 환경에서는 사용하지 못합니다. 혼합환경을 사용하고 있는 곳이라면 Argo CD는 적절하지 않습니다. Jenkins, CircleCI등을 고려해야 합니다. 그리고, 쿠버네티스 메커니즘을 이용하므로 쿠버네티스에 대한 지식이 필요합니다.
두번째 단점은 git서비스의 장애를 대비해야 합니다. public github을 사용한다고 가정하면 github 서비스가 장애난 경우 argocd는 새로운 업데이트 내용을 가져오지 못합니다. 설치용 git을 사용한다면 HPA, DA등을 고려해야 합니다.
지원기능
정말 많은 기능을 지원합니다. Argo CD가 많은 사랑을 받는 것은 SSO, 도구(helm, kustomize 등) 호환성, 멀티 쿠버네티스 클러스터 관리, 사용자(또는 그룹)별 권한관리, WEB UI 제공이라고 생각합니다.
[참고]
- https://malwareanalysis.tistory.com/403
- https://s-core.co.kr/insight/view/%EB%8D%B0%EB%B8%8C%EC%98%B5%EC%8A%A4%EC%9D%98-%ED%99%95%EC%9E%A5-%EB%AA%A8%EB%8D%B8-%EA%B9%83%EC%98%B5%EC%8A%A4gitops-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-2/
- https://gruuuuu.github.io/cloud/argocd-gitops/
- https://www.weave.works/technologies/gitops/
- https://thenicesj.tistory.com/293