GitOps란 무엇인가요?

Git 리포지토리에서 구동되는 자동화에 중점을 두고 있습니다. 제목에도 나와 있지만, Git만 사용할 수 있는 리포지토리는 아닙니다. 작업을 자동화하는 것은 Git에서 제공하는 인터페이스입니다. GitOps는 빌드 메타데이터에서 추출된 정보를 사용하여 특정 코드 변경에 의해 트리거되는 빌드할 패키지를 결정합니다.

GitOps 모델은 본질적으로 컨트롤러 패턴을 사용합니다. Kubernetes 또는 OpenShift 관점에서 오퍼레이터 패턴이 이를 추가로 지원합니다. 오퍼레이터는 사용자 지정 리소스를 사용하여 애플리케이션과 해당 구성 요소를 관리하는 소프트웨어 확장 기능입니다.

GitOps 워크플로에 도움이 되는 GitOps 툴인 Argo CD도 빼놓을 수 없습니다. Argo CD는 애플리케이션의 지속적 통합 및 지속적 배포(CI/CD)를 위한 오픈 소스 선언적 도구입니다. Kubernetes 컨트롤러로 구현된 Argo CD는 실행 중인 애플리케이션 정의와 구성을 지속적으로 모니터링하여 클러스터의 현재 라이브 상태를 Git 리포지토리에 정의된 원하는 상태와 비교합니다.

하지만 GitOps는 단일 제품이나 플러그인, 플랫폼이 아닙니다. GitOps 워크플로는 팀이 애플리케이션 개발에서 이미 사용하고 있는 프로세스를 통해 IT 인프라를 관리할 수 있도록 지원합니다. GitLab 블로그의 언급을 빌려오자면  GitOps = IaC + PR 또는 MR + CI/CD, 즉 GitOps에는 세 가지 핵심 구성 요소가 필요합니다.

• IaC: 코드형 인프라(IaC)는 모든 인프라 구성을 코드로 저장하는 방식입니다. GitOps는 인프라 정의를 위한 신뢰할 수 있는 단일 소스로 Git 리포지토리를 사용합니다. Git은 모든 코드 관리 변경 사항을 추적합니다.
  
  
• PR 또는 MR: GitOps는 모든 인프라 업데이트의 변경 메커니즘으로 풀 요청(PR) 또는 병합 요청(MR)을 사용합니다. 이 과정에서 팀은 검토와 코멘트를 통해 협업하고 공식 승인을 진행할 수 있습니다.
  
  
• CI/CD: GitOps는 지속적 통합(CI) 및 지속적 배포(CD)와 함께 Git 워크플로를 사용하여 인프라 업데이트를 자동화합니다. 새 코드가 병합되면 CI/CD 파이프라인이 환경의 변경 사항을 적용합니다. 수동 변경 또는 오류와 같은 모든 구성 드리프트는 GitOps 자동화에 의해 덮어쓰기되므로 환경이 Git에 정의된 원하는 상태로 수렴되어 지속적 운영(CO)을 제공합니다.

Red Hat OpenShift 오퍼레이터는 복잡한 워크로드의 설치 및 자동화된 오케스트레이션을 간소화합니다. 인간의 운영 로직을 인코딩하여 Kubernetes 네이티브 애플리케이션으로 실행되는 서비스를 관리하는 데 도움이 되므로 2일차 운영을 더 쉬우어집니다. 오퍼레이터는 클러스터의 팟에서 실행되는 소프트웨어로, Kubernetes API 서버와 상호 작용합니다. OpenShift 오퍼레이터는 기본적으로 맞춤형 컨트롤러이며 사실상 애플리케이션별 컨트롤러일 수 있습니다.

Red Hat OpenShift는 필수 오퍼레이터를 제공하여 개발자가 GitOps를 쉽게 사용할 수 있도록 지원합니다. 배포가 완료되면 OpenShift 콘솔의 설치된 오퍼레이터 섹션에서 확인할 수 있습니다. Red Hat OpenShift GitOps 오퍼레이터는 ArgoCD의 업스트림 오퍼레이터이며, 마찬가지로 배포되는 Red Hat OpenShift Pipelines 오퍼레이터는 Tekton의 업스트림 오퍼레이터입니다. (그림 3 참조)

그런 다음 오퍼레이터 및 관련 API를 사용하여 Git에서 원하는 구성 결과를 가져와 다양한 환경에 배포할 수 있는 하나 이상의 GitOps 파이프라인을 시작할 수 있습니다. 환경은 일반적인 개발, 테스트, 프로덕션 환경일 수도 있지만, 엔터프라이즈 클라우드, 통신사 네트워크 또는 엣지 컴퓨팅 노드와 같은 지리적 환경도 포함될 수 있습니다.

배포 리소스는 인프라, 서비스, 애플리케이션의 세 영역으로 분류됩니다. 이러한 영역을 사용하면 관련 리소스의 배포를 쉽게 분리하고 관리할 수 있습니다.

• 인프라에는 필요한 네임스페이스와 스토리지가 정의되어 있습니다.
• 서비스에는 인스턴스를 설정하는 데 필요한 다양한 오퍼레이터가 설명되어 있습니다.
• 애플리케이션에는 배포될 애플리케이션이 열거되어 있습니다.

엣지 컴퓨팅은 대부분의 IT 센터에서 OpenShift 또는 Kubernetes 클러스터의 확산을 보여주고 있습니다. 고객당 수백에서 수천 개의 배포에 이르는 거대한 규모에 도달할 잠재력을 가지고 있습니다. 그 결과, 엔터프라이즈 IT 부서는 온프레미스 및/또는 퍼블릭 클라우드에서 실행되는 여러 독립 또는 협력 컨테이너 런타임 클러스터를 관리해야 합니다.

여러 클라우드에서 변경 사항을 롤아웃하고 롤백하는 등 클러스터가 원하는 상태를 동일하게 유지하는 것은 GitOps가 엣지 및 IoT 기반 비즈니스에 제공하는 주요 이점입니다.

통신 서비스 공급자(CSP)가 직면한 주요 과제 중 하나가 네트워크의 오케스트레이션, 자동화, 관리할 방법을 찾는 것이기 때문에 GitOps 패러다임을 네트워크 엣지에 적용할 수 있습니다. 5G는 소비자에게 도움이 되지만, 소프트웨어 정의 네트워크(SDN), 다양한 대역폭을 갖춘 네트워크 슬라이싱, 더 빠른 배포는 통신사에 어려움을 안겨주었습니다.

자동화된 배포 파이프라인은 CSP가 고객에게 서비스를 더 빠르게 제공할 수 있는 한 가지 방법입니다. 컨테이너 인프라 프로비저닝에 대한 중앙 리포지토리와 선언적 접근 방식을 사용하면 새로운 기능 및 변경 요청에 대한 출시 시간을 단축할 수 있습니다. 이러한 패러다임은 네트워크 엣지에서 가상 네트워크 기능(VNF) 및 클라우드 네이티브 네트워크 기능(CNF)를 프로비저닝하는 데 도움이 됩니다. 네트워크 구성 요소의 컨테이너화를 통해 이러한 기능을 관리할 수 있습니다. 마지막으로, 모든 구성 활동이 Git에 기록되고 저장되기 때문에 변경 사항을 추적하는 기능은 규정 준수 및 감사 목적에 매우 중요합니다. 참고 자료에 WeaveWorks의 몇 가지 관련 블로그가 있습니다.

GitOps를 사용하면 조직이 여러 대상을 동시에 배포할 수 있습니다. 이를 통해 세분화된 배포를 롤아웃할 수 있습니다. 이는 다양한 형태와 폼 팩터로 제공되며 다양한 통신 프로토콜을 사용하는 수백, 수만 개의 엣지 노드에 애플리케이션을 배포할 때 매우 유용합니다. 특히 엣지 노드가 Intel NUC 또는 NVIDIA Jetson을 사용하는 소규모 엣지 클러스터인 경우 더욱 그렇습니다.

GitOps 프레임워크는 애플리케이션을 배포하고 Git 리포지토리를 신뢰할 수 있는 단일 소스로 활용하는 데 유용할 수 있습니다.ITOps 팀은 자율적인 애플리케이션 배포와 엣지 노드의 관리 및 운영을 추구하며, 이는 Red Hat OpenShift 오퍼레이터를 사용하여 지원됩니다.

GitOps의 이점은 네트워크 엣지와 엔터프라이즈 엣지에서 분명하게 드러납니다. 파 엣지 디바이스는 이들 중 일부의 스토리지 및 컴퓨팅 용량이 GitOps 서비스를 호스팅하고 애플리케이션을 실행하기에 충분하지 않다는 점에서 다른 과제를 안고 있습니다.

K3s 및 K0s와 같은 경량 Kubernetes 배포판의 릴리스는 IoT 및 엣지 사용 사례를 위한 것입니다. 엣지 디바이스에 경량 Kubernetes 배포판을 배포할 수 있는 기능을 통해 Argo CD와 같은 GitOps 도구를 실행할 수 있습니다. 그러면 디바이스는 원하는 상태에 대해 Git 리포지토리를 폴링하고 이를 클러스터의 라이브 상태와 동기화하는 풀 모델을 채택할 수 있습니다.