모범 사례
모범 사례 (Best Practices)
Argo CD로 GitOps를 운영할 때 적용하면 좋은 모범 사례를 정리합니다. 구성 저장소와 소스 코드 저장소 분리, 명령적(imperative) 요소를 남겨두는 방법, Git 리비전의 매니페스트가 진정으로 불변하도록 하는 방법을 다룹니다.
출처: 문서
본문
모범 사례
구성 저장소와 소스 코드 저장소 분리
Kubernetes 매니페스트를 보관하는 별도의 Git 저장소를 사용해 구성을 애플리케이션 소스 코드와 분리하는 것을 강력히 권장합니다. 이유는 다음과 같습니다:
- 애플리케이션 코드와 애플리케이션 구성을 깔끔하게 분리해 줍니다. 전체 CI 빌드를 트리거하지 않고 매니페스트만 수정하고 싶을 때가 있습니다. 예를 들어 Deployment 스펙의 레플리카 수만 올리려고 할 때 빌드를 트리거하고 싶지는 않을 것입니다.
- 더 깨끗한 감사 로그. 감사 목적으로 구성만 보관하는 저장소는 일반 개발 활동으로 인한 체크인 노이즈 없이 어떤 변경이 있었는지 훨씬 깨끗한 Git 히스토리를 갖습니다.
- 애플리케이션은 여러 Git 저장소에서 빌드된 서비스로 구성될 수 있지만 단일 단위로 배포될 수 있습니다. 종종 마이크로서비스 애플리케이션은 서로 다른 버전 체계와 릴리스 주기를 가진 서비스(예: ELK, Kafka + ZooKeeper)로 구성됩니다. 매니페스트를 단일 컴포넌트의 소스 코드 저장소 중 하나에 저장하는 것은 합리적이지 않을 수 있습니다.
- 접근 분리. 애플리케이션을 개발하는 개발자가 의도적이든 비의도적이든 프로덕션 환경에 푸시할 수 있거나 해야 하는 사람과 같지 않을 수 있습니다. 별도의 저장소를 두면 소스 코드 저장소에는 커밋 접근 권한을 주고 애플리케이션 구성 저장소에는 주지 않을 수 있습니다.
- CI 파이프라인을 자동화하고 있다면 같은 Git 저장소에 매니페스트 변경을 푸시하면 빌드 작업과 Git 커밋 트리거의 무한 루프가 발생할 수 있습니다. 구성 변경을 푸시할 별도의 저장소를 두면 이를 방지합니다.
명령적(Imperative) 요소를 위한 여지 남기기
모든 것을 Git 매니페스트에 정의하지 않고 일부 명령성/자동화를 위한 여지를 남기는 것이 바람직할 수 있습니다. 예를 들어 디플로이먼트의 레플리카 수를 Horizontal Pod Autoscaler가 관리하길 원한다면 Git에서 replicas를 추적하고 싶지 않을 것입니다.
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
# do not include replicas in the manifests if you want replicas to be controlled by HPA
# replicas: 1
template:
spec:
containers:
- image: nginx:1.7.9
name: nginx
ports:
- containerPort: 80
...
Git 리비전의 매니페스트가 진정으로 불변하도록 보장
helm이나 kustomize 같은 템플릿 도구를 사용하면 매니페스트가 하루아침에 의미가 바뀔 수 있습니다. 이는 보통 업스트림 helm 저장소 또는 kustomize base에 대한 변경 때문입니다.
예를 들어 다음 kustomization.yaml을 고려하세요:
resources:
- github.com/argoproj/argo-cd//manifests/cluster-install
위 kustomization은 argo-cd 저장소의 HEAD 리비전에 대한 원격 base를 갖습니다. 이것은 안정적인 대상이 아니므로, 이 kustomize 애플리케이션의 매니페스트는 자신의 Git 저장소에 변경이 없어도 갑자기 의미가 바뀔 수 있습니다.
더 나은 버전은 Git 태그나 커밋 SHA를 사용하는 것입니다. 예:
bases:
- github.com/argoproj/argo-cd//manifests/cluster-install?ref=v0.11.1