…이러한 토론 중 Weaveworks의 CEO인 Alexis Richardson은 이 모든 것을 설명하는 한 단어가 'GitOps'라는 것을 깨달았습니다. GitOps의 기본 아이디어는 시스템 외부에 있는 시스템 모델을 기반으로 전체 시스템에 대한 작업을 자동으로 만드는 것이었습니다. Git은 해당 모델을 배치하기로 선택한 곳입니다…
The History of GitOps 중에
GitOps란
•
git을 중심으로 클라우드 네이티브 애플리케이션에 대한 Continuous Deployment를 구현하는 방법 중 하나로 Weaveworks에서 2017년에 처음 주창.
•
git, IaC(Infrastructure as Code), CI(Continuous Integration) 등의 개발자에게 익숙한 도구를 사용하여, 개발자 중심의 경험을 운영 인프라(operating infrastructure)로 확장
참고 : Continuous Deployment는 CD(Continuous Delivery)에서 production으로의 배포를 자동화한 것에 차이가 있음
GitOps의 key idea
•
CI 뿐 아니라 CD에도 git을 적용
•
개발자가 사용한 git workflow를 운영팀에도 적용 (e.g. Pull Request)
•
git은 SSOT(Single Source Of Truth)일 뿐 아니라, environment(e.g. staging, production)에 대한 인터페이스의 역할도 겸함
GitOps 원칙
1.
선언적 (Declarative) : GitOps에서 관리하는 시스템은 선언적으로 원하는 상태를 표현해야
2.
버전 지정 및 불변성 (Versioned and Immutable) : 원하는 상태는 불변적이고 버전이 지정되며 완전한 버전 이력을 강제하는 방법으로 저장되어야
3.
자동으로 가져오기 (Pulled Automatically) : 소프트웨어 에이전트는 소스에서 원하는 상태에 대한 선언을 자동적으로 가져와야
4.
지속적인 화해 (Continuously Reconciled) : 소프트웨어 에이전트는 지속적으로 실제 시스템 상태를 관찰하고 원하는 상태를 적용하려고 시도하여야
원하는 상태(Desired State) : 시스템 재생성 시 해당 인스턴스들 간의 동작상 구분이 불가하기에 충분한 구성(configuration) 데이터의 모음. 구성 데이터에는 영구(persistent) 애플리케이션 데이터(예컨데 데이터베이스 컨텐츠)는 일반적으로 포함되지 않음. 하지만 해당 데이터 접근을 위한 자격 증명 또는 해당 시스템용 데이터 복구 도구를 위한 구성은 종종 포함됨.
참고로, Kubernetes의 yaml 기반 manifest는 선언적 상태 표현이며, 이 manifest를 git에서 관리하면 버전 지정 및 불변성이 완성되며, 자동으로 가져오기 및 지속적인 화해는 argoCD의 특성임.
GitOps의 workflow
•
상단 CI 과정은 기존과 동일(개발자에 의해 git에 code 변경 사항 반영, container image 생성 및 Registry로의 image 저장)
•
image 변경 사항에 대한 manifest code git으로의 업데이트 요청(Pull Request. 상단에서 하단으로 연결 과정 - Update image in staging config)
•
하단은 CD 과정으로, 제출된 PR에 대해 검토 및 git에 merge. Deploy Operator는 이를 확인하여 DEPLOY 수행
References
•
The Path to GitOps
•
GitOps Cookbook, Kubernetes Automation in Practice
•
GitOps - Cloud-native Continuous Deployment