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
C#
복사
•
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이 위치.
References
•
The Path to GitOps