![[사례연구] 사내 개인용 개발환경 이미지 실험기 1부: git push로 업데이트되는 OpenStack 샌드박스 만들기](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FudZrI%2FdJMcaaeH5r8%2FAAAAAAAAAAAAAAAAAAAAAIKfNGqN4KRi33079aGygqF7eXoyJh53s8Ti7VSCvC1E%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1782831599%26allow_ip%3D%26allow_referer%3D%26signature%3DMbQ%252FFsUXjPxMK6j%252B2%252F2PQ9U4j6Y%253D)
데브옵스
[사례연구] 사내 개인용 개발환경 이미지 실험기 1부: git push로 업데이트되는 OpenStack 샌드박스 만들기
두줄요약
OpenStack 기반 개인용 샌드박스 이미지를 단일 VM에 GitOps 방식으로 구성했습니다.부팅 후 ArgoCD와 Flux가 Git 변경을 반영해 git push만으로 업데이트되도록 실험했습니다.
핵심 내용
- OpenStack 기반 통합 개발환경의 공유 제약을 줄이기 위한 개인용 샌드박스 이미지 실험
- 단일 VM 이미지에 OpenStack 초기 배포 상태와 GitOps 컨트롤러를 함께 넣어 부팅 후 Git 레포와 동기화하는 구조
- 이미지에는 고정적인 런타임·컨트롤 플레인만 두고, 자주 바뀌는 설정과 배포 정의는 Git에서 관리
구조와 흐름
- qcow2 이미지 부팅 후 systemd가 IP를 재인식하고 인증서·kubeconfig를 재발급해 환경 재정렬
- ArgoCD와 Flux가 stack-deployments-sandbox 레포를 watch하며 Git 변경을 클러스터 상태에 반영
- OpenStack 코어 6종과 인프라 의존성 3종을 HelmRelease와 관련 정의로 관리
선택 이유
- 운영 환경과 같은 구조 성격을 유지하면서도 개인이 쓸 수 있는 크기로 축소하려는 목적
- 이미지 재빌드 없이 업데이트를 전파하기 위한 GitOps 경로 필요
- 멀티노드 확장 가능성을 남기면서도 1차는 노트북 자원 제약에 맞춘 단일 VM 우선
적용해볼 점
- 변경 빈도에 따라 이미지와 Git의 책임 경계 분리
- 운영과 동일한 배포 도구와 선언형 정의를 초기부터 맞춰두기
- 부팅 후 자동 복구와 지속 동기화가 되는 개인용 개발환경 설계