1. GitOps란?
GitOps는 운영자가 인프라에 직접 배포하지 않고, Git 리포지토리에 애플리케이션 및 인프라 구성을 올려두면 GitOps 컨트롤러가 이를 pull해서 자동으로 배포하는 방식이다. 이 방식은 선언적 구성 관리(declarative infrastructure)를 사용하여 Git 리포지토리를 단일 진실 소스(Single Source of Truth)로 삼는다.
- GitOps 컨트롤러는 Git 리포와 인프라 상태를 지속적으로 비교함
- Git 리포지토리의 변경 사항이 발견되면, 해당 변경 사항을 자동으로 배포함
- 인프라 리소스의 상태와 Git 리포의 상태가 다를 경우, 인프라를 Git 리포지토리 상태와 일치시킴
➡️ 이 방식 덕분에 운영자는 인프라에 직접 접근하지 않고도 배포를 자동화할 수 있으며, 일관된 버전 관리 및 신뢰성을 확보할 수 있음!
2. Push 방식이 아니라 Pull 방식을 쓰는 이유는?
- Push 방식 : 클러스터 외부에서 타겟 인프라로 접근할 때 보안 리스크가 존재함.
→ 외부에서 클러스터에 접근해야 하므로, 타겟 인프라의 정보가 외부에 노출될 수 있는 위험이 있음 - Pull 방식 : 타겟 클러스터 자체가 Git 리포에서 정보를 가져오므로, 외부 접근을 최소화하고 클러스터의 정보가 외부에 노출되지 않음
→ 보안 리스크 감소
Pull 방식의 큰 장점은, 타겟과 소스가 분리되기 때문에 배포 과정에서 발생할 수 있는 외부로의 정보 노출 가능성을 줄여준다는 것임!
3. GitOps 툴
대표적으로 Flux와 ArgoCD🐙가 있음!
- Flux
간결하고 확장 가능한 GitOps 도구임. 주로 CI/CD 파이프라인에 통합하여 쿠버네티스 리소스를 자동으로 동기화함. - ArgoCD
웹 UI를 제공하는 GitOps 도구로, 시각적 관리가 가능하다는 점에서 Flux와 차별화됨. 대규모 애플리케이션 배포 환경에 적합하며, 자동 동기화 및 롤백 기능을 지원함.👍🏻👍🏻
4. ArgoCD 파이프라인 아키텍처 🔍
- 개발자(Developer)
- 개발자는 코드 또는 애플리케이션 구성을 작성하고 이를 GitHub 레포지토리에 커밋함. 이때, 커밋된 코드는 애플리케이션의 변경 사항을 포함함.
- GitHub
- 개발자의 코드 커밋이 GitHub 레포지토리에 반영됨. GitOps에서는 Git 리포지토리가 애플리케이션 및 인프라의 단일 진실의 소스(Single Source of Truth)로 사용됨.
- Webhook을 통해 GitHub에서 변경 사항이 발생했음을 알림.
- CI 툴 (Jenkins)
- Jenkins는 CI(Continuous Integration) 도구로, GitHub에 커밋된 코드를 자동으로 빌드하고 테스트하는 역할을 함.
- 코드 커밋이 완료되면 Jenkins가 GitHub에서 변경 사항을 감지하고, 이를 바탕으로 빌드 및 테스트를 진행함.
- ArgoCD
- ArgoCD는 GitOps 컨트롤러 역할을 함. Git 리포지토리에서 애플리케이션 및 인프라 설정을 pull하여 쿠버네티스 클러스터와 동기화함.
- Jenkins에서 빌드가 완료되면 ArgoCD는 웹훅(Webhook)을 통해 GitHub의 변경 사항을 인지하고, 이를 기반으로 쿠버네티스 클러스터의 상태를 업데이트함.
- 즉, GitHub에 있는 리소스 정의와 쿠버네티스 클러스터의 실제 상태를 일치시키기 위해 자동 동기화가 이루어짐.
- Kubernetes Cluster
- Kubernetes 클러스터는 ArgoCD에서 전달받은 리소스 정의를 통해 애플리케이션을 배포하고 관리함.
- ArgoCD는 쿠버네티스 클러스터의 상태를 지속적으로 모니터링하며, GitHub 리포지토리에 있는 정의와 일치하지 않으면 클러스터의 상태를 자동으로 동기화해서 배포함.
아자!아자! 개발자!