GitOps 워크플로우란?

GitOps는 Git 리포지토리를 단일 정보 소스로 사용하여 전체 인프라와 애플리케이션 라이프사이클을 관리하는 현대적인 소프트웨어 개발 및 배포 방식입니다. 이 워크플로우에서 개발자는 코드 변경 사항 및 인프라 구성을 Git 리포지토리에 커밋하여 Git 리포지토리 상태를 기반으로 애플리케이션 및 인프라 변경 사항을 빌드, 테스트하고 배포하는 자동화된 CI/CD 파이프라인을 트리거합니다. 

운영자와 관리자는 Git에 저장된 선언적 구성 파일을 사용하여 원하는 인프라 상태를 정의하고 Argo CD와 같은 지속적 동기화 툴을 사용하여 라이브 환경이 Git 리포지토리와 일치하는지 확인함으로써 코드 및 인프라를 위한 버전 제어, 협업, 감사 가능성을 제공합니다. 이는 궁극적으로 효율적이고 신뢰할 수 있는 소프트웨어 제공 및 인프라 관리로 이어집니다.

이는 이전에 수동으로 이루어지던 프로세스에 자동화를 도입하여 클러스터 구성과 애플리케이션 배포를 관리하는 데 도움을 줍니다. 예를 들어, GitOps는 멀티 클러스터 쿠버네티스 환경 전반에서 Red Hat® OpenShift® Container Platform 클러스터를 관리하는 데 도움이 될 수 있습니다. 

이러한 기능은 워크로드가 퍼블릭 클라우드, 프라이빗 클라우드, 심지어는 온프레미스 환경 전반에서 이동할 때 발생하는 일관성, 보안, 협업에 대한 필요성과 같이 멀티클라우드 접근 방식에 따르는 여러 문제점을 완화하는 데 도움이 됩니다. 

이 문서에서는 GitOps 워크플로우의 기본적인 내용을 살펴봅니다.

GitOps에서 Git 리포지토리는 시스템과 애플리케이션 구성을 위한 단일 정보 소스입니다. 또한 환경에 대한 인프라의 선언적 설명으로 구성되며, Argo CD와 같이 GitOps 툴링으로 처리되는 자동화된 프로세스와 함께 작동합니다. 이와 같은 자동화는 환경의 실제 상태를 원하는 상태와 일치시킵니다. 또한 Git 기록이 변경 추적 기능을 제공하기 때문에 리포지토리를 사용하여 시스템 상태에 대한 변경 사항 목록을 확인할 수 있습니다. 

또한 인프라와 구성을 코드로 저장하면 확산을 줄이는 데 도움이 됩니다. Git 리포지토리 내에 클러스터와 애플리케이션의 구성을 코드로 저장할 수 있습니다. 

코드형 인프라(Infrastructure as Code, IaC)는 수동 프로세스가 아닌 코드를 통해 인프라를 관리하고 프로비저닝하는 것을 말합니다.

IaC를 사용하면 인프라 사양이 포함된 설정 파일이 생성됩니다. 이를 통해 구성을 더 손쉽게 편집하고 배포하는 동시에 항상 동일한 환경을 프로비저닝할 수 있습니다. IaC는 구성 사양을 코드화하고 문서화함으로써 구성 관리를 지원하며, 따라서 구성 변경 사항을 문서화하지 않고 임시로 변경하는 일을 막을 수 있습니다. IaC에 대한 접근 방식에는 선언적 방식과 명령형 방식 두 가지가 있습니다.

선언적 접근 방식에서는 필요한 리소스와 리소스의 속성 등 바람직한 시스템 상태를 정의하면 IaC 툴이 바람직한 상태로 구성해 줍니다. 또한 시스템 오브젝트의 현재 상태 리스트를 유지합니다. 한편 명령적 접근 방식에서는 바람직한 구성을 얻기 위한 특정 명령을 정의하며, 정의된 명령을 올바른 순서로 실행해야 합니다. 

많은 IaC 툴이 선언적 접근 방식에 따라 원하는 인프라를 자동으로 프로비저닝합니다. 원하는 상태를 변경하면 선언적 IaC 툴은 그러한 변경 사항을 적용합니다. 명령형 접근 방식의 툴을 사용하려면 변경 사항을 어떻게 적용하는지 이해해야 합니다.

IaC는 DevOps 사례 및 지속적 통합/지속적 제공(Continuous Integration/Continuous Delivery, CI/CD) 구현에서 중요한 부분을 차지합니다. 개발자가 하던 프로비저닝 작업을 대부분 IaC로 처리하고 개발자는 스크립트를 실행하여 인프라를 준비할 수 있습니다. 따라서 인프라 준비를 기다리는 동안 애플리케이션 배포를 보류할 필요가 없으며, 시스템 관리자는 시간이 많이 소요되는 수동 프로세스를 관리하지 않아도 됩니다. 

CI/CD는 통합 및 테스트에서 제공 및 배포에 이르는 애플리케이션 라이프사이클 전반에 걸쳐 지속적인 자동화와 지속적인 모니터링에 의존합니다. 
IaC를 사용하는 DevOps 접근 방식을 통해 개발 팀과 운영 팀의 방식을 서로 일치시키면 오류, 수동 배포, 비일관성 문제가 줄어듭니다.

GitOps는 인프라 구성을 위해 Git을 버전 제어 시스템으로 사용하는 IaC가 진화한 것이라고 생각하면 됩니다. 

파이프라인은 코드를 빌드, 테스트, 배포하는 과정을 거쳐 소프트웨어 개발을 추진하는 프로세스이며, 지속적 통합 및 지속적 제공/배포(Continuous Integration and Continuous Delivery/Deployment, CI/CD)라고도 합니다. 파이프라인을 자동화함으로써 인적 오류를 최소화하고 소프트웨어 출시 방식에 일관된 프로세스를 유지하는 것을 목표로 합니다. 파이프라인에 사용되는 툴에는 코드 컴파일, 유닛 테스트, 코드 분석, 보안, 바이너리 생성 등이 있습니다. 컨테이너화된 환경에서는 하이브리드 클라우드 전반에 배포할 컨테이너 이미지에 코드를 패키징하는 경우도 이러한 파이프라인에 포함됩니다.

CI/CD는 개발자와 IT 운영 팀이 협업해 소프트웨어를 배포하는 DevOps 방법론의 근간입니다. 사용자 정의 애플리케이션이 기업 차별화의 핵심 요소가 되면서 코드를 얼마나 빨리 릴리스할 수 있느냐가 경쟁력의 차별화 요소가 되었습니다.

CI/CD 파이프라인은 리포지토리로 푸시되고 있는 코드와 같은 외부 이벤트에 의해 트리거되는 것이 보통입니다. GitOps 워크플로우에서 변경 작업은 Git 리포지토리에서 상태를 수정하는 풀 요청을 사용해 이루어집니다. 

GitOps 워크플로우를 사용해 새 릴리스를 롤아웃하기 위해 Git에서 풀 요청이 이루어지고, 이를 통해 선언된 클러스터 상태가 변경됩니다. GitOps 파이프라인과 오케스트레이션 시스템 사이에 위치한 GitOps 운영자는 Git에서 커밋을 선택하여 새로운 상태 선언으로 풀링합니다.  

변경 사항은 승인되고 병합된 후 라이브 인프라에 자동으로 적용됩니다. 개발자는 표준 워크플로우 및 (CI/CD) 사례를 계속 사용할 수 있습니다.

워크플로우에 GitOps와 쿠버네티스를 함께 사용하는 경우, 오퍼레이터는 주로 쿠버네티스 오퍼레이터입니다. 

쿠버네티스 오퍼레이터는 쿠버네티스 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. 쿠버네티스 오퍼레이터는 쿠버네티스 API의 기능을 확장하여 쿠버네티스 사용자를 대신해 복잡한 애플리케이션의 인스턴스를 생성, 구성 및 관리하는 애플리케이션별 컨트롤러입니다. 이 오퍼레이터는 기본 쿠버네티스 리소스 및 컨트롤러 개념을 기반으로 하지만 오퍼레이터가 관리하는 소프트웨어의 전체 라이프사이클을 자동화하는 데 필요한 도메인 또는 애플리케이션별 정보가 담겨 있습니다. 

오퍼레이터는 GitOps 내에서 리포지토리의 원하는 상태를 배포된 인프라의 실제 상태와 비교합니다. 오퍼레이터는 실제 상태와 리포지토리 상황 사이에 차이점이 발견될 때마다 인프라를 업데이트합니다. 오퍼레이터는 컨테이너 이미지 리포지토리를 모니터링하고 새 이미지를 배포하는 방식으로 업데이트를 수행할 수도 있습니다.

관측성은 시스템 또는 애플리케이션의 출력, 로그, 성능 메트릭을 검사하여 시스템 또는 애플리케이션의 상태를 모니터링, 측정, 파악하는 기능을 뜻합니다. 현대적인 소프트웨어 시스템과 클라우드 컴퓨팅에서 관측성은 애플리케이션과 인프라의 신뢰성, 성능, 보안을 보장하는 데 있어 그 역할이 더욱 중요해지고 있습니다.

관측성은 기존 모니터링 시스템을 흡수하고 확장하며 팀이 문제의 근본 원인을 파악하는 데 도움을 줍니다. 이를 통해 이해관계자는 애플리케이션과 비즈니스에 관련한 전망과 잠재적인 문제 예측을 비롯한 질문에 답할 수 있습니다. 

관측성의 장점 

• 신뢰성 개선: 문제가 확대되기 전에 감지하고 해결하여 다운타임을 최소화하고 사용자가 시스템을 계속 사용할 수 있도록 보장합니다.
• 효율적인 트러블슈팅: 시스템 동작에 대한 심층적인 인사이트를 활용하여 문제의 근본 원인을 신속하게 파악하고 효율적으로 해결합니다.
• 성능 최적화: 시스템 병목 현상이나 활용률이 낮은 리소스와 같은 최적화 영역을 식별하여 리소스를 더욱 효율적으로 할당하고 성능을 개선할 수 있습니다.
• 데이터 기반 의사 결정: 시스템 성능과 동작에 대한 최신 정보를 수신하여 데이터에 기반한 의사 결정을 내리고 지속적으로 개선하도록 지원합니다.

Red Hat® OpenShift® Observability는 관측성 툴과 기술을 연계하여 통합된 관측성 경험을 생성함으로써 현대적인 아키텍처 복잡성을 해결합니다. 이 플랫폼은 다양한 시스템 메트릭, 로그, 추적, 이벤트에 대한 실시간 가시성, 모니터링, 분석 기능을 제공하여 문제가 애플리케이션 또는 최종 사용자에게 영향을 미치기 전에 신속하게 트러블슈팅할 수 있도록 설계되었습니다.

Red Hat OpenShift GitOps는 사용자를 대신해 Argo CD 인스턴스를 설치하고 구성하는 오퍼레이터입니다. 인프라 구성과 애플리케이션 배포를 관리하여 이와 같은 구성 리포지토리를 중심으로 배포 프로세스를 구성합니다. 프로세스의 중심에는 항상 최소 다음 두 개의 리포지토리가 있습니다. 하나는 소스 코드가 포함된 애플리케이션 리포지토리이고, 다른 하나는 원하는 애플리케이션 상태를 정의하는 환경 구성 리포지토리입니다.

Red Hat OpenShift GitOps는 클러스터 리소스를 유지 관리하기 위해 애플리케이션의 지속적 통합/지속적 배포(Continuous Integration/Continuous Deployment, CI/CD)에서 지속적 배포 부분에 대한 오픈소스 툴인 Argo CD를 사용합니다. Argo CD는 Git 리포지토리에 정의된 대로 애플리케이션 상태 설명과 구성을 모니터링하여 Red Hat OpenShift GitOps에 대한 컨트롤러 역할을 합니다. Argo CD는 정의된 상태와 실제 상태를 비교하며, 명시된 설명에서 벗어나는 구성을 보고합니다. 

관리자는 이러한 보고에 기반하여 구성을 정의된 상태로 다시 동기화할 수 있습니다. 이러한 재동기화는 수동 또는 자동으로 수행할 수 있습니다. 자동화의 경우, 구성은 기본적으로 '자가 치유(self-healing)'됩니다.

즉, Red Hat OpenShift GitOps는 GitOps 워크플로우를 최적화하도록 돕습니다. 개발자는 이 워크플로우에서 코드 및 구성 변경 사항을 Git 리포지토리에 커밋하여 자동화된 CI/CD 파이프라인을 트리거합니다. 이러한 파이프라인은 Git 리포지토리의 상태에 따라 애플리케이션 및 인프라를 빌드, 테스트하고 배포하는 데 사용됩니다. 이 경우 Red Hat OpenShift GitOps는 Git에 저장된 선언적 구성 파일을 사용하여 원하는 인프라 상태를 정의하는 오퍼레이터입니다. 그러면 Argo CD가 실제 환경이 Git 리포지토리에 지정된 상태와 지속적으로 일치하는지 확인합니다. 이 접근 방식은 코드와 인프라에 대한 버전 제어, 협업, 추적성을 용이하게 하여 궁극적으로 소프트웨어 제공과 인프라 관리를 간소화하는 동시에 안정성을 강화합니다.

이제 GitOps 워크플로우로 생산성과 개발 및 배포 속도를 높이는 동시에 시스템의 안정성 및 신뢰성을 향상할 수 있다는 것을 개념적으로 이해했습니다.

그러면 직접 GitOps를 사용하여 개발해 보세요.