GitOps 란?
- 2017년에 Weaveworks 에서 GitOps 란 용어를 처음 사용하기 시작했으며 프로젝트에 데브옵스를 적용하는 실천 방법 중 하나
- 클라우드 네이티브 애플리케이션을 대상으로 한 지속적 배포(Continuous Deployment)를 구현하기 위한 방법
- 핵심 아이디어는 현재 프로덕션 환경에서 원하는 인프라에 대한 선언적 설명을 항상 포함하는 Git 저장소와 프로덕션 환경이 저장소의 설명된 상태와 일치하도록 하는 자동화된 프로세스를 갖는 것이다.
GitOps 를 사용해야 하는 이유?
Deploy faster More Often
배포의 속돌르 높이고 더 자주 배포할 수 있음. GitOps 는 애플리케이션 배포를 위해 도구를 전환할 필요가 없음. 모든 것은 애플리케이션 개발에 사용하는 VCS 에서 발생함
Easy and Fast Error Recovery
GitOps 를 사용하면 시간이 지남에 따라 환경이 어떻게 변했는지에 대한 기록이 있으며 git revert 로 쉽게 오류를 복구할 수 있음
“git commit → push → merge request → review → merge”
Easier Credential Management
내부에서 배포를 완전히 관리할 수 있음. 이를 위해 리포지토리 및 이미지 레지스트에만 액세스 하면 되는 장점. 개발자에게 환경에 대한 직접 액세스 권한의 부여가 필요치 않음
Self-documention Deployments
GitOps 를 사용하면 환경에 대한 모든 변경이 저장소를 통해 이루어져야 한다.
항상 마스터 브랜치를 확인하고 어디에 배포되었는지에 대한 완전한 설명과 시스템에 적용된 모든 변경의 전체 기록을 얻을 수 있다.
Shared Knowledge in Teams
Git 을 사용하여 배포도니 인프라에 대한 전체 설명을 저장하면 팀의 모든 사람이 시간 경과에 따른 발전을 확인할 수 있다.
훌륭한 커밋 메시지를 통해 누구나 인프라 변경에 대한 생각 프로세스를 재현하고 새 시스템을 설정하는 방법에 대한 예를 쉽게 찾을 수 있다.
GitOps 핵심 개념
1️⃣ 선언형 모델(Declarative Model)
GitOps 가 아닌 방식은 명령형 모델(Imperative model)로 자동화 하는 것인데 이 방뻐은 간단하지만 예외상황을 모두 관리해야 하며, 원격 대상에 대한 지식이 필요하는 등의 단점이 있음
이에 반해 선언형 모델은 대상이 무엇이 되어야 하는지만 기술하면 되며 코드 형태로 세부 내용을 작성하기만 하면 된다.
선언형 모델의 대표적인 구현체로 쿠버네티스가 있으며 인프라를 포함한 애플리케이션의 배포와 운영에 관련된 모든 것을 코드로 관리할 수 있다는 점과 이 코드를 이용하여 언제든 똑같은 환경을 다시 만들어내거나 부분 소실 시 복원할 수 있다는 점이다.
2️⃣ 단일 진실 공급원(Single Source Of Truth, SSOT)
GitOps 에서는 깃을 단일 진실 공급원으로 저장하고 오직 이 곳에서만 관리하도록 한다.
모든 운영 활동의 시작은 깃이므로 사람 혹은 시스템 간의 혼선을 최소화 할 수 있다.
또한 개발 단계에서만 누릴 수 있었던 깃의 강력하고 익숙한 기능을 운영 단계에서도 활용할 수 있게 된다.
GitOps 구현
🔗 GCP 에서 코드형 인프라 관리하기 -
https://cloud.google.com/architecture/managing-infrastructure-as-code-with-terraform-jenkins-and-gitops?hl=ko
저장소 전략
최소 2개 이상의 저장소를 사용하며 다음과 같다
애플리케이션 저장소
애플리케이션 소스 코드와 애플리케이션 배포를 위한 배포 매니페스트(예:kubernetes yaml)를 포함한다.
배포 환경 구성 저장소
배포 환경에 대한 모든 매니페스트를 포함한다. 애플리케이션과 인프라 서비스(모니터링, 메시지 브로커 등)가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보가 들어있다.
여러 응용 프로그램 및 환경 작업
배포 전략
푸시 타입(Push type) 과 풀 타입(Pull type), 두 가지의 배포 전략을 가이드 하고 있다.
Push 기반 배포
푸시 기반 배포 전략은 Jenkins , CircleCI 또는 Travis CI 와 같은 널리 사용되는 CI/CD 도구로 구현된다.
애플리케이션의 소스 코드는 앱을 배포하는 데 필요한 Kubernetes YAML과 함께 애플리케이션 저장소 내부에 있다.
애플리케이션 코드가 업데이트될 때마다 빌드 파이프라인이 트리거되어 컨테이너 이미지를 빌드하고 마지막으로 환경 구성 리포지토리가 새 배포 설명자로 업데이트 된다.
환경 구성 리포지토리를 변경하면 배포 파이프라인이 트리거됩니다.
이 파이프라인은 환경 구성 저장소의 모든 매니페스트를 인프라에 적용하는 역할을 합니다.
이 접근 방식을 사용하면 배포 환경에 자격 증명을 제공하는 것이 필수적입니다. 일부 사용 사례에서는 클라우드 인프라의 자동화된 프로비저닝을 실행할 때 푸시 기반 배포가 불가피합니다.
이러한 경우 더 제한적인 배포 권한을 위해 클라우드 공급자의 세분화된 구성 가능한 인증 시스템을 활용하는 것이 좋습니다.
이 접근 방식을 사용할 때 명심해야 할 또 다른 중요한 사항은 배포 파이프라인 은 환경 저장소가 변경될 때만 트리거된다는 것입니다. 환경 및 원하는 상태의 편차를 자동으로 감지할 수 없습니다. 즉, 환경이 환경 저장소에 설명된 것과 일치하지 않는 경우 개입할 수 있도록 적절한 모니터링 방법이 필요합니다.
🔗 GCP 에서의 푸시 기반 배포 -
https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build
Pull 기반 배포
두 옵션 간의 차이점은 저장소에 있는 매니페스트와 배포 환경의 상태를 일치시키는 방법이다. 무엇을 선택해도 상관없으나 깃옵스는 보안상의 이유로 풀 타입 배포 전략을 권장한다.
풀 기반 배포 전략은 푸시 기반 변형과 동일한 개념을 사용하지만 배포 파이프라인이 작동하는 방식이 다릅니다.
기존 CI/CD 파이프라인은 예를 들어 새 코드가 애플리케이션 리포지토리로 푸시될 때 외부 이벤트에 의해 트리거됩니다.
풀 기반 배포 접근 방식을 사용하면 운영자 가 도입됩니다.
환경 리포지토리의 원하는 상태와 배포된 인프라의 실제 상태를 지속적으로 비교하여 파이프라인의 역할을 인수합니다.
차이점이 발견될 때마다 운영자는 환경 저장소와 일치하도록 인프라를 업데이트합니다.
또한 이미지 레지스트리를 모니터링하여 배포할 이미지의 새 버전을 찾을 수 있습니다.
이러한 방향 변경은 환경 저장소가 업데이트될 때만 환경이 업데이트되는 푸시 기반 배포의 문제를 해결합니다.
그러나 이것이 모니터링 없이 완전히 할 수 있다는 것을 의미하지는 않습니다. 대부분의 운영자는 컨테이너 이미지를 가져올 수 없는 경우와 같이 어떤 이유로든 환경을 원하는 상태로 가져올 수 없는 경우 메일 또는 Slack 알림 보내기를 지원합니다.
또한 운영자 없이는 더 이상 자동화된 배포 프로세스가 없으므로 운영자 자체에 대한 모니터링을 설정해야 합니다.
🔗 weaveworks Flux 를 사용하여 Google GKE 에서 풀 기반 GitOps 를 설정하기 - https://cloud.google.com/kubernetes-engine/docs/tutorials/gitops-cloud-build
GitOps 도구
- ArgoCD: A GitOps operator for Kubernetes with a web interface
- Flux: The GitOps Kubernetes operator by the creators of GitOps — Weaveworks
- Gitkube: A tool for building and deploying docker images on Kubernetes using git push
- JenkinsX: Continuous Delivery on Kubernetes with built-in GitOps
- Terragrunt: A wrapper for Terraform for keeping configurations DRY, and managing remote state
- WKSctl: A tool for Kubernetes cluster configuration management based on GitOps principles
- Helm Operator: An operator for using GitOps on K8s with Helm
- werf: A CLI tool to build images and deploy them to Kubernetes via push-based approach
블로그 게시물 및 소셜 미디어
참고자료
