[k8s] Strategy for Gitops

Strategy for Gitops

1. 현재 terraform을 branch를 통해 환경을 나누고 있었고, 괜찮은 결정이었다고 생각, 가장 큰 이유는 코드 base가 동일하며 terraform에 경우 workspace 단위로 나눌 수 있기 때문이라고도 생각이 들었다.
2. 하지만 동일한 code base로 인해 선언적인 명령에서 점점 멀어지게 되었고, code 관리 및 git branch 관리가 불편해진 경험을 다수 느낄 수 있었습니다.
3. gitops에 해당 전략을 적용해볼려고 자료를 조사해본결과 꽤 큰 도전적인것들이 있었습니다. 그 중에서는 git에서 환경에 따라 value를 어떻게 분리 할 것 이며, kustomize를 이용해서 분리된 value를 변경할 것 인가 라는 도전적인 부분이 있었습니다.
4. 하지만 YAML은 구조화된 데이터를 표현하기 위한 형식으로 프로그래밍 로직을 포함 할 수 없다. 자료 조사 하면서 RedHat에서 gitops에 관한 article을 읽게 되었고 관련 자료를 첨부합니다
5. 내용은 환경을 branch 별로 나누었을때의 단점에 대해서 나와있으며, Kubernetes, Kustomize 패치 프레임워크, Helm 패키지 매니저의 세계에서는 환경에 대해 브랜치를 사용하는 것이 안티패턴이며, 환경 간의 차이를 기록할 때 트렁크에 병합될 변경 사항을 명확히 볼 수 있다고 명시되어있던 부분이 공감이 되었던 것 같습니다.

Git best practices: Workflows for GitOps deployments | Red Hat Developer

Git best practices: Workflows for GitOps deployments | Red Hat Developer

 

6. 현재 charts의 버전관리 및 환경별 버전 분리를 위해 charts repo를 gitops와 분리했습니다. 참고한 레퍼런스 두 군데와 고민했을때 저희에게 적합한 구조를 공유드립니다.

├── bootstrap

# 현재 bootstrap은 terraform으로 관리되고 있어 생략합니다.

└── apps

      ├── genny

      │   ├── base # 공통된 value들이 들어가게 됩니다.

      │   └── overlays # 환경별로 변경되는 value들이 들어가게 됩니다. (ex, image url, tag)

      │       ├── dev

      │       ├── prod

      │       └── stage

      └── customvoice

          ├── base

         └── overlays

           ├── dev

           ├── prod

           └── stage

How to set up your GitOps directory structure | Red Hat Developer

How to set up your GitOps directory structure | Red Hat Developer

GitOps-Patterns: Examples

GitOps-Patterns: Examples