신입이 이해한 GitOps

GitOps에 대한 글을 정리해서 작성해보려 합니다.

 

잘못된 내용이 있을 수 있으며, 발견하신 분은 정정해주시면 감사하겠습니다!

 

 

 

GitOps란?

 

내용을 찾아보고 내가 내린 정의는 다음과 같다.

 

→ Git 저장소를 사용하여 인프라 및 애플리케이션 배포를 자동화하고 관리하는 DevOps 관행

 

 

 

DevOps : 개발 + 운영 / 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 개발 문화 및 환경

 

 

 

사실 DevOps에 대한 개념의 이해는 게시글 하나를 따로 작성해야할 정도의 깊이있는 이해와 경험이 필요한 것 같다.

일단 여기서는... 짧은 문장으로 대체하겠다.

굳이, 한 문장으로 정리하자면 내가 DevOps를 정의하자면 저렇다는 것이다.

 

 

 

 

GitOps 핵심 개념

 

GitOps를 누군가에게 설명하고자 할 때, 나는 GitOps의 2가지 핵심 개념이자 특징에 대해 설명할 것이다.

 

1. 선언형 모델

• 명령형 모델은 간단한 대신 발생할 수 있는 예외 상황을 모두 고려해야 한다.
• 반면, 선언형 모델은 코드 형태로 세부 내용을 작성하기만 하면 된다.
  • ex) 디렉토리의 존재 여부, OS에 따라 다른 명령어
• 인프라를 포함한 애플리케이션의 배포와 운영에 관련된 모든 것들을 코드로 관리할 수 있게 된다.
  • → 코드를 이용하여 언제든 동일한 환경을 다시 만들어 내거나 복원이 가능하다.

 

 

 

이해가 안된다면 다음의 예시를 보자.

 

 

선언형 모델 예시 : k8s (kubernetes)의 YAML 파일

 

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx:latest

 

 

해당 YAML 파일이 어떤 내용인지는 중요하지 않다. 단지, YAML 파일과 같이 어떤 상태나 구성을 간단하게 정의하여 구축할 수 있다는 것이 선언형 모델의 특징이다.

 

 

 

 

 

명령형 모델 예시

 

kubectl create deployment mypod --image=nginx:latest

 

 

간단하게 생각하면 그냥 명령어라고 생각하면 된다.

 

선언형 모델과의 차이점을 생각하면, 선언형 모델은 YAML 파일로 어떤 어플리케이션을 배포하기 위해서 요구되는 계층구조나 디렉토리, OS 등 환경에 대한 고려는 오직 YAML파일에 '선언' 하는 것으로 끝낼 수 있다.

 

그러나, 명령의 모델로 선언형 모델의 배포와 같은 동작을 하기 위해선, 디렉토리를 생성하고, 이동하고, 같은 경로에 디렉토리나 파일 이름이 이미 존재하는지, OS는 어떤 환경인지... 등 다양한 요소를 고려해야하고, 모두 내가 명령해야 한다.

 

 

 

 

 

 

 

2. 단일 진실 공급원 (SSOT)

• Git을 단일 진실 공급원으로 지정하고 오직 Git에서만 관리하도록 한다.
  • ex) 데이터 정규화 작업 → 테이블의 중복되는 열을 제거하고 다른 테이블을 참조하게 하는 과정
• Git의 강력하고 익숙한 기능을 개발 뿐만 아니라 운영에서도 활용이 가능하게 된다.

 

다 필요없고, 오직 Git 저장소 (진실 공급원) 에만 의존하고, 해당 저장소의 상태와 동일한 상태를 유지하겠다는 것이다.

 

개발자들에게 익숙한 Git 기능을 어떤 서비스를 운영하는데, 적극 활용할 수 있다는 것은 큰 이점일 것이다.

 

 

 

 

GitOps 배포 파이프라인

GitOps 배포 파이프라인은 push 방식과 pull 방식이 존재한다.

 

push

 

push 방식

 

• 저장소의 코드가 업데이트 혹은 manifest file의 변경에 감지되었을 경우처럼 외부 이벤트에 의해 배포 파이프라인이 트리거 되는 방식
• Jenkins, Travis CI, Circle CI 등의 도구

manifest file : 애플리케이션 또는 인프라 구성을 정의하고 설명하는 파일 / YAML, JSON 형식으로 작성된다.

위쪽의 선언형 모델로 예시로 든 YAML 파일이 manifest file이다.

 

 

 

 

 

 

pull

pull 방식

 

• Git 저장소와 실제 환경을 비교하는 Operator가 배포 파이프라인을 대신한다.
• 저장소와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소 기준으로 배포 환경을 유지해준다.
• 모든 이력은 Git에 존재하게 된다.
• ArgoCD, JenkinsX, Flux 등
• 배포 환경에 대한 자격 증명 정보를 외부에서 관리할 수 밖에 없는 Push 방식에 비해 보안상 안전하다.

 

 

 

위 내용이 이해가 잘 안가는 분들에게 쉽게 설명한다하면,

 

 

 

push 방식은 배포 환경에 직접 변경 사항을 외부에서 밀어 넣는다면(push)

배포 주체가 외부에서 배포 환경에 변경사항을 밀어 넣는다. (push)

 

 

 

 

pull 방식은 배포 환경에 존재하는 Operator가 외부 저장소와 배포 환경과의 차이를 감지하고, 외부 저장소의 변경 사항을 자체적으로 끌어온다(pull)는 점이다.

 

배포 환경 내부에 위치한 배포 주체가 외부 저장소의 변경을 감지하고 이를 반영한다. (pull)

 

 

 

 

 

GitOps에 대한 게시글은 여기까지 작성하도록 하겠습니다.

네, 제가 이해한 바는 여기까지라는 점이고...

이 글을 보시고 GitOps가 어떠한 느낌인지 감을 잡으신 분들이 계신다면, 제 게시글은 성공적이었다고 봅니다.

 

 

이후에는 GitOps 도구인 ArgoCD나 DevOps, CI/CD...? 에 대한 게시글을 작성할지도?

라고는 말했지만, 솔직히 이론과 개념 위주인 내용이 많아서 작성한다면 관련 도구에 대한 내용을 작성할 것 같습니다.