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 로 변경된다.

Push-based Deployments


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 와 일치시키는 작업을 실행한다. 

Pull-based Deployments

또한 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/

댓글

이 블로그의 인기 게시물

About JVM Warm up

About idempotent

About Kafka Basic

About ZGC

sneak peek jitpack

Spring Boot Actuator readiness, liveness probes on k8s

About Websocket minimize data size and data transfer cost on cloud

About G1 GC

대학생 코딩 과제 대행 java, python, oracle 네 번째