GitOps란? 무엇인가?
GitOps 란?
GitOps는 2017년에 위브웍스(Weaveworks Inc.)에서 처음 사용한 용어로 프로젝트에 DevOps의 실천 방법 중 하나이다. 그 중에서도 클라우드 네이티브 애플리케이션을 대상으로 한 지속적 배포(Continuous Deployment)에 초점을 두고 있다. 단어로 알 수 있듯이 애플리케이션의 배포와 운영에 관련된 모든 요소들을 코드화하여 Git에서 관리(Operation) 한다는 것을 뜻한다.
출처: Weaveworks
GitOps는 버전 관리, 협업, 컴플라이언스, CI/CD 등 애플리케이션 개발에 사용되는 DevOps 모범 사례를 인프라 자동화에 적용한 운영 프레임워크이다.
“인프라와 애플리케이션을 모두 포함한 시스템 전체의 코드를 Git을 사용하여 관리한다"라는 생각과 방법이 GitOps의 본질이다. GitOps는 Git 버전 관리 시스템을 사용하여 인프라 구성 파일(IaC, Infrastructure as Code)을 관리한다.
여기서 인프라라라고 하라도 Kubernetes가 전제로 되어 있고 있고, 간단하게 말하면, GitOps는 Kubernetes Manifest파일을 Git에서 관리하고, 배포할 때에도 Git에 저장된 Manifest로 클러스터에 배포하는 일련의 과정들을 의미한다.
GitOps의 원칙
모든 시스템은 선언적으로 선언되어야 한다.
- “선언적(declarative)“이라 것은 명령들의 집합이 아니라 사실(fact)들의 집합으로 구성이 되었음을 보장한다는 의미한다.
- 쿠버네티스의 manifest들은 모두 선언적으로 작성되었고, 이를 Git으로 관리한다면 versioning과 같은 Git의 장점과 더불어, SSOT(single source of truth)를 소유하게 된다.
시스템의 상태는 Git의 버전을 따라간다.
- Git에 저장된 쿠버네티스 manifest를 기준으로 시스템에 배포되기 때문에 이전 버전의 시스템을 배포하고 싶으면 git revert와 같은 명령어를 사용하면 된다.
승인된 변화는 자동으로 시스템에 적용된다.
- 한번 선언된 manifest가 Git에 등록되고 관리되기 시작하면 변화(코드 수정 등)가 발생할때마다 자동으로 시스템에 적용되어야 하며, 클러스터에 배포할때마다 자격증명은 필요하지 않아야 한다.
배포에 실패하게 되면, 이를 사용자에게 경고해야 한다.
- 시스템 상태가 선언되고 버전 제어 하에 유지되었을 때, 배포가 실패하게 되면 사용자에게 경고할 수 있는 시스템을 마련해야 한다.
GitOps의 장점
크게 나누어 다음 4가지가 GitOps를 사용하는 이점으로 생각할 수 있다.
생산성
- Git이 변경되면 리포지토리의 IaC 설정이 변경되어 Kubernetes 클러스터 업데이트 및 기능 관리를 Git을 통해 수행할 수 있다.
- 운용에서 배포까지 Git으로 할 수 있으며, 프로덕션 환경의 상태를 Git상의 IaC와 비교하여 일치하지 않는 경우에는 탐지, 수정할 수도 있다.
안정성
- GitOps 워크플로를 도입하면 외부에서 이루어진 Kubernetes 클러스트에 대한 변경 감사 로그를 자동으로 검색할 수 있다.
- 이렇게 하면 “누가, 언제, 무엇을 했는지"가 로그로 남아 있으므로 문제 해결이 더 쉬워진다.
신뢰성
- 인수에 의한 인프라의 관리에서는 커맨드 실수(kubectl apply 방향)등이 있을 수 있지만, GitOps에서는 그러한 실수는 일어나지 않는다. 롤백 등의 운용도 Git을 통해 관리하므로 안정 stake 재현성이 있는 오퍼레이션이 가능한다.
보안
- CI/CD 툴을 이용한 배포는 기본적으로 kubectl에서 클러스터에 Push하고 배포하기 위해 클러스터 외부에 자격 증명을 공개해야 하기 때문에 보안상 바람직하지 않을 수도 있다. CI와 CD의 기능의 분리가 되어 있지 않기 때문에 이러한 구조로 할 필요가 있다.
- 그러나 GitOps는 CI와 CD를 분리하고 관리하기 때문에 클러스터를 변경하기 위해 Pull을 사용하여 자격 증명을 외부에 공개하지 않고 배포 할 수 있으므로 보안 위험을 줄일 수 있다.
GitOps Workflow
다음은 Weaveworks의 공식 블로그에서 소개된 GitOps 파이프라인의 다이어그램이다.
이 그림에서 알 수 있듯이, CI와 CD 모두 Git에서 코드를 관리하고 있지만 CI와 CD의 기능은 분리되어 있다.
GitOps Repository
GitOps Pipeline을 설계할 때에는 Git Repository를 일반적으로 Application 코드의 Repository와 인프라 환경 구성을 위한 Repository 2개로 구성하는 것을 권장한다.
출처: https://www.gitops.tech/#push-based-deployments
- Application Repository (Git Code)
- Application 소스 코드와 배포를 위한 Manifest 파일(배포 구성 파일, kubernetes yaml 등)을 포함한다.
- 인프라 환경 구성을 위한 Repository (Git Config)
- 배포 환경에 대한 모든 Manifest(모니터링, 서비스, MQ 등)들이 어떤 버전으로 어떻게 구성되어있는지 포함한다.
GitOps 배포 전략
GitOps에서는 Push 방식의 파이프라인과 Pull 방식의 파이프라인의 2가지 유형의 배포 전략이 있다. 두 가지의 유형의 차이점은 저장소에 있는 매니페스트와 배포 환경의 상태를 일치시키는 방법이다. 일반적으로 보안적으로 Pull 방식의 배포 전략이 비교적 안전한 방법으로 간주되어 선호 되고 있다.
최근에 사용되는대 부분의 CI/CD 도구는 Push 기반 모델을 사용한다. Push 기반 파이프라인은 코드가 CI 시스템으로 시작하여, 일련의 인코딩된 스크립트를 통해 경로를 지속적으로 ‘kubectl’을 직접 사용하여 변경 사항을 Kubernetes 클러스터에 Push를 할 수 있음을 의미한다.
CI 시스템에서의 배포 기능을 사용하거나, 명령줄에서 수동으로 수행하지 않으려는 이유는 자격 증명이 클러스터 외부에 노출될 가능성이 있기 때문이다. CI/CD 스크립트와 명령줄을 모두 보호할 수 있지만 클러스터의 신뢰 도메인 외부에서 작업하고 있다. 이는 일반적으로 좋은 방법이 아니며 CI 시스템이 생산을 위한 외부의 침입 방법으로 알려질 수 있기 때문이다.
Push Pipeline
Push 방식의 파이프라인는 Git Repo에 있는 Manifest 파일이 변경되었을 때, 배포 파이프라인을 실행시키는 구조이다.
출처: https://www.gitops.tech/#push-based-deployments
배포 환경의 개수에 영향을 받지 않으며, 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있다. 아키텍처가 쉬워 많은 곳에서 사용된다.
일반적으로 푸시 파이프라인는 클러스터 외부(CI)에서 읽기/쓰기(RW) 권한이 존재하게 되어, 보안정보가 외부로 노출될 수 있다는 단점이 있다.
출처: https://www.weave.works/technologies/gitops/#a-diy-gitops-pipeline
Pull based Pipeline
배포하려는 클러스터에 위치한 별도의 오퍼레이터가 배포 역할을 대신하는 구조이다.
출처: https://www.gitops.tech/#pull-based-deployments
해당 오퍼레이터는 Git Repo의 Manifest와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우, Git Repo의 Manifest를 기준으로 클러스터를 유지시켜 준다.
Pull 방식의 파이프라인는 GitOps 도구에서 이미지를 가져오고 자격 증명은 클러스터 내부에 보관되어, 보안 정보가 외부에 노출되지 않고 실행할 수 있다.
그림: https://www.weave.works/technologies/gitops/#a-diy-gitops-pipeline
GitOps 도구
현재 많이 사용되는 도구는 3가지이다.
Argo CD
- Arogo CD에서는 알기 쉬운 GUI를 제공한다.
- 수동 Sync 등 모든 조작을 GUI에서 할 수 있다.
- 관련 사이트
Flux CD
- GitOps를 제시한 Weaveworks사의 도구로 제작이 간단하고 경량이지만, GUI를 제공하지 않는다.
- 관련 사이트
- 소스 코드 : https://github.com/fluxcd/flux2
- 관련 문서 : https://fluxcd.io/flux/
Jenkins X
- 유명한 Jenkins에서 나온 도구로, 이 도구에서는 CI/CD에 대응한 파이프라인 자체를 구축 가능하다.
- Argo CD, Flux CD는 CD만 가능하다.
- 자유도가 높지만, 그만큼 아키텍쳐가 복잡하기 때문에 학습 비용도 높다.
- 관련 사이트
- 소스 코드 : https://github.com/jenkins-x/jx-cli
- 관련 문서 : https://jenkins-x.io/v3/about/