App of Apps 의 진화

여러 가지 관점이 있겠지만 그냥 나의 여러가지 생각을 한 번 말해보겠다.

 

1. 서비스의 시작(단일 서비스)

서비스가 1개이므로, Argo CD에서 직접 하나의 애플리케이션을 등록 및 관리

- 가장 간단한 구조

- 여기서 부터 시작해서 관리하게 됨

 

 

여기서 고려할 점은 어차피 저장소는 하나이기 때문에 저장소를 잘 관리하면 됨

-> gitops 파이프라인을 잘 지키면 됨

-> sync Policy도 여기서 잘 생각해봐야함

-> lint 와 같이 문법 관리, schema validation과 같이 문법을 관리해야함

-> git commit, git pr, branch 규칙을 잘 지킬 것

-> 분리할 수 있는 value.yaml 파일을 잘 분리시켜야 좋음

 

또한 Argo CD가 배포 클러스터에 대한 권한 관리가 잘 되어있어야함

-> Hard Refresh 등과 같은 기능 사용

 

 

 

 

 

 

2. 환경 분리

dev, staging, prod

서비스는 여전히 1개이지만, 환경별로 manifest가 분리

이를 관리하기 위해 상위 App에서 하위 App을 하위로 관리하는 구조

root app이 환경별로 자식 app을 각각 생성 및 동기화

- configuration만 분리해서 설정하는 경우가 많음

- Helm을 이용하는 경우values 별로 관리함

 

 

고려할 점

환경(dev, staging, prod) 별로 values.yaml 또는 kustomize overlay 설정이 달라져야 함

-> Helm Template을 쓸 수도 있고 kustomize를 쓸 수도 있음 둘다 비슷함

-> 브랜치로 관리하거나, 디렉토리로 관리

이제부터 App of apps의 시작함

각 하위 app의 project, syncPolicy, source path, destination 등 명확히 정의

 

특히 배포 환경(prod)에서는 auto-sync에 대해 조심해야함

바로 반영되어도 되는가? 에 대해서 비즈니스적으로 잘 생각해봐야 함

 

 

 

 

3. 여러 개의 서비스

최상위 App 아래 환경별 App, 그 아래 각 서비스 별 App이 하위로 배치

- 이제야 App of apps로 서비스가 한 세트가 되어 배포됨

- Cluster는 동일한 경우가 많음

 

고려할 점

서비스별 디렉토리 구조 명확히 분리 및 네임스페이스, 리소스 이름에 서비스명 prefix 적용

여러가지 서비스 배포 시, 종속성이 있을 수도 있음

-> Argo CD sync-wave 옵션 활용하여 배포 순서 명시

 

 

 

 

 

4. 공통의 리소스 관리 - 서비스 분리

공통 인프라와 각 서비스 App을 분리해서 각각 하위 App으로 관리

- 서비스 모니터링 또는 공통적으로 쓰는 인프라를 분리해서 하나의 애플리케이션으로 분리

 

고려할 점

- 공통리소스도 환경을 나누어서 순차적으로 적용 가능함

- 공통리소스는 네임스페이스를 통일해서 운영하는 것이 좋음

 

 

 

5. 멀티 클러스터

여러 클러스터로 확장, 상위 App에서 각 클러스터별 하위 App을 관리

 

고려할 점

여러 클러스터로 관리할 때, target cluster에 대한 충분한 권한이 있는지

여러 클러스터 운영

- 네트워크 장애, 권한 만료, Git webhook 동기화 오류 등으로 특정 클러스터에만 배포 지연/실패

- 클러스터별로 서로 다른 secret, config를 잘못 공유하거나, 모든 클러스터에 동일 secret이 배포되어 보안/환경 이슈