Gitops?
Gitops는 Devops 방법론중 한가지로, Git을 사용해 인프라 변경상황 및 버전을 관리하는 방식입니다. Gitops 방식을 채택하여 인프라를 관리할 경우 모든 변경사항의 추적과 롤백이 쉬워지며, 인프라의 현재 상태를 실시간으로 확인할 수 있게 됩니다.
특히 다수의 개발자와 Sysops가 협업하는 경우 변경사항과 변경 요청을 명확하게 관리할 수 있습니다.
Gitops 환경을 구성하기 위해서는 선언적 인프라(Declarative Infrastructure) 가 우선적으로 전제되어야 합니다. 선언적 인프라는 인프라를 원하는 상태로 선언하고, 실제 인프라가 해당 상태로 유지되도록 하는것을 의미합니다.
이를 위해 상태 저장소(Config Repository) 를 구성하는것이 일반적이며, 상태 저장소에는 인프라의 현 상태를 정의하는 선언적인 코드들이 관리됩니다.
<이미지 출처 : https://rafay.co>
Stack for Gitops
Gitops를 구성하기 위해 필요한 요소는 크게 3가지로 나눌 수 있습니다.
- CI/CD Pipeline
- Infra Automation / IaC
- Git repository (Config Repository)
하나씩 설명을 해보자면, 우선 CI/CD 파이프라인은 선언적 인프라 코드의 변경사항이 자동적으로 테스트되고 인프라에 배포가 이루어져야 합니다.
두번째로 Infra Automation 및 IaC(Infrastructure as Code) 의 경우, 인프라를 코드로 정의하고 코드를 통해 인프라를 생성/관리/삭제 할 수 있도록 하는 기술입니다. 보통 클라우드 환경에서는 Terraform을 많이 사용하고, 온프레미스가 병합된 하이브리드 환경에서는 Ansible이나 Chef를 사용하는 경우도 많습니다.
세번째 Git repository는 위에서 짧게 언급한 상태저장소로, 모든 코드 및 인프라 변경사항은 깃 레포에 저장되어야 합니다. 이를 위해서 Git 레포지토리를 사용하게 되고 이는 Gitops의 가장 큰 장점인 변경사항의 빠른 트래킹과 롤백이 용이하다는 장점을 살릴 수 있도록 합니다.
Why Gitops?
Gitops 의 가장 큰 장점은 코드로써 인프라를 작성하고 Git을 통해 관리하게 되어 생기는 장점인 "롤백 용이성" 과 "변경이력 추적이 용이" 하다는 부분입니다.
부수적인 효과로는 IaC 를 사용하다 보니 인프라의 변경에 대한 검증과 배포를 더욱 효과적으로 자동화 할 수 있고, 이를 통해 개발자가 많은 시간을 쓰지않고 안정적인 배포를 구성할 수 있게됩니다.
Limit of Gitops & Hard way to gitops
현 시점에서 Gitops 의 가장 큰 한계는 복잡성과 보안성입니다.
초기 구축을 위해 많은 시간이 들어가고, 인프라의 규모가 커질수록 관리해야 하는 코드의 규모가 커지니 이에 대한 복잡도 또한 자연스럽게 높아질 수 밖에 없습니다.
여러 클라우드 벤더나 서버 유형을 사용하는 경우거나 모듈화된 인프라가 고려된 경우라면 상태저장소를 분할하여 관리할 수 있겠지만, 대부분의 경우에서는 인프라의 모듈화는 구성하기 어려운 경우가 많습니다.
또한 보안성의 관점에서 인프라를 코드로 정의하고 코드를 Git에 관리하기 때문에 비밀키가 포함된 환경변수의 공유 과정이나 내부 접근통제의 과정에서 보안문제가 발생할 수 있습니다.
이를 해결하기 위해서는 암호화와 비밀키 공유에 대한 적절한 절차 구성, 그리고 엄격한 접근 권한 관리가 필요합니다.
Nevertheless..
위에서 서술한 단점인 인프라 복잡도가 높아지고, 보안성에 상대적으로 단점이 있음에도 불구하고 Gitops는 여러 장점들로 인해 최근 많은 조직에서 채택되고 있는 Devops 방법론입니다.
위에 언급한 장점 이외에도 비 기술적인 관점에서 개발팀에게 더욱 친화적인 인프라 운영 경험을 제공할 수 있고, 초기 구성단계를 지나고 나면 Sysops(운영)의 관점에서 역할이 많이 줄어들기 때문에 많은 조직에서 사랑받는 방법론이 아닐까 예상합니다.
오늘 저녁은 여러분들의 토이프로젝트에 Gitops 구성을 한번 해보시는거 어떨까요?