[3주차] GitOps와 ArgoCD

*본 게시글의 내용은 가시다님의 노션 페이지와 스터디 자료인 '24단계 실습으로 정복하는 쿠버네티스 도서' 를 기반으로 작성하였습니다.

개요

ArgoCD나 k8s의 CI/CD 파이프라인 구축은 다양한 방법으로 여러 번 핸즈온 해 보았으므로(AWS CodeSeries, Harbor-Jenkins-ArgoCD, GitHub Action 등), 실습 내용보다는 사용하면서 추상적임에도 당연하게 받아들여왔던 GitOps의 개념과 ArgoCD에 대하여 보다 명확하게 정리해보고자 한다.

GitOps

---

GitOps란?

깃옵스는 프로젝트에 DevOps를 적용하기 위한 여러 컨셉 중 하나로, 클라우드 네이티브 애플리케이션의 지속적 배포(Continuous Deployment, CD)를 위한 방법이다.

'개발과 운영의 경계를 허문다'는 데브옵스의 철학에서 알 수 있듯이, GitOps는 배포 단위 당 하나의 Git 리포지토리를 단일 원천으로 하며, 인프라를 코드로(IaC)하는 정도에서 확장하여 애플리케이션의 배포까지 관련된 모든 요소를 코드화 하여 Git에서 관리하는 것을 목표로 한다.

깃옵스 환경에서 인프라 레벨의 개선 또는 애플리케이션의 버전 업데이트와 같이 수정이 발생하는 경우, 작업자는 변경된 코드를 레포지토리에 반영하는데서 그 역할을 마친다. 그 이후의 스텝은 모두 자동화 하며 심지어 Abnormal 상태의 정상화까지도 스스로 감지하고 롤백하도록 인적 자원의 개입을 최소화 하는 것이 궁극적인 목표이다.

깃을 기반으로 하고 있으므로 변경 사항에 대한 추적(Commit log)과 롤백이 용이하다는 점은 다수의 작업자들이 협업하는 환경에서도 장점으로 작용한다. 개발 단계에서만 사용하던 깃의 기능들을 운영 과정에서도 지속적으로 사용할 수 있게 된 것이다.

SSOT(Single Source Of Truth)

GitOps를 관통하는 가장 중요한 개념이 바로 단일 진실 공급원(SSOT)이다. 앞서 깃옵스는 배포 단위 당 하나의 Git 레포지토리를 단일 원천으로 한다고 하였는데, 같은 데이터가 여러 곳에 혼재하거나 하나의 단위로 묶을 수 있는 데이터를 불필요하게 파편화하여 관리 추적이 어려운 경우 페일 포인트가 될 수 있다. 따라서 관리는 되도록 한 곳에서 하며, 필요한 경우 참조하는 형식으로 사용해야 한다.

배포 전략

깃옵스는 푸시 타입(Push Type)과 풀 타입(Pull Type), 두 가지의 배포 전략을 가이드 하고 있다. 어느 이벤트를 트리거로 하여 CD 파이프라인이 동작하는가의 차이이다. 깃옵스를 구현할 때는 보안상의 이유로 풀 타입 배포 전략을 권장하고 있다. 그 이유는 아래에 서술.

(출처 : 에스코어 테크블로그)

Push Type

개인적으로는 Push Type을 선호하지 않기 때문에 단점을 먼저 서술하자면,

Push Type의 깃옵스를 구현한다면 배포 환경과 형상이 달라지는 경우 이에 대한 Notification을 받을 수 있어야 한다. 후술할 Pull Type과 달리 Push Type은 구조적으로 원천에 대한 지속적인 체크가 이루어지지 않기 때문이다. 변경사항이 발생한 것을 확인하였다면 형상을 다시 일치시키는 동작까지도 자동화가 필요하다. 또한 Push 이벤트 한 번이면 배포 환경까지 변경 사항이 발생하기 때문에 중간에 인가 절차도 추가되는 편이 좋다. 한 마디로 손이 많이 간다.

그럼에도 Push Type이 사용되는 이유로는 단순한 아키텍처를 꼽을 수 있다. 지속적으로 레포지토리를 체크할 필요가 없고 Push 이벤트만 옵저빙 하면 되기 때문이다.

(출처 : 에스코어 테크블로그)

Pull Type

3주차 주제에 포함되었던 ArgoCD가 Pull Type에 해당한다. ArgoCD는 연결된 Git Repository를 지속적으로 비교하고 있다가 차이가 감지되면 저장소의 상태를 기준으로 매니페스트를 Pulling하여 배포된 애플리케이션의 상태를 갱신한다. 이러한 컨셉 때문에 ArgoCD의 AutoSync옵션을 Enable해두면 k8s 클러스터에서 수동으로 변동사항이 발생하더라도 ArgoCD에서 관리되고 있는 매니페스트라면 다시 원상태로 자동 복원시킨다. 이는 배포된 환경의 상태는 반드시 단일 원천인 Git Repository만을 기반으로 한다는 점을 명확히 하는 동작이다.

왜 Pull Type을 권장하는가?

깃옵스를 구현할 때는 Pull Type 배포 전략을 권장하는데, 그 이유는 자격정보의 관리 때문이다. Push를 하기 위해서는 Push를 수행하는 지점에서(비록 외부 환경이라 할 지라도)관리 정보를 가지고 있어야 하며, 어떤 방식으로든 비인가자에 의하여 해당 Git Repository로 Push 이벤트가 발생한다면 배포 환경에 변경이 발생하여 피해를 입을 수 있기 때문이다.

이와 반면에 Pull 이벤트를 기반으로 동작한다면 CD를 수행하는 ArgoCD에서만 해당 레포지토리에 대한 인증 정보를 가지고 있으면 되고, Pull 권한만을 필요로 하기 때문에 SSOT에 의도치 않은 변경이 발생할 위험으로부터 비교적 자유로워진다.

ArgoCD 주요 용어 정리

• Application : 매니페스트로 정의된 쿠버네티스 리소스의 모음
• Target state : 애플리케이션의 Desired State
• Live state : 애플리케이션의 현재 상태
• Sync status : 애플리케이션의 Live state와 Target state의 일치 여부. 즉, Git Repository와 배포된 애플리케이션의 상태가 일치하는가
• Sync : 배포된 애플리케이션의 상태를 Git Repository의 상태와 같이 일치시킴. 만약 일치하지 않는 상황에서 Sync 버튼을 누르면 배포가 발생함.
• Sync operation status : Sync 명령의 수행 상태.
• Refresh : Git Respository의 상태와 현재 배포 상태를 단순 비교한다.
• Health : 애플리케이션의 Health Check 결과. 서비스가 정상 동작하는지 확인.

ArgoCD 아키텍처

ArgoCD는 크게 세 가지 구성 요소로 나누어진다.

API 서버

API 서버는 ArgoCD의 웹 대시보드, ArgoCD CLI를 통해 요청을 처리하기 위한 API를 노출하는 gRPC/REST 서버이다. ArgoCD API 서버는 아래와 같은 역할을 한다.

• ArgoCD 애플리케이션 관리 및 상태 보고
• ArgoCD 애플리케이션에서 수행할 수 있는 작업 호출(예: Sync, Rollback, Refresh 등)
• Git Repository와 및 k8s 클러스터에 연결하기 위한 자격 증명 관리(k8s secrets로 저장됨)
• 인증, RBAC
• Git webhook 이벤트 리스너

리포지토리 서버

리포지토리 서버는 애플리케이션의 매니페스트를 보관하는 Git Repository의 캐시를 관리하는 서비스이다. 아래의 Input을 필요로 한다.

• 저장소 URL
• Revisions(commit, tag, branch)
• 애플리케이션 Path
• 기타 템플릿별 설정(helm values.yaml)

애플리케이션 컨트롤러

애플리케이션 컨트롤러는 실행 중인 애플리케이션을 지속적으로 모니터링하고 현재의 Live state를 Target State와 비교하는 Kubernetes 컨트롤러이다. ArgoCD 애플리케이션이 OutOfSync 상태에 빠지면 이를 감지 하고, Auto Sync 옵션이 Enable 상태라면 자동으로 되돌리는 동작도 이 애플리케이션 컨트롤러에 의해 이루어지게 된다.

실습 결과

Harbor

GitLab Projects

레포지토리 연결

Application