GitOps란?

GitOps (https://www.weave.works/technologies/gitops/)

정의

GitOps는 버전 관리, 협업, 규정 준수, CI/CD 등 애플리케이션 개발에 사용되는 DevOps 모범 사례를 인프라 자동화에 적용하는 운영 프레임워크

 

왜 사용하는가?

• 소프트웨어 개발 라이프사이클의 대부분은 자동화 되었지만 인프라는 여전히 전문 팀이 필요한 수동 프로세스로 남아있다.
• 오늘날 인프라 자동화를 구현하는 것이 점점 더 중요해지고 있으며, 최신 인프라는 지속적인 배포에 필요한 클라우드 리소스를 효과적으로 관리할 수 있도록 탄력적이여야 한다.
• 데브옵스 팀은 GitOps를 이용해 클라우드 네이티브 애플리케이션의 속도와 확장성을 염두에 두고 개발을 진행한다.
• GitOps는 인프라, 특히 최신 클라우드 인프라를 프로비저닝하는 프로세스를 자동화하는 데 사용된다.
• 팀이 애플리케이션 소스 코드를 사용하는 방식과 유사하게 GitOps를 도입한 운영팀은 코드로 저장된 구성 파일을 사용한다.(IaC)
• 애플리케이션 소스 코드가 빌드될 때마다 동일한 애플리케이션 바이너리를 생성하는 것처럼, GitOps 구성 파일은 배포될 때마다 동일한 인프라 환경을 생성한다.
• GitOps는 단일 제품, 플러그인 또는 플랫폼이 아니다. 팀의 구체적인 요구 사항과 목표에 따라 GitOps를 실행하는 방법은 달라질수 있어 정답은 없다.
• 하지만 모든 팀원이 구성 및 코드를 공유할 수 있는 전용 GitOps 리포지토리를 사용하고, 코드 변경 사항의 배포를 자동화하며, 변경 사항이 발생했을 때 팀에 알리는 알람 설정하는 등으로 GitOps를 시작할 수 있다.
• GitOps에는 세 가지 핵심 구성 요소가 필요하다.
  • IaC
    • GitOps는 소스 코드 관리를 Git 리포지토리를 사용한다.
    • Git은 코드 관리 변경 사항을 추적하는 오픈 소스 버전 제어 시스템이며, Git 리포지토리는 시간이 지남에 따라 프로젝트의 파일에 적용된 모든 변경 사항을 추적하는 프로젝트 내 .git 폴더이다.
    • IaC는 모든 인프라스트럭처 구성을 코드로 저장하는 방식이다. 실제 원하는 상태(예 : 리플리카 또는 파드 수)는 코드로 저장될 수도 있고 저장되지 않을 수도 있다. (코드로 저장하는 것이 좋음)
  • MRs (Merge Requests) 또는 PRs (Pull Requests)
    • 모든 인프라 업데이트에 대한 변경 메커니즘으로 병합 요청 또는 풀 리퀘스트를 사용한다.
    • MR 또는 PR은 팀이 검토와 댓글을 통해 협업할 수 있고 공식적인 승인이 이루어지는 곳
    • 병합은 메인(또는 트렁크) 브랜치에 커밋되며 감사 로그 또는 감사 추적 역할을 한다.
  • CI/CD
    • CI/CD와 함께 Git 워크플로를 사용하여 인프라 업데이트를 자동화한다.
    • 새 코드가 병합되면 CI/CD 파이프라인이 환경의 변경 사항을 적용한다.
    • 수동 변경이나 오류와 같은 모든 구성 변동은 GitOps 자동화를 통해 덮어쓰기 되어 클라우드 또는 원하는 환경이 Git에 정의된 상태로 수렴된다.
    • Gitlab 또는 Github action과 같은 것들로 이를 제공할 수 있다.

 

장단점

• 장점 :
  • 단일 통합 도구를 사용해 전체 인프라 및 애플리케이션 개발 수명 주기를 관리할 수 있다. 이를 통해 팀 간의 협업이나 조정을 강화하고, 오류를 줄여 문제를 더 빠르게 해결할 수 있다.
  • 조직이 컨테이너와 마이크로서비스를 활용하고 Kubernetes 클러스터 구성과 Docker 이미지부터 클라우드 인스턴스 및 온프레미스까지 모든 인프라에서 일관성을 유지할 수 있도록 도와준다.
  • GitOps 환경에서 프로덕션 환경이 다운되더라도 git revert 명령어를 수행하면 손 쉽게 환경이 복원된다.
  • 배포 속도를 높이고 보다 자주 배포할 수 있게 해준다. GitOps를 통해 이전에 형상관리 하고 있던 방식 그대로를 사용하여도 실제 환경에 배포가 자동으로 된다. 따라서 개발자는 배포 결과를 즉시 확인하고 보다 나은 방식을 다시 적용할 수 있다.
  • 자격 증명 관리가 쉽다. 실제 환경을 접속하고 kubectl 명령어로 실행하지 않아도 접근 권한을 부여할 수 있어 보다 안전하다.
• 단점 :
  • 학습 곡선 : Git 및 버전 제어 및 GitOps 워크플로우에 사용되는 관련 도구에 익숙하지 않은 경우 새로운 도구와 개념을 배워야한다.
  • 단일 실패 지점 : Git에서 문제가 발생해 가동 중지 시간이나 데이터 손상과 같은 문제는 전체 배포 프로세스에 심각한 영향을 미칠 수 있다.
  • 보안 문제 : Git 리포지토리에 비밀 및 자격 증명과 같은 민감 정보를 배치하면 보안 위험이 발생할 수 있다.
  • 드리프트 가능성 : Git 저장소 외부의 클러스터를 직접 수동으로 변경하는 경우 시스템의 실제 상태가 Git 저장소에 정의된 원하는 상태와 달라지는 구성 드리프트가 발생할 위험이 있다.

 

DevOps와의 차이점

• GitOps는 코드 변경 사항을 관리하고 배포하기 위해 자동화 및 도구에 크게 의존하는 반면, DevOps는 팀 간의 커뮤니케이션과 혐업에 더 중점을 둔다.
• GitOps는 일반적으로 Kubernetes와 같은 컨테이너화 기술과 함께 사용되는 반면, DevOps는 모든 유형의 애플리케이션에 사용 가능하다.
• GitOps는 Git 리포지토리가 배포 상태에 대한 신뢰할 수 있는 소스인 반면, DevOps는 애플리케이션 또는 서버 구성 파일이라는 점에서 다르다.

 

내 생각

• Git을 중점으로 Git 소스에 있는 코드를 인프라에 그대로 반영하게 되는 CD에 가까운 프레임워크
• Git에서 코드 변경 사항이 생길 시 코드를 바라보고 있던 CI/CD가 작동해 인프라에 배포하게 됨
• 세 가지 핵심 구성 요소가 필요하다.
  • IaC
  • MRs PRs
  • CI/CD
• Application을 단순히 Git으로만 관리하게 된다면 GitOps를 사용하는 것이 굉장히 좋아보인다. 어차피 IaC로 많이 넘어가고 있고 형상관리는 필수적이기 때문에
• 그런데 참조글을 읽던 중 SPOF에 대해 우려하는 의견이 있었다. 나도 어떻게 해결할지 궁금하다.

 

[참조] :

https://blog.kico.co.kr/2022/04/25/gitops-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0/

https://about.gitlab.com/topics/gitops/

https://www.gitops.tech/