[사례연구] 사내 개인용 개발환경 이미지 실험기 1부: git push로 업데이트되는 OpenStack 샌드박스 만들기

 

 

[ kt cloud Platform엔지니어링팀 이초환 님 ]

📋 요약

이 글에서는 GitOps 기반 개인용 OpenStack 샌드박스 이미지를 구축하고 업데이트하는 실험 과정을 다룹니다.

개발환경 표준화와 운영 부담 완화에 주는 실무적 의미를 정리합니다.

#OpenStack #GitOps #ArgoCD #FluxCD #Kubernetes

 

---

1. 배경 — 이 프로젝트를 시작한 맥락

저희 조직은 OpenStack 기반 서비스를 개발하고 있고, 여러 개발자·팀이 함께 쓰는 통합 개발환경이 있습니다.

 

통합환경은 각 서비스가 서로 상호작용하는 공유 공간이다 보니, 서비스를 단독으로 변경·테스트하려면 별도의 독립 환경이 필요합니다. 개인 단위 실험까지 공유 환경에서 하기엔 부담이 컸고, 그래서 개인별·서비스별 개발환경이 자연스럽게 필요해졌습니다.

 

이런 니즈에 대응하기 위해 저희는 통합 개발환경과 비슷한 구조의 개인용 OpenStack 샌드박스를 표준화해 제공한다는 방향을 잡았습니다. 운영·통합 환경과 구조 성격을 최대한 유지하되 개인이 받아 쓸 수 있는 크기로 줄이는 것입니다. 제공 경로는 두 가지로 잡았습니다.

1. 사내 클라우드에서 on-demand로 OpenStack 샌드박스 환경 제공
2. 개발자 로컬에서 바로 올려 쓸 수 있는 OpenStack 샌드박스 이미지 배포

이 글은 (2) 로컬 이미지 트랙의 1차 실험 기록입니다. 운영·통합 환경의 구조를 단일 VM 한 대에 그대로 담기는 어려워, 이번 1차에서는 단일 VM에 단일 클러스터로 접어넣는 방향으로 갔습니다.

---

2. 요건 정리

• OpenStack + ArgoCD 기반 GitOps. 운영 환경이 이미 ArgoCD 기반이어서 샌드박스에서 실험한 매니페스트가 운영으로 자연스럽게 넘어가야 합니다.
• 누가 받아도 같은 환경.
• 운영 환경과 구조 정합. 지금은 단일 VM이라도 멀티노드로 확장 가능한 뼈대와 동일한 배포 도구(helm, kustomize, ArgoCD)를 써야 합니다.
• 배포 이후에도 업데이트 경로. 컴포넌트 업데이트, 보안 패치, 설정 변경이 꾸준히 생기므로 이미지 재빌드 없이 반영되는 경로가 있어야 합니다.

이 요건들을 종합한 선택이 "단일 VM 이미지 + GitOps 컨트롤러 선탑재 + 애플리케이션 정의는 Git 레포에서 관리" 였습니다.

---

3. 이미지와 Git의 경계

이미지는 qcow2로 구워 부팅 후 약 10분 안에 OpenStack 환경이 Ready에 도달하게 했습니다. 여기까지는 흔한 이미지 배포 방식입니다.

 

차이는 이미지 안에 ArgoCD와 Flux를 함께 설치해두고, 빌드 타임에 OpenStack 컴포넌트도 한 번 배포한 뒤 그 상태 그대로 이미지로 굳혔다는 점입니다. 즉 부팅하면 OpenStack은 이미 배포된 상태로 올라옵니다. 다만 source of truth(클러스터가 어떤 상태여야 하는지 정의하는 단일 기준점)는 이미지가 아니라 Git 레포에 있어, 컨트롤러들이 부팅 후 stack-deployments-sandbox 레포를 계속 watch하면서 Git에 변경이 생기면 그쪽으로 클러스터 상태를 맞춰갑니다.

 

이미지에 들어간 것

• Ubuntu 24.04, containerd, Kubernetes 컨트롤 플레인(kubeadm, CNI, local-path-provisioner)
• ArgoCD + Flux (빌드 타임에 설치 완료)
• 빌드 타임에 한 번 배포된 OpenStack 코어 6종 + 인프라 의존성 3종의 초기 상태
• OpenStack 및 의존성 컨테이너 이미지 pre-pull, 부팅 시 IP 교체 systemd 서비스

Git 레포(stack-deployments-sandbox)에 둔 정의들

• Harbor OCI HelmRepository, values ConfigMap (아키텍처별 values/arm64/, values/amd64/)
• OpenStack 코어 6종(keystone, glance, placement, cinder, neutron, nova)과 인프라 의존성 3종(mariadb, rabbitmq, memcached)의 HelmRelease
• ArgoCD Application, ExternalSecret / ClusterSecretStore (시크릿 처리 등 트러블슈팅·상세 설정은 2부에서 다룹니다)

이미지에 든 OpenStack 초기 상태와 Git의 정의가 일치하면 부팅 후 그대로 유지되고, Git 정의가 바뀌면 ArgoCD/Flux가 차이를 감지해 cluster를 Git 상태로 수렴시킵니다. 즉 "처음 배포 한 번"은 이미지가 책임지고, 그 이후의 모든 변경은 Git이 책임지는 구조입니다.

 

이 글에서 "OpenStack 컴포넌트"로 묶어 부를 때는 keystone·glance·placement·cinder·neutron·nova 6종을 의미합니다. mariadb·rabbitmq·memcached는 OpenStack을 돌리기 위한 인프라 의존성으로 별도 분류합니다.

 

경계의 기준은 "얼마나 자주 바뀌는가"였습니다. 이미지에는 분기별로도 거의 손대지 않는 영역(커널·런타임·컨트롤 플레인)만 두고, values·이미지 태그·probe처럼 운영 중 계속 바뀌는 영역은 Git에 뒀습니다. 배포된 샌드박스 이미지가 10대든 100대든 동일한 변경을 전파하는 비용이 이 경계에 달려 있기 때문입니다.

 

이번 1차에서는 OpenStack Helm 차트는 외부 차트를 사내 Harbor OCI에 올려 그대로 사용했고, 컨테이너 이미지는 사내 이미지를 활용했습니다. 운영 환경에는 사내 노하우가 반영된 사내 차트가 따로 있어, 다음 시도에서는 그쪽으로 전환해 운영과의 구조 정합을 한 단계 더 높일 계획입니다.

 

ArgoCD + Flux HelmRelease 혼합 구조 자체의 설계 철학은 https://tech.ktcloud.com/entry/2026-01-ktcloud-openstack-helm-gitops-배포-전환 에 자세히 나와 있습니다.

[실전가이드] OpenStack Helm 배포를 GitOps로 전환: FluxCD+Argo CD 아키텍처 설계와 운영 전략

---

4. 완성된 구조와 부팅 흐름

이미지를 UTM(macOS)·libvirt(Linux)에 import해 부팅하면, systemd 서비스가 현재 IP를 감지해 apiserver 인증서·kubeconfig를 재발급하면서 빌드 타임에 배포된 OpenStack이 새 IP 환경에 맞춰 Ready로 올라옵니다. 동시에 ArgoCD·Flux가 Git 레포 watch를 시작하고, Git 정의에 변경이 있으면 cluster 상태를 그쪽으로 수렴시킵니다. 전체 흐름이 약 10분 안에 끝납니다.

---

5. 현재 상태와 다음 스텝

확인된 것

• ARM64 단일 VM qcow2 이미지(~5.6GB). macOS UTM에서 import 후 10분 내 OpenStack 환경 Ready
• OpenStack 코어 6종(keystone, glance, placement, cinder, neutron, nova)과 인프라 의존성 3종(mariadb, rabbitmq, memcached) 모두 Running
• Git 레포 수정 → 배포된 이미지 OTA 반영 체인 정상 동작 (values 보정·컴포넌트 설정 변경 같은 작업을 git push로 전파해 검증)
• AMD64 이미지도 동일 구조로 1차 작성 완료

다음 스텝

• 축소 구조를 운영 환경에 더 가깝게: 이번 1차는 여러 요소를 단일 클러스터에 접어넣은 형태입니다. 운영 환경과의 구조 정합을 더 높이려면 여러 클러스터로 분리해 가야 하는데, 로컬 이미지 트랙은 개발자 노트북의 리소스 제약이 커서 사내 클라우드 개인용 환경 제공 트랙에서 먼저 그 확장을 다룰 예정입니다
• 외부 차트 → 사내 차트 전환: 1차에서는 외부 openstack-helm 차트를 그대로 사용했지만, 다음 단계에서는 운영 환경에 적용된 사내 노하우가 담긴 사내 차트로 전환할 계획입니다. 운영과의 구조 정합도 한 단계 좁혀질 것으로 보고 있습니다
• nested virtualization: 샌드박스 안에서 실제 OpenStack 인스턴스를 띄우기 위한 검증 진행 중 (Apple Silicon + Lima)

---

6. 마치며

이미지 배포 단계까지는 기존 방식에도 있었지만, 배포 이후 개발자 각자가 환경을 손보는 방식은 조직 차원에서 관리되지 않던 영역이었습니다. GitOps 컨트롤러를 이미지에 심고 애플리케이션 정의를 Git으로 빼두자, 이미 배포된 모든 이미지가 같은 Git 레포를 바라보며 함께 따라가는 구조의 윤곽이 잡혔습니다.

 

여기까지가 지금 시점의 결과입니다. 멀티 클러스터 확장, 외부 차트 대신 운영 노하우가 반영된 사내 차트로의 전환, nested virt로 실제 인스턴스를 띄우는 검증 같은 큰 숙제들이 아직 남아 있어서 잘 풀릴지는 다음 단계들을 진행해보면서 확인할 부분이고, 진행되는 대로 후속 기록으로 또 공유드리겠습니다.

 

다음 글에서는 이 구조를 세우는 과정에서 마주친 자잘한 트러블슈팅과 신경 써야 했던 상세 설정, 그리고 보안적으로 짚은 지점들을 풀어둡니다.

 

---

❓ 자주 묻는 질문 (FAQ)

Q. DevStack이나 MicroStack을 쓰면 되지 않나요?

A. 운영 환경이 openstack-helm 기반이라 DevStack/MicroStack과는 구조가 달라, 운영과 동일한 openstack-helm + Kubernetes를 단일 VM에 담는 방향으로 갔습니다.

Q. 왜 일단 단일 VM인가요? 운영은 멀티노드인데?

A. 운영은 멀티노드라 이후엔 그쪽으로 확장해야 하지만, 개발자 노트북의 리소스 제약과 "빌드·OTA 파이프라인을 먼저 안정화한 뒤 확장한다"는 판단으로 1차는 단일 VM입니다.

Q. 한 번 배포된 이미지가 어떻게 자동으로 업데이트되나요?

A. 이미지에는 빌드 타임에 한 번 배포된 OpenStack 초기 상태와 함께 ArgoCD·Flux가 들어 있습니다. 부팅 후 두 컨트롤러가 지정된 Git 레포를 watch하면서 cluster 상태를 Git 정의에 맞춰 유지하고, 이후 설정 변경은 레포에 git push만 하면 배포된 모든 이미지에 자동 반영됩니다.

---

📚 관련/출처

[실전가이드] OpenStack Helm 배포를 GitOps로 전환: FluxCD+Argo CD 아키텍처 설계와 운영 전략 [가이드] kt cloud에서 사용하는 Umbrella Helm Chart 설계 전략 [사례연구] kt cloud OpenStack GitOps 배포 전략: Genestack 기반 CI/CD 자동화 구축 과정 openstack-helm: Welcome to OpenStack-Helm’s documentation! — openstack-helm 2026.1.1.dev71 documentation FluxCD HelmController: Helm Controller ArgoCD Application: Declarative Setup - Argo CD - Declarative GitOps CD for Kubernetes