GitOps Overview

GitOps는 cluster 상태를 직접 손으로 맞추는 대신, Git에 선언된 manifest를 원하는 상태로 삼는 운영 방식입니다.

이 예제에서는 Argo CD가 cd-repo의 environment path를 감시합니다. Git에 변경이 merge되면 Argo CD가 해당 manifest를 읽고 Kubernetes cluster에 적용합니다.

1. Source Repo와 CD Repo의 차이

source repo와 CD repo는 서로 다른 질문에 답합니다.

Repo	Main question
source-repo	이 app/package/image가 올바르게 만들어졌는가?
cd-repo	어떤 image를 어떤 환경에 배포할 것인가?

source repo는 package, app, contract, test, image build를 검증합니다. CD repo는 검증된 image를 environment overlay에 배치합니다.

2. GitOps Flow

일반적인 흐름은 다음과 같습니다.

source-repo
  -> test, contract validation, image build
  -> image publish
  -> release handoff

cd-repo
  -> environment overlay update
  -> pull request
  -> merge to main
  -> Argo CD sync
  -> Kubernetes rollout

3. Why Git Keeps the Deployment Record

배포 변경은 Git history로 남아야 합니다.

Git history는 어떤 image가 언제 어떤 환경으로 들어갔는지 보여줍니다. 장애가 발생했을 때도 kubectl edit 기록을 추적하는 대신, CD repo commit과 Argo CD revision을 기준으로 원인을 좁힐 수 있습니다.

4. Current Cluster Model

현재 dev와 stg는 같은 Kubernetes API server를 사용하고 namespace로 환경을 나눕니다.

Environment	Namespace
dev	tirosh-guide-dev
stg	tirosh-guide-stg

이 구성은 guide 예제에서 배포 경계를 이해하기 위한 단순한 모델입니다. 실제 production 환경은 별도 cluster, 별도 project, 더 강한 approval gate를 둘 수 있습니다.