엣지에서의 GitOps
최근 몇 년 동안 우리는 점점 더 많은 기업이 Git을 리포지토리로 사용하는 DevOps 패러다임인 GitOps를 채택하는 것을 보았습니다.
GitOps는 몇 년 동안 사용되어 왔지만, 최근 컨테이너와 컨테이너 런타임 환경의 일관된 배포 및 관리를 둘러싼 복잡성으로 인해 주목을 받고 있습니다.
GitOps가 해결하려는 문제는 무엇일까요?? GitOps는 기업이 소프트웨어 엔지니어링을 더 원활하게 할 수 있도록 소프트웨어 운영을 자동화합니다. 이를 통해 애플리케이션 팀은 더 자주 릴리스하고 클라우드 네이티브 애플리케이션을 더 효과적으로 운영할 수 있습니다.
이 블로그에서는 GitOps를 엣지 토폴로지에 적용할 수 있는지, 특히 원거리 엣지 디바이스에 애플리케이션을 배포할 수 있는 CI/CD 파이프라인을 생성할 수 있는지 살펴봅니다. 다시 말해, 엣지는 엔터프라이즈 엣지 및 네트워크 엣지와 함께 멀리 떨어진 엣지 디바이스부터 클라우드까지를 포괄합니다.
GitOps는 Git을 원하는 구성 상태를 저장하는 신뢰할 수 있는 단일 소스로 사용하는 DevOps 방식입니다. 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 파이프라인을 시작할 수 있습니다. 환경은 일반적인 개발, 테스트, 프로덕션 환경일 수도 있지만, 엔터프라이즈 클라우드, 통신사 네트워크 또는 엣지 컴퓨팅 노드와 같은 지리적 환경도 포함될 수 있습니다.
배포 리소스는 인프라, 서비스, 애플리케이션의 세 영역으로 분류됩니다. 이러한 영역을 사용하면 관련 리소스의 배포를 쉽게 분리하고 관리할 수 있습니다.
- 인프라에는 필요한 네임스페이스와 스토리지가 정의되어 있습니다.
- 서비스에는 인스턴스를 설정하는 데 필요한 다양한 오퍼레이터가 설명되어 있습니다.
- 애플리케이션에는 배포될 애플리케이션이 열거되어 있습니다.
이전 블로그에서 엣지 컴퓨팅 도메인의 DevOps에 대해 설명했으며, 여기서는 GitOps를 엣지 컴퓨팅에 어떻게 적용할 수 있는지 살펴보겠습니다. 다음과 같은 엣지 컴퓨팅의 세 가지 엣지를 언급했습니다.
- 엔터프라이즈 엣지
- 네트워크 에지
- 디바이스 엣지(또는 파 엣지)
클라우드 또는 엔터프라이즈 데이터 센터도 있습니다. 이러한 영역에 대해 자세히 살펴보겠습니다. 그림 4는 엣지 환경과 함께 세 가지 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 리포지토리를 폴링하고 이를 클러스터의 라이브 상태와 동기화하는 풀 모델을 채택할 수 있습니다.
GitOps를 사용하면 인프라 및 애플리케이션 구성 확산 문제를 해결할 수 있습니다. Red Hat OpenShift에 내장된 GitOps 오퍼레이터를 사용하면 Argo CD 기반 파이프라인을 쉽게 구현할 수 있습니다. IBM® Cloud Pak for Network Automation을 비롯한 IBM Cloud Pak 고객은 Red Hat 오퍼레이터를 활용하여 리소스를 설치하고 GitOps 프레임워크를 사용하여 배포 프로세스를 자동화하고 제어할 수 있습니다.
IBM® Cloud Native Toolkit은 좋은 시작점으로, 애플리케이션 개발 및 운영 배포를 가능하게 하는 오픈 소스 자산 컬렉션입니다.
기사를 검토해 주신 Hollis Chui와 Kavitha Bade에게 특별히 감사드립니다.