About GitOps

 GitOps 란 무엇인가?

cloud native application 의 CD(Continuous Deployment) 의 구현 방법이다. infrastructure 을 운영할 때 Git 을 포함한 CD tools 을 포함하여 이미 개발자들에게 친숙한 tools 을 사용하는 방법을 통해서 개발자 중심적인 경험에 초점을 두고 만들어졌다. 

GitOps 의 가장 중심적인 개념은 아래의 3가지이다.

1. automated process (자동화된 프로세스)
2. 현재 infrastructure 상태의 declarative descriptions (선언적인 상세)
3. Git repository 

Git repository 는 production 환경에서 현재 infrastructure 의 상태를 기술하는 declarative description 가지며 자동화된 프로세스를 통해서 실제 infrastructure 가 관리된다.

새로운 application 또는 기존의 application 을 update 할 경우, Git repository 을 update 함으로써 infrastructure 를 변경한다. 또한 이는 자동화된 프로세스로 모든것이 이루어진다.

그렇다면 왜 GitOps 를 사용해야 하는가?

더 빠른 그리고 더 자주 배포할 수 있다.

모든 CD technology 는 배포성에 대해서 장점으로 말한다. 하지만 GitOps 가 특별한 점은 배포를 위해서 CD tools 변경이 필요없다는 점이다. 모든것이 VCS (version control system) 을 통해서 이루어진다.

쉽고 빠른 Error Recovery

GitOps 는 모든 infrastructure 의 변경 내역이 Git repository 에 관리된다. 또한 error recovery 를 위해서 git revert 를 진행하고 복구되는 것을 지켜보기만 하면 된다.

쉬운 Credential 관리

오직 Git repository 와 image registry 만 필요하다. 개발자가 직접 production 운영환경에 접근할 필요가 전혀 없다.

배포의 자체 문서화

server 에 SSH 를 통해서 접속하고 무엇이 작동중인지 궁금할 것이다. GitOps 를 사용한다면, 어떤 환경에서든 일어나는 모든 변화는 Git repository 를 통해서 일어난다. 따라서 master 혹은 main 브랜치를 확인한다면 현재 배포된 내역을 자체적으로 문서화가 되고 또한 모든 변경에 대한 내역을 확인할 수 있다. 또한 모든 변경에 대한 감사를 공짜로 할 수 있다.

팀의 공유 지식이 된다.

Git 을 통해서 배포된 현재 시스템의 문서화는 팀의 모든 구성원들에게 시스템 발전을 모두가 쉽게 공유할 수 있다. 잘 작성된 Commit 메시지를 통해서 팀원 누구나 infrastructure 변경에 대해 프로세스를 재현하고 새로운 시스템을 정의하는 방법에 대한 예를 쉽게 찾을 수 있다.

GitOps 는 어떻게 작동하는가?

Environment Configurations as Git repository

GitOps 는 code repository 들을 중심 요소로써 배포 프로세스를 조직한다. 

최소 2개의 repository 가 있어야 한다.

1. application repository - application 의 source code 와 배포를 위한 deployment manifests 를 포함한다.

2. environment configuration repository - 현재 유지하려고 하는 배포 환경의 infrastructure 를 구성하는 모든 deployment manifests 를 포함한다. (message broker, service mesh, monitoring tool, etc...)

Push-based vs. Pull-based Deployment

GitOps 를 구현하는 두 가지 배포 전략이 있다. 

Push-based Deployments

주로 대중적인 Jenkins, CircleCI, Travis CI 와 같은 CI/CD tool 을 이용한다. application 의 source code 와 배포를 위한 Kubernetest YAMLs 이 application repository 에 같이 존재한다. source code 가 변경될 때 마다, build pipeline 이 trigger 되며, container image 를 build 하고 최종적으로 environment configuration repository 가 새로운 deployment descriptors 로 변경된다.

environment configuration repository 의 변경은 deployment pipeline 의 trigger 가 된다. 해당 pipeline 은 모든 environment configuration repository 에 있는 모든 manifests 가 infrastructure 에 반영되는 것을 담당한다. 해당 방식을 사용하게 되면 Build Pipeline 에 많은 권한을 가지게 된다. 따라서 Push-based 방식을 사용할 경우 보다 배포를 할 수 있는 권한에 대해서 세분화 된 인증과 인가 시스템을 갖출 필요가 있다.

또 명심해야 할 것은 Deployment Pipeline 은 Environment Repository 가 변경될 때만 실행된다는 것이다. 따라서 원하는 환경과 실제 환경이 불일치 하는 것을 방지하기 위해서 모니터링을 할 수 있는 툴이 별도로 필요하게 된다. 

Pull-based Deployments

Pull-based 방식은 Push-based 방식과 유사하지만 차이점은 Deployment Pipeline 이 동작하는 방식이다. 전통적인 CI/CD Pipeline 들은 외부 이벤트로 인해서 실행된다. 예를 들어, 새로운 코드가 application repository 에 push 되었을 때 실행된다. Pull-based deployment 방식은 Operator 가 도입된다. Operator 는 Pipeline 의 역할을 하며 지속적으로 environment repository 에 기술된 원하는 상태와 실제 배포된 상태를 비교한다. 실제 상태와 environment repository 의 기술된 상태가 다른것을 감지할 때마다, Operator 는 실제 상태를 environment repository 와 일치시키는 작업을 실행한다. 

또한 environment repository 에 기술된 manifest 가 아닌 변경에 의해서 Operator 는 자동으로 해당 변경을 revert 하는 역할을 함으로써 environment repository 기술된 manifest 상태를 유지한다. 이러한 Operator 의 역할로 인해서 현재 상태가 오직 environment repository 의 변화를 통해서만 이루어진다는 것을 보장해준다. 따라서 cluster 의 직접적인 변경은 불가능해진다.

대부분의 Operator 는 mail 이나 slack notification 을 지원한다. 어떤 이유로든 environment repository 의 manifest 상태와 다를 경우 설정한 mail 혹은 slack 알람을 받도록 설정할 수 있다.

해당 방식을 지원하는 대표적인 Operator 로 ArgoCD, Jenkins X 와 weave 에서 만든 flux 를 들 수 있다.

참고

gitops.tech

https://argo-cd.readthedocs.io/en/stable/

https://jenkins-x.io/

https://www.weave.works/oss/flux/