GitOps를 위한 Git 관리 전략

참고 : 하기 내용은 The Path to GitOps의 4, 5장에서 추출되었습니다.

Operations via Pull Request

… GitOps의 아이디어는 (개발자의 그것과) 동일한 workflow를 인프라 및 애플리케이션 변경에도 적용하는 것입니다. 변경은 해당 Git 저장소로의 Pull Request를 발행하는 것으로 제안됩니다 …

Motivation

CD용 git으로의 (manifest) code merge에는 어떤 전략을 취해야 하는지 고민 도중 BP를 찾다가…
알고보니 CD용 git으로의 merging 조차 Pull Request를 한다는 것을 마주치면서 CD용 git 관리 BP가 필요하다는 것을 보면서..

Git Workflows BP

application code와 configuration code를 분리 (Separate Your Repositories)

일반적으로 application code와 configuration code는 독립적인 라이프사이클을 가지며, 함께 있을 경우 CI / CD 프로세스 상호간 불필요한 간섭, 마찰이 발생하기 마련임
(DevOps가 CI/CD 간 장벽 제거를 추구하지만) 각각을 담당하는 팀 분리는 발생하기 마련이며, 이들 코드가 분리되어 있으면 상대적으로 유리.

environment의 구분을 branch가 아닌 directory로 (Separate Development in Directories, Not Branches)

예컨데, staging용 configuration과 production용 configuration을 branch가 아닌 각각의 directory로 구분하라고.
branch를 쓸 경우 merge가 필요하고 merge는 결코 간단한 일이 아님. 특히 cherry-pick 연산이 개입될 경우 더욱 어려워짐.

TBD (Trunk Based Development)

다음의 TBD 특징이 GitOps와 특히 잘 맞음
- 애플리케이션 변경사항의 신속한 전달에 초점을 맞춤. 이는 지속적인 통합과 지속적인 전달을 가능케 함.
- cherry-pick할 필요가 별로 없음.
- Git 저장소에 있는 것이 실제로 환경으로 이동하는 것이라는 확신을 더 많이 갖게 함
production 과 prod 는 trunk branch로 많이 쓰이는 이름임

정책과 보안 (Policies and Security)

TBD의 단일 branch 정책은 production 뿐 아니라 조직 전체에 해당하므로 trunk의 안정성 유지는 매우 중요하며 안정성 유지를 위한 장치, 즉 정책과 보안이 필요.
trunk 보호 규칙으로 강제 merge 불가, merge 가능 인원 제한, merge 시점 설정 등이 있을 수 있음.

Git 디렉토리 구조

Key Idea

DRY(Don’t Repeat Yourself)의 중복 방지(특히 yaml에서 중복)과 설계는 조직의 소통 구조를 따르기 마련이라는 Conway 법칙을 고려.
Kustomize 사용 및 Kustomize가 제시하는 directory 구조를 기본적으로 사용(e.g. base, overlays)
- Environment 별 configuration에 따른 manifest yaml 상 중복 제거 등 용도
- 참고로 Kustomize와 Helm는 상호보완적 관계라 논하지만, 기본적으로 Kustomize를 더욱 중시하는 중.
다수의 App, 나아가 cluster 자체에 대한 configuration 및 GitOps Controller(e.g. Argo CD)에 대한 configuration도 함께 저장

디렉토리 구조 예제

├── bootstrap
│   ├── base
│   └── overlays
│       └── default
├── components
│   ├── applicationsets
│   └── argocdproj
├── core
│   ├── gitops-controller
│   └── sample-admin-workload
└── apps      
		├── bgd-blue      
		│   ├── base      
		│   └── overlays     
		│       ├── dev      
		│       ├── prod      
		│       └── stage      
		└── myapp          
				├── base          
				└── overlays
            ├── dev
            ├── prod
            └── stage

bootstrap : cluster와 GitOps Controller에 대한 configuration 저장. 전자는 base에, 후자는 overlays 에.
components : GitOps Controller에 대한 추가/확장 configuration(e.g. applicationsets의 경우 https://argo-cd.readthedocs.io/en/stable/user-guide/application-set/ 참조)
core : cluster의 핵심 기능(core functionality)를 위한 yaml을 저장. 예컨데 admin이나 GitOps Controller가 있을 수 있음
apps : 개발자나 릴리즈 엔지니어가 주로 다루는 곳으로, 클러스터 내 동작하는 workload를 위한 yaml이 위치.