GitOps
이번 장에서는 DevOps(이하 데브옵스)에 이어서 요즘 자주 등장하기 시작하는 GitOps(이하 깃옵스)가 무엇인지에 대해서 알아보도록 한다.
깃옵스란?
깃옵스라는 용어는 위브웍스(Weaveworks Inc.)에서 처음으로 사용한 용어로 Git을 사용해 인프라 및 애플리케이션 구성을 관리하기 위한 일련의 방법으로 지속적 배포(Continuous Deployment)에 초점을 두고 있다. 깃옵스를 완전히 새로운 개념이라고 생각할 수 있지만 데브옵스 업무를 이전부터 진행했던 엔지니어라면 아마 한번쯤은 깃옵스라는 방법을 사용해 봤을 것이다.
깃옵스는 선언형 모델(Declarative Model)을 지원하는 클라우드 네이티브에 중점을 두고 있다. 이름에서 알 수 있듯이 깃을 통해서 애플리케이션의 배포와 운영에 관련된 모든 요소를 관리하는 방식이다. 특히 IaC(Infrastructure as Code)도구를 지원한다. 이 말은 인프라를 구성하기 위한 구성 파일 세트를 Git을 통해서 버전 관리를 할 수 있고 애플리케이션이 더 쉽게 배포되거나 롤백될 수 있다. 또한 인프라를 구성하는 파일이 따로 버전 관리가 되기 때문에 새로운 인프라 환경을 구축해야 하는 경우 빠르게 재현이 가능하다.
위브웍스에서는 깃옵스를 클라우드 네이티브 애플리케이션 구축을 위한 운영 모델이라고 부르고 있으며 아래와 같이 두 가지로 요약하고 있다.
- Kubernetes 및 기타 클라우드 네이티브 기술을 위한 운영 모델로, 컨테이너화된 클러스터 및 애플리케이션에 대한 Git 배포, 관리 및 모니터링을 통합하는 일련의 모범 사례를 제공한다.
- 애플리케이션 관리를 위한 개발자 경험으로 가는 길 종단 간 CI/CD 파이프라인과 Git 워크플로우가 운영과 개발 모두에 적용되는 곳이다.
깃옵스 원칙
깃옵스 워크플로우로 클러스터를 관리하려면 아래의 항목이 준비되어 있어야 한다.
- 전체 시스템을
선언적으로 설명한다.
깃옵스와 함께 쿠버네티스는선언적이고 코드로 처리될 수 있는 많은 최신 클라우드 네이티브 도구의 하나의 예시이다.선언적이란 구성이 일련의 지침 대신 사실 집합에 의해 보장됨을 의미한다. 깃에서 버전이 지정된 애플리케이션 선언을 사용하면 단일 정보 소스를 갖게 되고 앱을 쿠버네티스에서 쉽게 배포하고 롤백할 수 있다. 가장 중요한 점은 어떠한 이유로 인프라를 복구해야 하는 경우 안정적이고 신속하고 재현할 수 있다는 점이다. - 깃을 통해
버전을 관리할 수 있는 상태다.
시스템 선언이 버전 제어 시스템에 저장되고 표준 정보 소스 역할을 하면 모든 것이 파생되고 구동되는 단일 위치를 가지게 된다. 번역을 하다보니 부자연스럽게 표현되었지만 간단하게 버전이 관리된다는 의미다. 버전이 관리되기 때문에 언제든지 인프라를 우리가 원하는 상태로 롤백이 가능하다. 또한 깃에서 보안을 보장하기 때문에 SSH 키를 사용하여 코드의 저자 및 출처에 대한 강력한 보안을 보장받을 수 있다. - 깃에 반영되는 변경 사항은 시스템에
자동으로 적용할 수 있도록 승인되어 있다.
선언된 상태가 깃에 유지되면 다음 단계는 해당 상태에 대한 변경 사항이 시스템에 자동으로 적용되도록 허용하는 것이다. 여기서 중요한 점은 시스템을 변경하기 위해 클러스터 자격 증명이 필요하지 않다는 점이다. 깃옵스에는 상태 정의가 외부에 존재하는 분리된 환경이 있다. 이를 통해 수행할 작업과 수행 방법을 구분할 수 있다. - 정확성을 보장하고
차이를 경고하는 소프트웨어 에이전트.
선언되어 있는 시스템의 상태와 실제로 운영되는 시스템의 상태가 일치하지 않는 경우 소프트웨어 에이전트가 알려줄 수 있다. 에이전트를 사용하여 전체 시스템이 자가 치유되도록 할 수도 있으며 노드나 파드가 실패하는 경우뿐만 아니라 사람의 실수와 같은 차이도 복구가 가능하다. 이러한 경우 소프트웨어 에이전트는 작업에 대한 피드백 및 제어 루프 역할을 한다.
깃옵스의 주요 이점
자동화된 전달 파이프라인은 깃에 변경 사항이 있을 때 인프라에 대한 변경 사항을 롤아웃한다. 하지만 깃옵스의 아이디어는 그 이상이며 도구를 사용하여 전체 애플리케이션의 상태와 선언된 소스와 비교하여 일치하지 않는 경우 엔지니어에게 알려준다. 깃옵스 모범 사례를 적용하면 인프라와 애플리케이션 모드로 관리되기 때문에 개발팀이 속도를 높이고 시스템의 안정성을 개선할 수 있다.
- 생산성 향상
통합 피드백 제어 루프를 통한 지속적인 배포 자동화는 평균 배포 시간을 단축한다. 개발팀은 수많은 변경 사항을 실시간으로 반영할 수 있으며 전체 개발 퍼포먼스가 향샹된다. - 향상된 개발자 경험
개발자는 깃과 같은 친숙한 도구를 사용하여 쿠버테시트의 내부를 몰라도 쿠버네티스에 대한 업데이트 및 기능을 더 빠르게 관리할 수 있다. 팀에 새롭게 합류한 개발자는 몇 개월이 아닌 며칠 만에 빠르게 적용하여 생산성을 높일 수 있다. - 향상된 안정성
깃 워크플로우를 사용하여 클러스터를 관리하면 쿠버네티스 외부의 모든 클러스터 변경 사항에 대한 편리한 감사 로그를 자동으로 얻을 수 있다. 클러스터에 대해 누가 무엇을 했는지에 대한 감사 추적은 SOC2 규정을 충족하고 안정성을 보장하는 데 사용할 수 있다. - 빠른 롤백 및 복구 가능
깃의 기능을 통해서 안정적이고 재현 가능한 롤백을 얻을 수 있다. 전체 시스템이 깃에 설명되어 있기 때문에 멜트다운 이후 복구까지 소요되는 시간을 몇 시간 단위에서 몇 분 단위로 단축시킬 수 있다. - 일관성 및 표준화
깃옵스는 인프라, 앱 및 쿠버네티스 추가 기능 변경을 위한 하나의 모델을 제공하므로 전체 조직에서 일관된 워크플로우를 사용할 수 있다. CI/CD 모두 Pull 또는 Push 요청에 의해 구동될 뿐만 아니라 운영 작업도 깃을 통해 완전히 재현할 수 있다. - 강력한 보안 보장
깃의 강력한 정확성 및 보안 보장은 변경 사항을 추적 및 관리하는 데 사용되는 강력한 암호화는 물론 저자와 출처를 증명하기 위해 변경 사항에 서명하는 기능이 지원하는 클러스터의 원하는 상태를 안전하게 정의하는 데 중요하다.
깃옵스는 지속적인 전달과 클라우드 네이티브의 만남이다.
깃옵스는 포괄적인 지속적 통합 개요에서 시작된 데브옵스 및 SRE에서 가져온 아이디어를 기반으로 구축하고 반복한다.
- 필요한 도구를 자유롭게 선택할 수 있다.
깃옵스는 CI/CD 파이프라인을 위한 워크플로우로서 개발 프로세스의 성배라고 불린다. CI/CD 파이프라인에 필요한 모든 작업을 수행할 수 있는 많은 도구가 있기 때문에 깃옵스를 도입한다면 다양한 부분에 최적의 도구를 자유롭게 선택할 수 있다. - 깃은 IaC도구를 지원한다.
쿠버네티스는 선언적이고 코드로 처리될 수 있는 대표적인 최신 클라우드 네이티브 도구이다. 선언적이란 구성이 일련의 지침 대신 사실 집합에 의해 보장됨을 의미한다. 선언적 도구를 사용하면 전체 구성 파일 세트를 깃에서 버전 관리 할 수 있다. - 우리의 시스템을 모니터링 한다.
선언적 프로비저닝 도구를 사용하면 깃에서 원하는 실제 상태를 설명할 수 있다. 대표적으로 Ansible과 같은 IaC 도구는diff alerts와 같은 기능을 지원한다. 이는 운영자가 라이브 시스템을 의도된 상태(구성 스크립트에 정의된)로 만들기 위해 추가 작업이 필요한 경우 도움이 된다. 최근에는 불변이 보장되는 컨테이너 이미지를 사용한다. - 변경할 수 없는 인프라를 기반으로 한다.
깃옵스는 변경할 수 없는 인프라 및 선언적 컨테이너 오케스트레이션으로의 이동을 최대한 활용한다. 배포 후에 변경의 위험을 최소화하려면 재현 가능하고 안정적인 배포 프로세스를 유지하는 것이 중요하다. 우리가 원하는 상태는 깃에 설명되어 있고 불변성을 위한 컨테이너와 Terraformr과 Ansible과 같은 다양한 클라우드 네이티브 도구를 사용하여 구성을 자동화하고 관리한다. 이러한 도구들은 컨테이너 및 쿠버네티스의 선언적 특성과 함께 전체 멜트다운의 경우 완전한 복구에 필요한 것들을 제공한다.
워크플로우 및 구현
깃옵스의 핵심 아이디어는 아래와 같다.
- 배포에 관련된 모든 것을 선언적인 코드로 작성하여 깃 리포지토리에서 관리한다.
- 깃 리포지토리의 선언적으로 작성된 코드와 운영되는 환경 간 상태의 차이가 없도록 유지시켜주는 자동화 시스템을 구성한다.
핵심 아이디어를 준수하도록 깃옵스 파이프라인을 구축하였다면 새로운 선언적 코드를 리포지토리에 새로운 버전으로 등록하면 자동으로 인프라에 반영될 것이다.
전략
깃옵스를 도입할 때 깃 저장소 전략과 배포 전략을 정해야 한다.
- 저장소 전략
- 애플리케이션 저장소: 애플리케이션 코드와 배포를 위한 배포 매니페스트를 포함한다.
- 배포 환경 구성 저장소: 배포 환경에 대한 모든 매니페스트를 포함하며 애플리케이션과 인프라 서비스가 어떤 버전으로 어떻게 구성되어야 하는지에 대한 정보를 포함한다.
- 배포 전략
위브웍스는 깃옵스를 도입하기 위해 Push 타입과 Pull 타입 두 가지 배포 전략을 사용할 것을 권장하고 있다.
- Push 타입
저장소에 있는 매니페스트 파일이 변경되는 경우 파이프라인을 통해 운영 환경에 반영되는 구조이다. 젠킨스, 서클CI와 같은 도구를 사용하며 아키텍처가 단순하기 때문에 가장 인기 있는 방법이다. 또한 배포 환경의 개수에 영향을 받지 않기 때문에 간단한 수정으로 배포 환경을 추가하거나 변경할 수 있다.
단, 항상 연결되어 있는 상태가 아니기 때문에 실제 배포 작업이 수행될 때 실패하는 지점이 발생할 수 있으며 배포 환경과 매니페스트가 동기화 되지 않음을 감지하는 별도의 모니터링 시스템이 필요하다.
- Pull 타입
옵저버 패턴을 사용하여 운영 환경에 설치되어 있는 오퍼레이터가 배포 파이프라인을 대신하는 전략이다. 오퍼레이터는 저장소의 매니페스트와 배포 환격을 지속적으로 비교하고 운영 환경에 변경이 필요한 경우에 자동으로 운영 환경을 변경시킨다. 누군가 수동으로 운영 환경을 변경하는 경우 운영 환경이 매니페스트에 명시되어 있는 형태로 롤백되며 이러한 방식을 통해서 운영 환경이 깃 저장소의 매니페스트 파일과 동일하다는 것을 보장한다.
Push 타입의 경우 운영 환경 외부에서 접속해야 하기 때문에 접속을 위한 자격 증명 정보를 외부에서 관리해야 한다. 하지만 Pull 타입의 경우 오퍼레이터와 애플리케이션이 동일한 환경에서 동작하기 때문에 자격 증명 정보가 외부에 노출될 가능성이 낮다.
지금까지 깃옵스란 무엇인지에 대해서 알아보았다.
다음에는 깃옵스를 도입하여 운영 환경을 구축하는 방법에 대해서 알아본다.
참고한 자료
'Infrastructure > DevOps' 카테고리의 다른 글
| [DevOps] DevOps란 (0) | 2022.09.08 |
|---|
