Judaeng
GitOps 알아보기 본문
Argo CD를 내 프로젝트에 적용하기 위해 GitOps을 공부했다.
GitOps를 공부하기 위해 블로그, 문서 등을 이용해서 정리했다. 틀린 게 있다면 댓글로 피드백은 항상 환영입니다😄
GitOps가 머야?
GitOps는 위브웍스(Weaveworks Inc.)에서 처음 사용한 용어로 프로젝트에 데브옵스를 적용하는 실천 방법 중 하나이다.
GitOps는 DevOps의 실천 방법 중 하나로 애플리케이션의 배포와 운영에 관련된 모든 요소들을 Git에서 관리(Operation) 한다는 뜻이다.
GitOps는 제어 시스템의 오픈소스 버전인 Git를 사용해 인프라 및 애플리케이션 구성을 관리하기 위한 일련의 사례라고 한다.
GitOps는 Git를 선언적 인프라 및 애플리케이션에 대한 단일 정보 소스(Source Of Truth, SOT)로 사용하는 방식으로 작동한다고 한다.
GitOps는 Git 풀 요청을 사용해 인프라 프로비저닝 및 배포를 자동으로 관리한다.
Git 리포지토리에는 전체 시스템 상태가 포함되어 있어 시스템 상태의 변화 추이를 확인하고 감사할 수 있다.
GitOps는 개발자 경험을 중심으로 구축되어 있으며, 따라서 소프트웨어 개발에 사용하는 것과 동일한 툴 및 프로세스로 인프라를 관리할 수 있다.
GitOps에서는 Git 외에도 필요한 툴을 선택할 수 있다.
GitOps는 Kubernetes Manifest 파일을 Git에서 관리하고, 배포할 때에도 Git에 저장된 Manifest로 클러스터에 배포하는 일련의 과정들을 의미한다.
* 단일 진실의 원천(SOT): 어떠한 진실(결과)의 원인이 오직 단일한 원천(이유)에서 나왔다는 것을 의미한다.
"단일 진실의 원천" 방법의 장점
1. 현재 배포환경의 상태를 쉽게 파악할 수 있다.
배포 환경에 들어가서 상태를 파악할 필요 없이 원천(배포 작업서)만 살펴보면 되기 때문이다.
2. 빠르게 배포할 수 있게 된다.
단일한 방법으로 소프트웨어를 배포하여 표준화시켰기 때문에 쉽게 배포 자동화를 할 수 있고 이것은 더 빠르고 지속적인 배포를 가능하게 한다.
3. 안정적으로 운영 환경에 배포할 수 있다.
사람의 손을 거치지 않기 때문에 운영 반영에 발생할 수 있는 Human Error를 최소화할 수 있다.
배포를 관장하는 사람은 원천의 상태만 잘 확인하면 된다고 한다.
더 자세한 내용을 보고 싶다면 여기를 참고하면 된다.
GitOps 워크플로우란?
GitOps는 인프라 구성을 위해 Git을 버전 제어 시스템으로 사용하는 코드형 인프라(IaC)가 진화한 것이라고 생각하면 된다고 한다.
IaC는 원하는 시스템 상태를 정의하고 시스템의 실제 상태를 추적하여 인프라 관리에 대한 선언적 접근 방식을 따르는 경우가 많다고 한다.
CI/CD 파이프라인은 리포지토리로 푸시되고 있는 코드와 같은 외부 이벤트에 의해 트리거 되는 것이 보통이다.
GitOps 워크플로우에서 변경 작업은 Git 리포지토리에서 상태를 수정하는 풀 요청을 사용해 이루어진다고 한다.
GitOps 워크플로우를 사용해 새 릴리스를 롤 아웃하기 위해 Git에서 풀 요청이 이루어지고, 이를 통해 선언된 클러스터 상태가 변경된다.
GitOps 파이프라인과 오케스트레이션 시스템 사이에 위치한 GitOps 운영자는 Git에서 커밋을 선택하여 새로운 상태 선언으로 풀링 한다.
변경사항은 승인되고 병합된 후 라이브 인프라에 자동으로 적용된다고 한다.
개발자는 표준 워크플로우 및 지속적인 통합/지속적인 서비스 제공 사례를 계속 사용할 수 있다고 한다.
GitOps를 쿠버네티스와 함께 사용할 때 운영자는 흔히 쿠버네티스 오퍼레이터의 역할을 하게 된다고 한다.
운영자는 리포지토리의 원하는 상태를 배포된 인프라의 실제 상태와 비교한다.
운영자는 실제 상태와 리포지토리 상황 사이에 차이점이 발견될 때마다 인프라를 업데이트한다.
운영자는 컨테이너 이미지 리포지토리를 모니터링하고 새 이미지를 배포하는 방식으로 업데이트를 수행할 수도 있다.
관측 가능한 모든 시스템을 가리키는 관측성은 GitOps에서 중요한 개념이라고 한다.
GitOps의 관측성을 바탕으로 원하는 상태와 관찰된 상태(또는 실제 상태)가 동일한지 확인할 수 있다.
풀 요청과 Git과 같은 버전 관리 시스템을 사용하여 배포 프로세스를 파악할 수 있다.
이를 통해 모든 시스템 변경 사항을 확인 및 추적할 수 있고, 감사 추적이 가능하며, 문제가 생기면 변경 사항을 롤백할 수도 있다.
GitOps 워크플로우로 생산성과 개발 및 배포 속도를 높이는 동시에 시스템의 안정성 및 신뢰성을 향상할 수 있다.
* GitOps 워크플로우에 GitOps의 장점과 어떻게 사용되는지가 다 적혀있다.
GitOps의 원칙
GitOps는 특정 소프트웨어나 프로덕트가 아닌 철학 혹은 방법론에 더 가깝다고 한다.
1. 모든 시스템은 선언적으로 선언되어야 한다.
“선언적(declarative)”이라 함은 명령들의 집합이 아니라 사실(fact)들의 집합으로 구성이 되었음을 보장한다는 의미이다. 쿠버네티스의 manifest들은 모두 선언적으로 작성되었고 이를 Git으로 관리한다면 versioning과 같은 Git의 장점과 더불어, SSOT(Single Source Of Truth)를 소유하게 된다.
2. 시스템의 상태는 Git의 버전을 따라간다.
Git에 저장된 쿠버네티스 manifest를 기준으로 시스템에 배포되기 때문에 이전 버전의 시스템을 배포하고 싶으면 git revert와 같은 명령어를 사용하면 된다.
3. 승인된 변화는 자동으로 시스템에 적용됨
한 번 선언된 manifest가 Git에 등록되고 관리되기 시작하면 변화(코드 수정 등)가 발생할 때마다 자동으로 시스템에 적용되어야 하며, 클러스터에 배포할 때마다 자격증명은 필요하지 않아야 한다.
4. 배포에 실패하면 이를 사용자에게 경고해야 한다.
시스템 상태가 선언되고 버전 제어 하에 유지되었을 때 배포가 실패하게 되면 사용자에게 경고할 수 있는 시스템을 마련해야 한다.
GitOps Repository
GitOps PipeLine을 설계할 때에는 Git Repository를 최소 두 개 이상 사용하는 것을 권장한다.
- App Repo: App 소스코드와, 배포를 위한 Manifest 파일
- 배포 환경 구성용 Repo: 배포 환경에 대한 모든 Manifest(모니터링, 서비스, MQ 등)들이 어떤 버전으로 어떻게 구성되어 있는지 포함
나는 위에 GitOps PipeLine 사진을 보고, 이해한 뒤에 내 프로젝트 구성 어떻게 만들지 계획했었다.
GitOps 배포 전략
두 가지 방법이 있다고 한다.
1. Push Type
Git Repo가 변경되었을 때 파이프라인을 실행시키는 구조이다.
배포 환경의 개수에 영향을 받지 않으며 접속 정보를 추가하거나 수정하는 것만으로도 간단하게 배포 환경을 추가하거나 변경할 수 있다.
아키텍처가 쉬워 많은 곳에서 사용하고 있으나, 보안정보가 외부로 노출될 수 있다는 단점이 있다고 한다.
2. Pull Type
배포하려는 클러스터에 위치한 별도의 오퍼레이터가 배포 역할을 대신한다.
해당 오퍼레이터는 Git Repo의 Manifest와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우, Git Repo의 Manifest를 기준으로 클러스터를 유지시켜준다.
또한 Push Type과 달리 오퍼레이터가 App과 동일한 환경에서 동작중이므로 보안 정보가 외부에 노출되지 않고 실행할 수 있다.
한 줄 요약
쿠버네티스의 구성요소들을 관리하고 배포하기 위해서는 Manifest파일을 구성하여 실행해야 하는데 이러한 파일들은 계속해서 변경되기 때문에 지속적인 관리가 필요한데 이를 편하게 Git으로 관리하는 방식을 GitOps라고 한다.
GitOps를 실현시키며 쿠버네티스에 배포까지 해주는 툴이 Argo CD이다.
🤔 블로그 정리 후, 느낀 점
"GitOps 알아보기" 글을 작성하면서 느낀 점은 정말 아이러니하다.
현재 글을 쓰고 있는 글쓴이는 ArgoCD+MiniKube+Ngrok을 이용해서 배포를 해보았기 때문이다.
처음에는 ArgoCD를 간단하게 사용해보려고 목표를 잡았다.
근데 ArgoCD를 사용하려면 GitOps 방법이 무엇인지부터 알아야겠다는 생각이 들었다.
그래서 "GitOps가 머지?" 이렇게 시작했었는데 진입장벽이 개인적으로 너무 높다고 생각이 갑자기 들었다.
"내가 GitOps 방법을 적용시킬 수 있을까?" "Git Repo는 왜 만들어야 되지?" 등등 생각이 너무 많아졌다.
하지만 그때 상황에서 나는 하는 일이 별로 없었기 때문에, 공부만 주구장창 했다.🤮
머리로만 공부하다 보니, GitOps, ArgoCD를 내 프로젝트에 도저히 적용을 못 시킬 것 같았다...
그래서 하나씩 "그냥" 해봤다.
처음엔 Git Repo를 "그냥" 만들어보고, ArgoCD라는 기술 스택도 공식문서를 보는 것이 아니라, 보고 그대로 시도해보았다.
"실패해도 시도라도 해보자"라는 마음이었던 것 같다.
진짜 무슨 생각으로 했는지 기억은 안 나지만 "그냥"이라는 단어가 떠올랐다ㅋㅋ
ArgoCD를 Minikube에 적용시키고, 그것을 눈으로 볼 수 있는 GUI형태의 페이지로 내 배포된 애플리케이션을 확인해보니, 너무 신기하고 재밌었고, 기능으로 생각해도 너무 좋다고 생각이 들었다.
내 Git Repo에 yaml파일로 업로드한다. "나는 내 애플리케이션을 이렇게 배포할 거야!"라고 지정하는 것이다.
이렇게 지정한 yaml파일을 MiniKube에 ArgoCD라는 프레임워크를 통해 Sync라는 버튼을 눌러 배포되는 것을 보면 너무나도 신기하고 좋은 기능이었다.
누군가가 실수해서 배포했다면, Git Repo를 통해서 확인할 수 있고, 그 실수를 되돌리거나, 수정해서 다시 올릴 수도 있다는 것이 좋았다.
어쨌든 말이 너무 길어졌는데, GitOps에 대해서 진입장벽이 높았지만, 직접 내 애플리케이션을 배포하면서 공부하는 것이 제일 와닿는 공부법이라고 말하고 싶었던 것 같다.
개인적으로 성공했을 때 너무 기뻤고, 재밌었고, 장점을 깨달을 수 있어서 좋았다.
📝 이번 게시물을 만들기 위해 참고한 사이트
2. CI/CD(지속적 통합/지속적 제공): 개념, 방법, 장점, 구현 과정 - RedHat
5. GitOps와 Argo CD란? - 호롤리한 하루