Git Ops

회사 깃허브를 둘러보더가 Git Ops라는 개념이 궁금해서 정리하려고 한다. 

 

참고

Git Ops

코드 실행과 배포, 운영에 관련된 정보들을 모두 Git으로 관리하는 것입니다. 이전에 공부한 Terraform은 인프라를 프로비저닝 하는데 Git ops는 인프라에서 애플리케이션 범위로 확장한 것이다. 

 

- 배포에 관련된 모든 정보 파일들을 따로 config Repository로 만들어서 관리한다. 

- config Repository의 내용과 운영환경 사이의 차이가 없도록 유지시켜주는 것이 중요하다. 

 

 

Git Ops 저장소 전략

최소 2개 이상의 Git 저장소를 사용한다. 

 

- 개발중인 저장소:

- 배포환경 관련 저장소: 인프라 서비스를 어떻게 구성되고 있는지 어떤 버전을 사용하는지 등등의 정보가 들어있다.

 

배포 방식

 

깃 옵스에서는 Push Type, Pull Type, 두가지 배포 전략이 존재한다. 둘다 공통적인 점은 현재 배포중인 환경과 작성한 배포 파일의 환경을 동일하게 만들어주는 것이다.  그 방식에는 두가지가 있는데 Push Type과 Pull Type이다. 

 

Push Type

Push Type은 저장소의 있는 정보가 변경되었을 때 배포 파이프라인을 실행시키는 구조이다. 단순히 깃 허브에 푸쉬가 되었을 때 변경된 내용을 바탕으로 Jenkins, Cricle CI 등을 이용해 배포중인 서버를 변경하는 방법입니다. 

 

Pull Type

Pull Type은 Push 되었을 때 파이프 라인을 실행시키는 것이 아닌 오퍼레이터라는 것이 배포 환경과 git hub 저장소의 내용을 지속적으로 비교하며 관찰합니다. 변경된 정보를 확인하면 배포 서버 환경을 이와 같이 유지하려고 합니다. 이러한 방식을 지원하는 도구는 Argo CD, Jenkins X 등이 있습니다. 

 

전체적으로 보안상의 이유로 Pull Type을 제공한다고 합니다. Push Type의 경우 결국엔 배포환경에 대한 모니터링, 자격증명 정보를 외부에서 관리할 수 밖에 없습니다. 또한 이러한 정보들이 외부에서 노출 될 수도 있기 때문에 조심해야한다. 

 

반면 PullType의 오퍼레이터는 실행되는 서버의 환경과 동일한 곳에서 실행되기 때문에 외부로 노출될 일이 줄어들 것입니다.

 

장점

- git을 통한 정보공유

깃을 사용하면 어떤 사람이 어떤 코드를 어떻게 수정했는지 기록별로 모두 확인할 수 있기 때문에 간편하게 소스코드의 개발 내용을 공유할 수 있습니다. 

 

 

- 개발자에게 익숙한 절차

git commit -> push -> merge request -> review -> merge라는 개발자에게는 정말로 익숙한 절차로 동일하게 진행되기 때문에 

특별한 교육 및 리뷰를 통해 문제를 체클할 수 있습니다. 다음에는 회사에서 사용해보고 직접적인 사용기를 작성해보겠습니다.