[사례연구] kt cloud OpenStack GitOps 배포 전략: Genestack 기반 CI/CD 자동화 구축 과정

 

 

[ kt cloud Foundation플랫폼팀 이지은 님 ]

📋 요약

kt cloud가 Genestack 기반으로 구축한 OpenStack GitOps 배포 자동화 시스템을 소개합니다.

Helm Chart와 ArgoCD를 활용해 컨테이너 이미지 빌드부터 배포까지 전 과정을 Git 기반으로 자동화한 실무 사례를 다룹니다.

#OpenStack #GitOps #Genestack #ArgoCD #Helm #자동화배포

---

kt cloud는 2024년 말, Rackspace와의 기술 협업을 통해 Genestack 기반의 OpenStack 배포 구조를 검토하고 실증하는 PoC를 진행했습니다. Genestack은 Rackspace가 자체적으로 개발한 배포 도구로, OVN 기반 네트워크 아키텍처와 함께 public/private cloud 환경을 일원화해 관리하기 위한 고민이 반영된 플랫폼입니다. PoC 기간 동안 우리는 Genestack이 OpenStack 컴포넌트를 Helm 기반으로 Kubernetes acc상에 배포하며, 템플릿화와 버전 관리에 강점을 지닌 구조임을 확인했습니다.

 

도입 전까지는 OpenStack 배포가 환경마다 수동 또는 스크립트 방식으로 진행되었고, 컴포넌트 간 버전 의존성, 배포 순서의 불일치, Git 외부에서의 변경 관리 등으로 인해 운영 자동화에 한계가 많았습니다. 특히 staging과 production 간 배포 신뢰도 확보가 어려워, 반복 작업임에도 결과의 재현성을 보장하기 어려운 구조였습니다.

 

이에 따라 kt cloud는 Genestack의 Helm/Kustomize 기반 설계와 GitOps 연동 가능성에 주목했습니다. 단순한 PoC를 넘어, 릴리즈 태그 기반의 자동화 → 환경별 YAML 랜더링 → Git 저장소 기반의 배포까지 연결되는 전체 흐름을 구축하고자 했습니다. 이는 단지 도구를 수용하는 것을 넘어, 향후 Genestack을 우리가 주도적으로 발전·확장하거나, 필요 시 우리 환경에 최적화된 자체 관리 도구로 분화할 수 있는 기반이 되기도 합니다.

---

kt cloud의 OpenStack GitOps 배포 구조는 총 4개의 Git 저장소를 축으로 구성됩니다.
먼저, ktc-openstack-helm과 ktc-openstack-helm-infra는 Rackspace에서 제공하는 OpenStack 및 외부 컴포넌트(mariadb, rabbitmq, nova 등)의 Helm Chart를 그대로 받아오는 upstream 역할을 합니다.

여기에 kt cloud의 환경에 맞춘 설정을 덧입히는 저장소가 바로 ktc-genestack-region입니다. 이곳에서는 환경별로 helm-overrides, kustomize.yaml, deploy-list.yaml을 관리하며, chart와 value를 결합해 실제 배포 가능한 YAML을 랜더링할 수 있도록 구성되어 있습니다.

 

랜더링된 결과는 GitHub Actions 워크플로를 통해 stack-deployments-region 저장소에 커밋됩니다. 이 저장소는 ArgoCD가 GitOps 방식으로 배포를 수행하는 배포 대상 저장소로, 각 OpenStack 컴포넌트 별 YAML(manifests)이 서비스 단위로 분리되어 저장됩니다. 또한 ArgoCD는 이 저장소를 기준으로 Root App → App of Apps 구조를 따릅니다.

예를 들어 stack-infra-apps은 mariadb, rabbitmq 등의 인프라 구성 요소를 포함한 하위 App들을 관리하고, stack-apps은 glance, nova, neutron 같은 실제 OpenStack 서비스를 관리합니다. 각각의 Root App은 별도로 ArgoCD에 등록되며, 이후에는 Git 저장소의 디렉토리 구조와 연동된 하위 App들이 자동으로 구성됩니다.

 

추가로 OpenStack 배포에 앞서 클러스터에 공통적으로 필요한 리소스(Namespace, Gateway API, StorageClass, SealedSecret 등)는 별도의 ktc-base-repo 저장소를 통해 관리되며, 이 리소스들은 base-root-app을 통해 ArgoCD에서 먼저 적용됩니다. 이로써 OpenStack 인프라 및 서비스 배포가 원활하게 진행될 수 있는 기반 환경을 사전에 구성합니다.

 

결과적으로 kt cloud의 OpenStack 배포 구조는 Helm 기반 선언형 구성 위에, kustomize를 활용한 환경 맞춤형 Overlay, Git 저장소를 통한 변경 이력 및 배포 추적, 그리고 ArgoCD 기반의 자동화까지 유기적으로 연결된 완성도 높은 GitOps 체계를 이루고 있습니다.

---

kt cloud의 OpenStack CI/CD 배포 과정은 Genestack 기반의 Helm Chart와 kustomize를 결합해 환경별 설정을 유연하게 구성하고, 컨테이너 이미지부터 YAML 렌더링, GitOps 배포까지 전 과정을 자동화한 구조를 지향합니다.

OpenStack 서비스를 구성하는 각 컴포넌트(nova, glance, neutron 등)는 ktc-osp-loci 저장소에서 loci 기반으로 빌드한 경량화된 컨테이너 이미지로 제공되며, 빌드된 이미지는 Harbor에 업로드되어 Helm Chart에서 참조됩니다. 이 과정을 통해 빌드-패키징-배포 전체가 GitOps와 ArgoCD 기반 하나의 파이프라인 내에서 자동화 관리됩니다.

 

전체 배포 흐름은 크게 다음 순서로 나뉘며, 아래에서 구체적으로 설명드립니다.
① 공통 시스템 리소스 구성 → ② OpenStack Infra 구성 → ③ OpenStack 서비스 구성

 

---

1단계. Stack 이미지 빌드

가장 먼저 LOCI 기반으로 OpenStack 이미지들을 빌드합니다.
예를 들어 ktc-osp-loci 저장소에서 nova, glance, neutron 등의 stack-deploy.yaml 파일을 수정하면 GitHub Actions가 자동 실행되어 이미지가 빌드되고 Harbor에 push됩니다. 이때 이미지의 버전(tag)은 릴리즈 전략에 따라 브랜치 혹은 tag 기준으로 관리됩니다.

---

2단계. Config 업데이트

이미지가 준비되면, Helm Chart에서 사용할 override 값과 kustomization 설정을 ktc-genestack-md 저장소에서 환경별로 구성합니다.

• custom-helm-configs/ 에는 컴포넌트 및 환경 별 overrides.yaml 이 위치하며,
• base-kustomize/ 하위에 Openstack 컴포넌트 별 배포될 kustomization.yaml, namespace, secret, storageClass 등이 정의되어 있습니다.

기본적으로 운영 환경에서는 base/ 디렉토리를 사용하도록 workflow을 작성했고, staging 또는 테스트 환경에서는 aio/ 디렉토리를 선택적으로 활용할 수 있는데, 현재는 더 직관적으로 관리하기 위해 리전별로 별도의 디렉토리를 사용하고 있습니다.

---

3단계. Argo App 파일 구성

배포 대상 컴포넌트마다 argo-app/ 디렉토리에 하나씩 Application YAML을 생성합니다.
예: argo-app/cinder.yaml, argo-app/nova.yaml 등.
이 파일에는 ArgoCD Application 리소스 정의가 포함되며, 각 모듈의 이름, namespace, 대상 클러스터, 소스 repo와 path, revision 등이 명시됩니다.

---

4단계. YAML 파일 렌더링

배포 대상 서비스 목록은 deploy-list.yaml파일로 관리합니다. 렌더링 대상 서비스를 정하고 버전을 설정한 후 commit & push하면, GitHub Actions가 실행되어 Helm Chart + Override 값을 조합한 rendered.yaml 파일을 생성합니다.

이 파일은 yq 도구를 통해 리소스 단위로 분리되며, 최종적으로는 stack-deployments-md 저장소의 지정된 경로에 push됩니다. 예를 들어, openstack/nova.yaml, openstack/keystone.yaml처럼 서비스 단위로 분리되어 저장됩니다.

---

5단계. 공통 리소스 사전 배포 등록

OpenStack 인프라를 구성하기 전에, 클러스터에 필요한 공통 리소스를 ktc-base-repo를 통해 먼저 배포합니다. 이 저장소에는 다음과 같은 리소스들이 정의되어 있으며, base-root-app이라는 Root App을 통해 ArgoCD에서 먼저 적용됩니다:

• Namespace 정의
• Gateway API 및 Ingress 리소스
• MetalLB 및 L2Advertisement 설정
• StorageClass, PVC
• SealedSecret 및 TLS 인증서
• CoreDNS 설정 등

이 사전 리소스들은 OpenStack 인프라 구성에서 참조하는 부분을 포함하므로 사전에 반드시 적용되어야 합니다.

---

6단계. Root App 등록

ArgoCD에는 먼저 두 개의 Root App을 수동 등록합니다:

• openstack-infra-root-app
• openstack-root-app

Root App은 App of Apps 구조로, 실제 서비스별 Argo App들을 포함하는 상위 리소스입니다. 해당 리소스는 stack-deployments-md 저장소에 openstack-infra-application.yaml, openstack-application.yaml으로 따로 관리되며, ArgoCD에서는 이를 직접 연동하여 최초에 한 번만 생성해줍니다.

---

7단계. OpenStack Infra 컴포넌트 배포

openstack-infra-root-app을 통해 mariadb, rabbitmq 등 외부 의존성 서비스를 배포합니다. Root App을 Sync하면 하위 App들이 생성되고, 다시 각각의 App을 수동으로 Sync해 리소스를 실제 클러스터에 반영합니다. 이 단계는 OpenStack 서비스 배포에 앞서 반드시 완료되어야 하는 전제 조건입니다.

---

8단계. OpenStack 서비스 컴포넌트 배포

openstack-root-app을 통해 nova, glance, neutron 등 OpenStack 모듈들이 배포됩니다. 이 역시 Root App을 먼저 Sync한 뒤, 하위 App(nova, glance 등)을 지정된 순서대로 배포합니다.
일부 컴포넌트는 의존성 관계가 존재하므로 아래 순서대로 Sync하는 것을 권장합니다:

1. keystone
2. glance
3. cinder
4. placement
5. nova
6. neutron

---

마무리: 자동화와 통합의 조화

이와 같이 kt cloud의 구현 흐름은 단순히 Helm Chart를 사용하는 수준을 넘어서,

• LOCI 기반 컨테이너 이미지 빌드
• 환경별 config override
• ArgoCD 기반 GitOps 배포
• App of Apps 구조를 활용한 리소스 구조화

까지 완성도 높게 정립되어 있습니다.
운영자는 Git에 커밋하는 것만으로 환경별 OpenStack 구성 변경과 배포를 자동화할 수 있고,
ArgoCD UI 또는 CLI를 통해 배포 상태, 변경 이력, 동기화 여부까지 명확하게 파악할 수 있습니다.

 

Genestack 기반의 GitOps 배포 구조를 도입한 이후, kt cloud 내부에서는 OpenStack 배포 및 운영 효율성이 크게 향상되었습니다. 기존에는 환경마다 수동으로 설정을 적용하거나 배포 순서를 관리해야 했기 때문에, 동일한 구성을 반복하면서도 일관성을 유지하기 어려웠습니다. 하지만 지금은 이미지 빌드부터 설정 반영, 배포까지 전 과정이 Git 기반으로 관리되며, 변경 사항을 커밋하고 Push하는 것만으로 전체 시스템이 자동으로 구성되도록 체계화되었습니다.

 

특히, ktc-base-repo를 통한 공통 리소스 선배포 구조는 OpenStack 인프라 및 서비스 리소스가 안정적으로 동작할 수 있는 기반을 사전에 보장해주며, 장애 가능성을 줄이고 배포 전후 의존성 문제를 최소화했습니다. 또한, stack-deployments-md에 저장된 YAML 파일은 모두 버전 이력을 갖고 있어, 배포 이력 추적, 변경 비교(diff), 롤백 처리까지 매우 수월해졌습니다.

 

ArgoCD UI를 통해 실시간으로 배포 상태를 시각적으로 확인할 수 있고, Application 단위의 상태 동기화 여부(OutOfSync/Healthy 등)도 한눈에 확인할 수 있어 운영 편의성 역시 크게 높아졌습니다.
결과적으로, 배포 자동화 → 검증 시간 단축 → 운영 신뢰도 향상이라는 긍정적인 사이클이 자리잡게 되었고, 여러 리전/환경에 동일한 구조를 확장 적용할 수 있는 기반이 마련되었습니다.

 

kt cloud는 앞으로도 Genestack 기반의 배포 구조를 기반으로, 다양한 리전과 환경에 유연하게 확장 적용할 수 있는 자동화 체계를 지속적으로 고도화해 나갈 예정입니다.
이번 구조를 통해 확보한 재현성과 안정성을 바탕으로, 운영 효율은 물론 배포 품질까지 한층 더 향상될 수 있음을 확인했습니다.
앞으로도 실사용 환경에서 검증된 구조를 바탕으로, 더 빠르고 안전한 인프라 운영을 만들어갈 계획입니다.

---

❓ 자주 묻는 질문 (FAQ)

Q. Genestack 기반 GitOps 배포 구조의 핵심 장점은 무엇인가요?

A.Genestack 기반 GitOps 배포 구조의 핵심 장점은 다음과 같습니다. 🔄 완전 자동화된 배포 파이프라인 - 컨테이너 이미지 빌드부터 YAML 렌더링, 실제 배포까지 전 과정이 Git 커밋만으로 자동화 - 기존 수동/스크립트 방식 대비 배포 일관성과 재현성 대폭 향상 📊 체계적인 환경 관리 - 4개 Git 저장소를 통한 역할별 분리 (upstream, config, deployment, base) - 환경별 설정을 Helm overrides와 Kustomize로 유연하게 관리 - staging과 production 간 배포 신뢰도 확보 👁️ 실시간 모니터링 및 추적 - ArgoCD UI를 통한 배포 상태 실시간 시각화 - Git 기반 변경 이력 추적, diff 비교, 롤백 처리 용이 - Application 단위별 동기화 상태 (OutOfSync/Healthy) 명확한 파악 🏗️ 안정적인 의존성 관리 - App of Apps 구조로 인프라와 서비스 컴포넌트 단계별 배포 - 공통 리소스 선배포를 통한 의존성 문제 최소화 - keystone → glance → cinder → nova → neutron 순서의 체계적 배포 결과적으로 배포 자동화 → 검증 시간 단축 → 운영 신뢰도 향상의 선순환 구조를 구축할 수 있습니다.

---

📚 관련/출처

https://github.com/openstack/openstack-helm https://github.com/openstack/loci https://docs.rackspacecloud.com/genestack-getting-started/