2020.07.16

“쿠버네티스도 넘어서는 데브옵스의 확장판” 깃옵스의 이해

Josh Fruhlinger | InfoWorld
지난 10년 동안 프로그래밍에는 여러 혁신적인 변화가 일어났다. 개발팀과 운영팀을 공유된 하나의 작업 프로세스로 정렬하는 데브옵스를 중심으로 한 작업 방식의 변화, 그리고 데브옵스팀이 코드베이스에 일관적인 증분 업데이트를 제공하는 CI/CD(Continuous Integration and Continuous Delivery, 지속적 통합 및 지속적 제공)이 대표적이다. 또 다른 변화는 모놀리식 코드베이스에서 쿠버네티스와 같은 오케스트레이션 플랫폼으로 관리되는 컨테이너에서 실행되는 클라우드 기반 마이크로서비스로의 이동이다.
 
ⓒ Getty Images Bank

클러스터 시스템 또는 클라우드에서 실행되는 컨테이너 기반 애플리케이션은 쿠버네티스와 같은 플랫폼이 이것저것 조율한다 해도 프로비저닝과 관리가 복잡하고 어렵다. 깃옵스(GitOps)는 데브옵스와 CI/CD 분야의 기법을 적용함으로써 이 관리 작업을 간소화하는 것을 목표로 하는 새로운 실행 방식이다.

깃옵스의 핵심은 데브옵스가 애플리케이션을 프로비저닝하기 위해 사용하는 것과 동일한 인프라 프로비저닝 접근 방식을 취하는 코드형 인프라(infrastructure as code) 개념이다. 따라서 애플리케이션뿐만 아니라 파일에 기술된 기반 호스트 머신과 네트워크도 버전 제어 시스템의 다른 코드와 똑같이 자동화된 프로세스를 사용해 처리하고, 이후 실제 애플리케이션과 이러한 파일에 기술된 애플리케이션을 하나로 수렴할 수 있다.

깃옵스에서 버전 제어 시스템의 코드는 프로덕션에서 애플리케이션이 어떤 형태여야 하는지를 알려주는 단일 진실 공급원이다.
 

깃옵스의 정의

위브웍스(Weaveworks)는 깃옵스 개념을 널리 퍼뜨린 기업이다. 위브웍스가 한 일에 대해서는 잠시 후에 자세히 살펴보고, 먼저 이 회사의 깃옵스 정의부터 살펴보자. 정의는 다음과 같이 두 부분으로 구성된다.
 
  • 쿠버네티스 및 기타 클라우드 네이티브 기술을 위한 운영 모델로, 컨테이너화된 클러스터와 애플리케이션의 배포, 관리, 모니터링을 단일화하는 모범 사례 모음을 제공한다.
  • 애플리케이션 관리에 있어서의 개발자 경험을 향한 경로로, 운영과 개발, 두 가지 모두에 엔드 투 엔드 CI/CD 파이프라인과 깃 워크플로우가 적용된다.

즉, 깃옵스는 쿠버네티스 및 이와 유사한 플랫폼을 관리하기 위한 구체적인 방법 모음이다. 또한 데브옵스를 도입하고 코드를 클라우드로 마이그레이션하는 개발팀이 증가하면서 더 폭넓은 애플리케이션에 적용될 가능성도 지니고 있다. 그러나 깃옵스와 깃옵스가 해결하는 문제를 제대로 이해하려면 깃옵스에 들어가는 구성 요소에 대해 살펴봐야 한다.
 

깃의 정의

깃옵스에서 깃(Git)은 리누스 토발즈가 2005년에 개발한 이후 매우 폭넓게 사용되고 있는 분산 버전 제어 시스템을 가리킨다. 깃은 개발팀이 애플리케이션 코드베이스에서 협업하면서 각자 작업하는 다양한 코드 분기를 저장하고 이후 프로덕션 코드로 병합할 수 있게 해준다. 깃의 핵심 개념은 개발자가 자신이 작업한 코드가 코드베이스 내의 다른 분기에 통합되도록 공식적으로 요청하는 풀 요청(pull request)이다.

깃 풀 요청은 팀원이 새 코드를 애플리케이션에 추가해야 하는지 여부에 대한 합의에 이르기 전에 협업하고 토론할 수 있는 기회를 제공한다. 또한 깃은 이전 코드 버전을 저장하므로 잘못될 경우 마지막 정상 작동 버전으로 쉽게 돌아갈 수 있으며, 리비전 간에 변경된 부분을 신속하게 볼 수 있다. 깃은 클라우드에 호스팅되는 제어 시스템인 깃허브의 기반으로 가장 잘 알려져 있지만, 깃 자체는 내부 기업 서버부터 개인 PC까지 어디에나 배포할 수 있는 오픈소스 소프트웨어다.

보통 깃을 컴퓨터 프로그래밍 툴이라고 생각하기 쉬운데, 사실 깃은 어떤 콘텐츠를 사용하든 관계없다. 깃은 어떤 텍스트 파일이건 “코드베이스”로 처리한다. 예를 들어 작가가 공동 저작물의 편집 내용을 추적하는 용도로도 사용할 수 있다. 깃옵스의 핵심 코드베이스 대부분은 실행 가능 코드가 아닌 선언적 구성 파일로 이뤄진다는 면에서 이는 중요한 부분이다.

마지막으로 짚어볼 부분은 이름에 “깃”이 포함되긴 해도 깃옵스에서 꼭 깃을 사용할 필요는 없다는 것이다. 이미 서브버전(Subversion)과 같은 다른 버전 제어 소프트웨어에 투자한 기업도 깃옵스를 구현할 수 있다. 그러나 데브옵스 세계에서 CI/CD 구현에 깃이 워낙 광범위하게 사용되는 만큼 대부분의 깃옵스 프로젝트가 깃을 사용한다.
 

CI/CD 프로세스란 무엇인가?

CI/CD에 대한 종합적인 이야기는 이 기사의 범위를 벗어나지만, CI/CD는 깃옵스 작동의 중심에 위치하므로 몇 가지는 설명이 필요하다. CI/CD 중 하나인 지속적 통합은 깃과 같은 버전 제어 리포지토리를 통해 실현된다. 즉, 개발자는 몇 개월 또는 몇 년마다 한 번씩 대용량의 단일체 새 버전을 내놓는 대신 조금씩 지속적으로 코드베이스를 개선할 수 있다. 지속적 배포는 새 코드를 빌드, 테스트하고 프로덕션으로 배포하는 파이프라인이라고 하는 자동화된 시스템을 통해 실현된다.

여기서 계속 코드라는 용어가 나오는데, 보통은 코드라고 하면 C나 자바, 또는 자바스크립트와 같은 프로그래밍 언어로 작성된 실행 가능 코드가 연상된다. 그러나 깃옵스에서 우리가 관리하는 “코드”는 대부분 구성 파일로 이뤄진다. 이것은 단순히 부차적인 내용이 아니라, 깃옵스의 핵심이다. 앞에서도 말했듯이 이러한 구성 파일이 “단 하나의 사실 소스(single source of truth)”로서 시스템의 정상 상태를 기술하기 때문이다. 구성 파일은 지시적이 아니라 선언적이다. 즉, 구성 파일은 “10개의 서버를 시작하라”고 지시하지 않고 “이 시스템에는 10개의 서버가 포함된다”고 기술한다.

깃옵스에서 CI 부분은 개발자가 이러한 구성 파일을 대상으로 한 조정과 개선을 신속하게 롤아웃할 수 있게 해주고, CD 부분은 자동화된 소프트웨어 에이전트가 애플리케이션의 라이브 버전이 구성 파일의 설명을 반영하도록(깃옵스 언어로 말하면 선언적 모델로 수렴하도록) 보장하기 위해 최선을 노력을 기울이는 것이다.
 

깃옵스와 쿠버네티스

앞서 언급했듯이, 깃옵스의 개념은 원래 쿠버네티스 애플리케이션 관리를 중심으로 개발됐다. 지금까지 알아본 깃옵스에 대한 내용을 바탕으로 위브웍스의 깃옵스로 돌아가서, 깃옵스 원칙에 따라 관리되는 쿠버네티스를 업데이트하는 방법에 관한 이들의 설명을 살펴보자. 요약하면 다음과 같다.
 



2020.07.16

“쿠버네티스도 넘어서는 데브옵스의 확장판” 깃옵스의 이해

Josh Fruhlinger | InfoWorld
지난 10년 동안 프로그래밍에는 여러 혁신적인 변화가 일어났다. 개발팀과 운영팀을 공유된 하나의 작업 프로세스로 정렬하는 데브옵스를 중심으로 한 작업 방식의 변화, 그리고 데브옵스팀이 코드베이스에 일관적인 증분 업데이트를 제공하는 CI/CD(Continuous Integration and Continuous Delivery, 지속적 통합 및 지속적 제공)이 대표적이다. 또 다른 변화는 모놀리식 코드베이스에서 쿠버네티스와 같은 오케스트레이션 플랫폼으로 관리되는 컨테이너에서 실행되는 클라우드 기반 마이크로서비스로의 이동이다.
 
ⓒ Getty Images Bank

클러스터 시스템 또는 클라우드에서 실행되는 컨테이너 기반 애플리케이션은 쿠버네티스와 같은 플랫폼이 이것저것 조율한다 해도 프로비저닝과 관리가 복잡하고 어렵다. 깃옵스(GitOps)는 데브옵스와 CI/CD 분야의 기법을 적용함으로써 이 관리 작업을 간소화하는 것을 목표로 하는 새로운 실행 방식이다.

깃옵스의 핵심은 데브옵스가 애플리케이션을 프로비저닝하기 위해 사용하는 것과 동일한 인프라 프로비저닝 접근 방식을 취하는 코드형 인프라(infrastructure as code) 개념이다. 따라서 애플리케이션뿐만 아니라 파일에 기술된 기반 호스트 머신과 네트워크도 버전 제어 시스템의 다른 코드와 똑같이 자동화된 프로세스를 사용해 처리하고, 이후 실제 애플리케이션과 이러한 파일에 기술된 애플리케이션을 하나로 수렴할 수 있다.

깃옵스에서 버전 제어 시스템의 코드는 프로덕션에서 애플리케이션이 어떤 형태여야 하는지를 알려주는 단일 진실 공급원이다.
 

깃옵스의 정의

위브웍스(Weaveworks)는 깃옵스 개념을 널리 퍼뜨린 기업이다. 위브웍스가 한 일에 대해서는 잠시 후에 자세히 살펴보고, 먼저 이 회사의 깃옵스 정의부터 살펴보자. 정의는 다음과 같이 두 부분으로 구성된다.
 
  • 쿠버네티스 및 기타 클라우드 네이티브 기술을 위한 운영 모델로, 컨테이너화된 클러스터와 애플리케이션의 배포, 관리, 모니터링을 단일화하는 모범 사례 모음을 제공한다.
  • 애플리케이션 관리에 있어서의 개발자 경험을 향한 경로로, 운영과 개발, 두 가지 모두에 엔드 투 엔드 CI/CD 파이프라인과 깃 워크플로우가 적용된다.

즉, 깃옵스는 쿠버네티스 및 이와 유사한 플랫폼을 관리하기 위한 구체적인 방법 모음이다. 또한 데브옵스를 도입하고 코드를 클라우드로 마이그레이션하는 개발팀이 증가하면서 더 폭넓은 애플리케이션에 적용될 가능성도 지니고 있다. 그러나 깃옵스와 깃옵스가 해결하는 문제를 제대로 이해하려면 깃옵스에 들어가는 구성 요소에 대해 살펴봐야 한다.
 

깃의 정의

깃옵스에서 깃(Git)은 리누스 토발즈가 2005년에 개발한 이후 매우 폭넓게 사용되고 있는 분산 버전 제어 시스템을 가리킨다. 깃은 개발팀이 애플리케이션 코드베이스에서 협업하면서 각자 작업하는 다양한 코드 분기를 저장하고 이후 프로덕션 코드로 병합할 수 있게 해준다. 깃의 핵심 개념은 개발자가 자신이 작업한 코드가 코드베이스 내의 다른 분기에 통합되도록 공식적으로 요청하는 풀 요청(pull request)이다.

깃 풀 요청은 팀원이 새 코드를 애플리케이션에 추가해야 하는지 여부에 대한 합의에 이르기 전에 협업하고 토론할 수 있는 기회를 제공한다. 또한 깃은 이전 코드 버전을 저장하므로 잘못될 경우 마지막 정상 작동 버전으로 쉽게 돌아갈 수 있으며, 리비전 간에 변경된 부분을 신속하게 볼 수 있다. 깃은 클라우드에 호스팅되는 제어 시스템인 깃허브의 기반으로 가장 잘 알려져 있지만, 깃 자체는 내부 기업 서버부터 개인 PC까지 어디에나 배포할 수 있는 오픈소스 소프트웨어다.

보통 깃을 컴퓨터 프로그래밍 툴이라고 생각하기 쉬운데, 사실 깃은 어떤 콘텐츠를 사용하든 관계없다. 깃은 어떤 텍스트 파일이건 “코드베이스”로 처리한다. 예를 들어 작가가 공동 저작물의 편집 내용을 추적하는 용도로도 사용할 수 있다. 깃옵스의 핵심 코드베이스 대부분은 실행 가능 코드가 아닌 선언적 구성 파일로 이뤄진다는 면에서 이는 중요한 부분이다.

마지막으로 짚어볼 부분은 이름에 “깃”이 포함되긴 해도 깃옵스에서 꼭 깃을 사용할 필요는 없다는 것이다. 이미 서브버전(Subversion)과 같은 다른 버전 제어 소프트웨어에 투자한 기업도 깃옵스를 구현할 수 있다. 그러나 데브옵스 세계에서 CI/CD 구현에 깃이 워낙 광범위하게 사용되는 만큼 대부분의 깃옵스 프로젝트가 깃을 사용한다.
 

CI/CD 프로세스란 무엇인가?

CI/CD에 대한 종합적인 이야기는 이 기사의 범위를 벗어나지만, CI/CD는 깃옵스 작동의 중심에 위치하므로 몇 가지는 설명이 필요하다. CI/CD 중 하나인 지속적 통합은 깃과 같은 버전 제어 리포지토리를 통해 실현된다. 즉, 개발자는 몇 개월 또는 몇 년마다 한 번씩 대용량의 단일체 새 버전을 내놓는 대신 조금씩 지속적으로 코드베이스를 개선할 수 있다. 지속적 배포는 새 코드를 빌드, 테스트하고 프로덕션으로 배포하는 파이프라인이라고 하는 자동화된 시스템을 통해 실현된다.

여기서 계속 코드라는 용어가 나오는데, 보통은 코드라고 하면 C나 자바, 또는 자바스크립트와 같은 프로그래밍 언어로 작성된 실행 가능 코드가 연상된다. 그러나 깃옵스에서 우리가 관리하는 “코드”는 대부분 구성 파일로 이뤄진다. 이것은 단순히 부차적인 내용이 아니라, 깃옵스의 핵심이다. 앞에서도 말했듯이 이러한 구성 파일이 “단 하나의 사실 소스(single source of truth)”로서 시스템의 정상 상태를 기술하기 때문이다. 구성 파일은 지시적이 아니라 선언적이다. 즉, 구성 파일은 “10개의 서버를 시작하라”고 지시하지 않고 “이 시스템에는 10개의 서버가 포함된다”고 기술한다.

깃옵스에서 CI 부분은 개발자가 이러한 구성 파일을 대상으로 한 조정과 개선을 신속하게 롤아웃할 수 있게 해주고, CD 부분은 자동화된 소프트웨어 에이전트가 애플리케이션의 라이브 버전이 구성 파일의 설명을 반영하도록(깃옵스 언어로 말하면 선언적 모델로 수렴하도록) 보장하기 위해 최선을 노력을 기울이는 것이다.
 

깃옵스와 쿠버네티스

앞서 언급했듯이, 깃옵스의 개념은 원래 쿠버네티스 애플리케이션 관리를 중심으로 개발됐다. 지금까지 알아본 깃옵스에 대한 내용을 바탕으로 위브웍스의 깃옵스로 돌아가서, 깃옵스 원칙에 따라 관리되는 쿠버네티스를 업데이트하는 방법에 관한 이들의 설명을 살펴보자. 요약하면 다음과 같다.
 



X