Ooops? GitOps!

“꼭 안 좋은 예감은 100% 맞다”

인프라 설정에 권한이 있는 사람이 그 날 따라 “ 시키지도 않은 작업까지 + 창의적으로 + 욕심을 더 내어서 + 서둘러” 작업을 하다보면… 인프라 환경에 문제를 발생 시키기도 한다.

게다가 인프라에 대한 변경 기록이 없거나 있다고 하더라도 이메일과 메신저 등에 파편적으로 있거나, 기안서 속에 변경 버전 별로 짧게 변경할 사항만 기록이 되었다면 변경 전 상태로 되돌리기는 어려워진다.

등에 땀 줄기가 흐르고, 주변에 병풍이 쳐진다.

인프라 담당 인원수에 적당한 서버와 ‘변화와 장애 요소가 거의 없는 운영’을 하고 있고 있으면 다행이지만, 점점 관리해야 할 서버의 대수가 증가하고, 인프라 관리자의 권한을 타부서와 공유해야 하고 잦은 배포가 발생하게 되면 문제가 발생할 수 있는 접점이 많아진다. DevOps를 접목하게 되면 인프라 운영팀과 각 개발팀과 필연적으로 권한을 공유해야 하고 인프라 변경에 대한 기록과 장애 발생 시 변경 전으로 되돌리기 위한 준비도 필수적이게 된다. DevOps 라는 발전적인 변화에 대처한다는 것 뿐만 아니라 단순히 운영자의 부재나 이직으로 인해 인수인계가 발생하는 할 때에 사람의 기억과 파편화된 문서로는 0000년 00월 00일 시점의 버전으로 되돌리는 것은 너무 많은 에너지를 소모하게 되거나 불가능 할 수도 있다.

지금은 상상할 수도 없지만 여러 개발자가 동일한 개발 소스로 개발하기 위해서 중간중간 소스를 비교하며 소스를 합치는 시절이 있었다. 개발자 한 명에게 몰아줄 수도 없으니 필요하지만 빠듯한 일정에 마이너스가 되는 시간이었다. 그러다가 소스 버전을 관리해주는 기술들이 등장했고 그 중에 하나가 Git이다.

기록이 되고 COMMIT하여 버전 별로 저장이 되는 Git의 특성을 인프라의 관리에 적용하게 되었다.

“사람이 수작업으로 서버 환경을 변형하는 것을 원천적으로 차단한다”

GitOps란?

애플리케이션의 배포와 운영에 관련된 모든 요소를 코드화하여 Git에서 관리(Ops)하는 것이 GitOps의 핵심이다. 기본 개념은 코드를 이용하여 인프라를 프로비저닝 하고 관리하는 IaC(Infrastructure as Code)에서 나온 것으로 GitOps는 이를 인프라에서 전체 애플리케이션 범위로 확장했다. GitOps는 어디까지나 방법론이기 때문에 정해진 도구가 따로 없다.

GitOps는 Git을 선언적 인프라 및 애플리케이션에 대한 단일 정보 소스(Source Of Truth, SOT)로 사용하는 방식으로 작동한다. GitOps는 Pull Request를 사용해 인프라 프로비저닝 및 배포를 자동으로 관리한다.

GitOps 시작

선언형 모델(Declarative Model)

GitOps를 시작하려면 선언적으로 관리할 수 있는 인프라가 필요하다. 이러한 특징 때문에 GitOps는 쿠버네티스 및 클라우드 네이티브 애플리케이션 개발을 위한 운영 모델로 사용되는 경우가 많고 쿠버네티스에 대한 지속적 개발을 지원할 수 있다.

Ansible은 쿠버네티스처럼 전통적인 IT 시스템의 선언적 모델링을 지원하는 원하는 상태 엔진이다. 그래서 GitOps에 사용할 수 있다.

단일 진실 공급원(Single Source Of Truth, SSOT)

Git을 단일 진실 공급원으로 지정하고 이 곳에서만 관리하도록 한다. 모든 운영 활동의 시작은 Git이므로 사람 혹은 시스템 간의 혼선을 최소화 할 수 있다. 그리고 개발 단계에서만 누릴 수 있었던 Git의 기능을 운영 단계에서도 활용할 수 있게 된다. (History, Commit, Merge Request/ Review, Revert 등)

GitOps 장점

일반적인 devops의 장점으로 배포 빈도 및 속도 상승, 생산성 향상, 오류 감소 등이 있다.

• 신뢰할 수 있는 설정 정보의 공유

  • 배포된 서버에 직접 접속하지 않고 변경 점에 대해 누가,언제,왜, 어느 곳을 수정했는지 알 수 있다.

• 계획되지 않은 변형을 원천 차단

  • 수작업으로 갑작스럽게 인프라를 변형하는 것을 예방할 수 있다.

  • 작업 기록이 없는 사고를 예방 할 수 있다.

• 익숙한 절차

  • ‘git commit → push → merge request → review → merge’ 개발자에게 익숙한 절차이다.

GitOps 적용

풀 타입 구현체 중 하나인 아르고CD를 이용하여 깃옵스 시스템을 소개한다.

Pull Type: 배포 환경에 위치한 별도의 오퍼레이터가 배포 파이프라인을 대신한다. 이 오퍼레이터는 저장소의 매니페스트와 배포 환경을 지속적으로 비교하다가 차이가 발생할 경우 저장소의 매니페스트를 기준으로 배포 환경을 유지시켜 준다.

Argo: 쿠버네티스 리소스들의 현 상태를 사용자가 원하는 상태로 유지하려고 하는 지속적인 배포 도구이다.

저장소에 있는 배포 관련 정보를 수정했을 때 argoCD가 배포 환경(Kubernetes)에 변경 사항을 잘 반영하는지도 확인하는 예제이다

GitOps Ansible 방식

Ansible webhook을 사용하여 agent가 필요 없는 방식으로 인프라를 관리할 수 있다.

• Kubernetes를 넘어선 GitOps

• 에이전트 없는 GitOps

• 유연성과 자유

• 기존 기술 및 생태계

참조 사이트

https://www.ansible.com/blog/ops-by-pull-request-an-ansible-gitops-story