OpenStack을 공부하다 보면 결국 openstack 명령어와 친해져야 합니다. Horizon(웹 대시보드)도 좋지만, 실무·자동화는 CLI가 기본이거든요. DevStack 실습에서 실제로 쓴 명령들을 바탕으로, 입문자가 꼭 알아야 할 openstack CLI를 정리합니다.
1. 인증부터 — openrc
모든 명령은 인증 토큰이 필요합니다. DevStack은 openrc 스크립트를 주는데, 이걸 source하면 환경변수로 로그인 정보가 들어갑니다.
# 관리자(admin) 자격으로 환경 설정
source /opt/stack/devstack/openrc admin admin
# 토큰 확인(로그인 됐나)
openstack token issue -f value -c id | head -c 20; echo
자원(server·network·image·flavor·subnet…)만 바꾸면 되니, list/create/show/delete 네 동작으로 대부분을 합니다.
3. 상태 점검 3종 세트
클라우드가 정상인지 볼 때 제가 가장 먼저 치는 명령들입니다.
# 카탈로그에 서비스가 다 떴나
openstack service list
# 컴퓨트 노드(하이퍼바이저)가 살아있나
openstack hypervisor list
# 컴퓨트 서비스 상태(up/down)
openstack compute service list
실제로 DevStack 디버깅 때 hypervisor list가 비어 있어서 “컴퓨트 미등록”을 바로 알아챘습니다. CLI가 문제를 가장 빨리 보여줍니다.
4. 인스턴스 하나 띄우는 전체 흐름
이미지·플레이버·네트워크를 조합해 VM을 만듭니다.
# 재료 확인
openstack image list # OS 이미지
openstack flavor list # 사양(vCPU/RAM/디스크)
openstack network list # 네트워크
# 인스턴스 생성 (이미지+플레이버+네트워크)
openstack server create myvm \
--image cirros --flavor m1.nano --network testnet --wait
# 결과 확인
openstack server list
openstack console log show myvm # 부팅 로그(진짜 떴나)
--wait는 생성이 끝날 때까지 기다려 줍니다. 실패하면 openstack server show myvm -f value -c fault로 원인을 봅니다(저는 이걸로 “No valid host”를 확인했습니다).
5. 출력 다루기 — 자동화의 시작
CLI의 진짜 힘은 출력을 가공할 수 있다는 점입니다.
# 특정 값만 뽑기 (스크립트에 유용)
NET_ID=$(openstack network create testnet -f value -c id)
# 표 형식 / JSON 형식
openstack server list -f table
openstack server list -f json
-f value -c <컬럼>으로 ID만 뽑아 변수에 담으면, 그대로 쉘 스크립트 자동화로 이어집니다.
6. 정리
openstack CLI는 ①openrc로 인증 → ②자원 동작 패턴 → ③-f value -c로 값 추출 이 세 가지만 잡으면 끝입니다. 웹 대시보드로 감을 잡되, 반복·자동화는 CLI로 가세요. 클라우드 엔지니어의 실력은 결국 이 명령어들이 손에 붙는 데서 나옵니다.
지난 편까지 DevStack을 홈랩에 올리며 CPU·Neutron·Glance·Placement에서 연달아 부딪히고 하나씩 해결했습니다. 이번 편은 그 여정의 솔직한 후기와 교훈입니다. 결과를 미화하지 않고, 홈랩에서 DevStack에 도전할 분께 실질적인 지도를 남기려 합니다.
1. 어디까지 됐고, 무엇이 남았나
정직하게 말하면 “완벽한 원클릭 성공”은 아니었습니다.
✅ 코어 서비스 전부 기동(Keystone·Glance·Nova·Neutron·Cinder·Placement)
✅ geneve 테넌트 네트워크 생성 성공, 하이퍼바이저 등록, 이미지 업로드, 플레이버 확인
❌ 인스턴스 최종 부팅은 placement 자원 클래스 누락으로 막힘 — 여러 번의 부분 설치가 누적돼 생긴 불일치가 근본 원인
즉 OpenStack의 뼈대는 다 세웠지만, 마지막 조립이 어긋난 상태였습니다. 그리고 그 어긋남의 원인까지 정확히 짚었다는 게 이 도전의 진짜 소득입니다.
2. 가장 큰 교훈 — “깨끗한 상태에서 한 번에”
이번 삽질의 뿌리는 하나였습니다: 중간에 실패한 설치 위에 계속 재시도한 것. DevStack은 실행 때마다 여러 서비스의 DB를 다시 만들고 마무리 단계를 수행하는데, 앞 단계에서 죽으면 뒷 단계가 통째로 생략됩니다. 그 위에 또 돌리면 서로 다른 실행의 잔재가 뒤섞여 새로운 증상이 끝없이 나옵니다.
다음엔 실패하면 미련 없이 ./clean.sh로 초기화하고, 모든 수정을 local.conf에 미리 반영한 뒤 깨끗한 상태에서 한 번에 완주시키겠습니다.
3. 홈랩 DevStack 체크리스트 (다음 도전용)
항목
이유
OS는 Ubuntu (22.04/24.04)
DevStack 공식 지원
VM CPU 타입 = host
x86-64-v2 미노출 시 NumPy 크래시
RAM 12GB+ / 디스크 40GB+
올인원 최소선
local.conf에 geneve 명시
테넌트 네트워크 할당 실패 방지
실패 시 clean.sh 후 재시작
부분 설치 누적 방지(가장 중요)
완주 후에도 서비스 재시작 점검
엔드포인트/동기화 지연 대응
4. DevStack에 대한 현실 감각
DevStack은 “개발/학습용”입니다. 운영용이 아니고, 재부팅하면 상태가 깨지기도 합니다. 공부하고 부수고 다시 까는 용도로 쓰세요.
무겁습니다. 올인원도 12~16GB를 먹고, 설치에 수십 분이 걸립니다. 홈랩에선 “쓸 때만 켜는 랩”이 현실적입니다.
그럼에도 배움은 큽니다. 이 과정에서 CPU 가상화(x86-64-v2), Neutron의 geneve, placement의 자원 모델, 서비스 간 의존성을 에러를 통해 몸으로 익혔습니다. 매끄러운 성공보다 이 삽질에서 더 많이 배웠습니다.
5. 마치며
“튜토리얼대로 했는데 왜 안 되지?”는 홈랩의 일상입니다. 이번 DevStack 도전도 7번 넘게 깨졌지만, 각 실패의 원인을 파고드는 과정 자체가 클라우드 인프라를 이해하는 가장 빠른 길이었습니다. 다음엔 clean.sh 원샷으로 완주시키고, 실제 인스턴스를 띄워 SSH로 접속하는 순간까지 이어가는 후속편으로 돌아오겠습니다. 홈랩에서 프라이빗 클라우드에 도전하는 분들, 깨져도 그게 정상입니다. 원인을 하나씩 잡으면 됩니다.
프라이빗 클라우드를 제대로 공부하려면 OpenStack을 직접 깔아봐야 합니다. 가장 빠른 길이 DevStack — 스크립트 하나로 올인원 OpenStack을 올려주는 개발/학습용 도구죠. 저는 이걸 Proxmox 홈랩에 올려봤습니다. 결론부터 솔직히 말하면 한 방에 안 됐고, 여러 번 깨졌습니다. 이번 편은 설치 준비부터 첫 번째 벽까지의 실전 기록입니다.
1. 먼저 정한 것 — OS는 Ubuntu
제 홈랩엔 Rocky 9 설치용 VM이 있었지만, DevStack엔 안 썼습니다. DevStack은 사실상 Ubuntu 전용이거든요(공식 지원·테스트가 우분투 중심). Rocky/CentOS는 지원이 불안정합니다. 그래서 깨끗한 Ubuntu 24.04로 갔습니다.
RuntimeError: NumPy was built with baseline optimizations:
(X86_V2) but your machine doesn't support: (X86_V2).
원인은 가상 CPU 타입이었습니다. Proxmox VM의 기본 CPU 타입(kvm64)은 호환성을 위해 최신 명령어셋(SSE4.2 등, x86-64-v2)을 감춥니다. 그런데 요즘 NumPy 휠은 x86-64-v2를 전제로 빌드돼서, 그 명령어가 없으면 임포트 단계에서 크래시합니다. nova의 콘솔 프록시가 NumPy를 쓰다 죽은 거죠.
해결은 지난 KVM 글에서 다룬 바로 그 포인트 — CPU 타입을 host로 바꿔 물리 CPU 기능을 그대로 노출하는 것이었습니다.
qm stop 200
qm set 200 --cpu host # 물리 i5의 명령어셋 그대로 노출
qm start 200
# VM 안에서 확인 — 이제 노출됨
grep -o -m1 sse4_2 /proc/cpuinfo # sse4_2
grep -o -m1 avx2 /proc/cpuinfo # avx2
이건 일반 DevStack 튜토리얼엔 없는 함정입니다. 물리 서버나 워크스테이션에선 안 생기고, “기본 CPU 타입 가상머신”에서만 터지거든요. 홈랩에서 VM으로 OpenStack·AI 라이브러리를 돌린다면 --cpu host는 기본으로 챙기세요.
다음 편
CPU를 고치고 다시 ./stack.sh를 돌렸습니다. 그런데 이번엔 네트워크(Neutron)에서, 그다음엔 Glance에서, 또 placement에서 연달아 막혔습니다. 다음 편에서 이 “서비스는 뜨는데 안 되는” 연속 삽질과 각각의 원인을 낱낱이 분석합니다. DevStack이 홈랩에서 왜 만만치 않은지, 제대로 보여드리겠습니다.
OpenStack 스토리지는 Glance(이미지)로 시작 → Cinder(블록)로 디스크 확장 → Swift(오브젝트)로 파일 보관, 이 세 축이 전부입니다. “블록은 디스크처럼, 오브젝트는 드라이브처럼”만 기억하면 헷갈릴 일이 없습니다. 홈랩 랩에선 Glance + Cinder(LVM)부터 붙여보는 걸 권합니다.
OpenStack을 공부하다 보면 대부분 Neutron(네트워킹)에서 벽을 만납니다. 저도 그랬습니다. 컴퓨트·스토리지는 직관적인데, 네트워크는 개념이 겹겹이라 헷갈리죠. 이번 글은 홈랩 랩에서 삽질하며 정리한 Neutron 핵심 개념 지도입니다. 이거 하나 잡으면 OpenStack의 절반은 끝납니다.
1. 왜 Neutron이 어려운가
Neutron은 소프트웨어로 네트워크(스위치·라우터·방화벽)를 통째로 구현합니다(SDN). 물리 네트워크 지식 + 가상 네트워크 개념 + 여러 에이전트가 한꺼번에 얽혀서 어렵게 느껴지는 겁니다. 그래서 개념을 계층으로 쪼개서 봐야 합니다.
2. 두 가지 네트워크 — Provider vs Tenant
Provider 네트워크
Tenant(Project) 네트워크
정체
기존 물리망에 직접 연결
프로젝트별 격리된 가상망
관리 주체
관리자
사용자(테넌트)
용도
외부와 바로 통신
내부 인스턴스끼리
격리
없음(공용)
VLAN/VXLAN으로 격리
쉽게 말해 Provider는 “회사 실제 네트워크에 꽂는 선”, Tenant는 “내 프로젝트만의 사설망”입니다. 실제 클라우드에선 테넌트망(사설) + 라우터 + 외부 provider망 조합을 가장 많이 씁니다.
3. 핵심 구성요소
ML2 플러그인 + L2 에이전트: 실제 스위칭 담당(Open vSwitch 또는 Linux Bridge). VLAN/VXLAN으로 망을 나눔.
L3 에이전트: 가상 라우터. 테넌트망 ↔ 외부망 라우팅, Floating IP 처리.
DHCP 에이전트: 인스턴스에 IP 자동 할당.
Security Group: 인스턴스 단위 방화벽(포트 허용/차단).
4. Floating IP — 외부 접속의 핵심
인스턴스는 보통 사설 IP만 가집니다. 외부에서 접속하려면 Floating IP(외부망의 공인/실 IP)를 인스턴스에 “붙였다 뗐다” 합니다. 개념이 NAT과 같아서, Floating IP ↔ 인스턴스 사설 IP를 라우터(L3 에이전트)가 매핑합니다.
외부 사용자 → Floating IP(외부망) → [L3 라우터/NAT] → 인스턴스 사설 IP
“인스턴스는 만들었는데 SSH가 안 돼요”의 99%는 Floating IP 미할당 + Security Group에서 22번 미허용입니다. 이 둘을 먼저 확인하세요.
5. 홈랩 랩에서의 배치
컨트롤러: neutron-server(API) + DHCP/L3 에이전트
컴퓨트: L2 에이전트(OVS/Linux Bridge)만
외부망은 Proxmox의 Linux Bridge(vmbr)에 물려 provider 네트워크로 노출
즉 Proxmox의 브리지가 OpenStack provider 네트워크의 물리 기반이 됩니다. 중첩 구조라 처음엔 헷갈리지만, “Proxmox 브리지 = 물리망, 그 위에 Neutron 가상망”으로 이해하면 정리됩니다.
6. 공부 순서
Provider 네트워크부터: 기존 망에 인스턴스를 직접 붙여 “통신되는 것”을 먼저 경험.
Tenant 네트워크 + 라우터: 사설망을 만들고 라우터로 외부와 연결.
Floating IP + Security Group: 외부 접속과 방화벽까지.
7. 정리
Neutron은 “Provider(실제망) vs Tenant(가상 사설망)”와 “L2(스위칭)·L3(라우팅/Floating IP)·Security Group(방화벽)”이라는 두 축으로 나눠 보면 정리됩니다. 외부 접속이 안 될 땐 Floating IP와 Security Group부터. 이 구조가 손에 익으면 OpenStack이 훨씬 만만해집니다.
OpenStack을 처음 보면 Nova, Neutron, Cinder, Keystone, Glance… 낯선 이름에 압도됩니다. 하지만 각각이 “클라우드의 한 부품”이라고 생각하면 의외로 명료합니다. 제가 홈랩 랩에서 공부하며 정리한, 핵심 컴포넌트 지도를 공유합니다.
1. 컴포넌트 한눈에
컴포넌트
역할
익숙한 비유
Keystone
인증·권한(Identity)
로그인·출입증
Glance
OS 이미지 저장소
설치 ISO 창고
Nova
컴퓨트(인스턴스 생성)
VM을 찍어내는 공장
Neutron
네트워킹(가상 네트워크)
가상 스위치·라우터
Cinder
블록 스토리지(볼륨)
붙였다 뗐다 하는 디스크
Horizon
웹 대시보드
관리 콘솔
여기에 오브젝트 스토리지 Swift, 오케스트레이션 Heat 등이 더 있지만, 위 6개가 “인스턴스 하나 띄우기”의 핵심입니다.
2. 인스턴스 하나 띄울 때 무슨 일이 벌어지나
컴포넌트가 어떻게 맞물리는지는 “VM 하나 생성” 흐름을 따라가면 단번에 이해됩니다.
1) 사용자 → Keystone 에 로그인 → 토큰 발급 (이후 모든 요청에 사용)
2) Nova 에 "인스턴스 생성" 요청
3) Nova → Glance 에서 OS 이미지 가져옴
4) Nova → Neutron 에 네트워크/포트 요청 (IP 할당)
5) (선택) Nova → Cinder 에서 볼륨 붙임
6) Nova 스케줄러가 적당한 compute 노드 선택 → VM 부팅
7) Horizon 대시보드에서 상태 확인
즉 Keystone(인증)으로 문을 열고 → Nova(컴퓨트)가 지휘하면서 → Glance(이미지)·Neutron(네트워크)·Cinder(볼륨)를 불러다 조립하는 구조입니다. 이 흐름 하나만 머리에 넣으면 나머지가 술술 풀립니다.
컴퓨트 노드: Nova-compute·Neutron 에이전트 — 실제 인스턴스가 여기서 돎
스토리지: Cinder 백엔드(LVM/Ceph 등)
그래서 컨트롤러는 CPU·메모리를, 컴퓨트는 인스턴스용 자원을 더 챙겨줘야 합니다. 제 랩에서 컴퓨트 노드에 RAM을 더 준 이유가 이것입니다.
4. 공부 순서 추천
Keystone부터: 인증이 안 되면 아무것도 안 됩니다. 토큰·프로젝트·롤 개념 먼저.
Glance → Nova: 이미지 올리고 인스턴스 하나 띄워보기(성취감 큼).
Neutron: 가장 어렵습니다. 네트워크가 되면 절반은 끝난 것.
Cinder: 볼륨 붙이기까지 하면 기본은 완성.
5. 정리
OpenStack은 이름이 많아 겁나 보이지만, “인증(Keystone) → 컴퓨트(Nova)가 이미지·네트워크·볼륨을 조립”이라는 큰 그림 하나면 충분히 잡힙니다. 각 컴포넌트를 따로 외우지 말고, 인스턴스 생성 흐름 속에서 이해하세요. 홈랩 랩에서 직접 인스턴스를 한 번 띄워보면 이 모든 게 손에 익습니다.
클라우드 엔지니어링을 제대로 공부하려면 결국 OpenStack을 손으로 만져봐야 합니다. 그런데 클라우드를 배우자고 클라우드에 돈을 쓰긴 아깝죠. 그래서 저는 Proxmox 홈랩 안에 OpenStack 멀티노드 랩을 꾸며 두고, 공부할 때만 켭니다. 실제 제 랩 구성과 프라이빗 클라우드 학습 환경을 만드는 법을 공개합니다.
1. 왜 집에서 OpenStack인가
프라이빗 클라우드의 실체를 이해하려면 컨트롤러·컴퓨트·네트워크·스토리지가 어떻게 맞물리는지 직접 봐야 합니다.
퍼블릭 클라우드는 “결과”만 보여주지만, OpenStack은 그 아래 구조를 다 열어 줍니다.
자격증·실무(프라이빗 클라우드 운영) 준비에 이만한 실습 환경이 없습니다.
2. 내 랩의 실제 토폴로지
저는 Proxmox 위에 노드 역할을 나눈 멀티노드 구성과, 간단히 굴리는 올인원 학습용을 함께 둡니다.
노드(VM)
역할
vCPU / RAM
deploy
배포·오케스트레이션
1 / 2GB
control
API·스케줄러·DB·메시지큐
4 / 2GB
compute01~03
실제 인스턴스(VM) 구동
각 1 / 4GB
all-in-one(study)
단일 노드 전체 스택
6 / 16GB
멀티노드는 “진짜 구조”를 배우는 데 좋고, 올인원은 “빠르게 기능만” 볼 때 좋습니다. 둘 다 갖춰두면 학습 목적에 맞게 골라 쓸 수 있습니다.
3. 핵심 전제 — 중첩 가상화(Nested Virtualization)
OpenStack의 컴퓨트 노드는 그 안에서 또 VM(인스턴스)을 돌립니다. 즉 “VM 안의 VM”이라, Proxmox 호스트에서 중첩 가상화가 켜져 있어야 합니다.
# Proxmox 호스트에서 중첩 가상화 확인 (Intel)
cat /sys/module/kvm_intel/parameters/nested # Y 여야 함
# 컴퓨트 노드 VM의 CPU 타입을 host로 (가상화 기능 노출)
qm set 105 --cpu host
이게 빠지면 인스턴스가 아예 안 뜨거나 QEMU 소프트웨어 에뮬레이션으로 기어갑니다. compute 노드엔 반드시 --cpu host를 주세요.
4. 자원 현실 — OpenStack은 무겁다
솔직히 말하면 OpenStack은 홈랩 기준으로 무겁습니다. 올인원만 해도 16GB를 잡아먹고, 멀티노드는 노드 5개가 동시에 떠야 합니다. 그래서 제 원칙은 —
평소엔 꺼둡니다. 학습할 때만 부팅하고, 끝나면 종료해 RAM을 회수합니다.
멀티노드와 올인원을 동시에 켜지 않습니다.
미니 PC 한 대의 RAM 예산 안에서 굴리려면 “쓸 때만 켠다”가 필수입니다.
홈랩에서 상시 운영이 아니라 학습용 랩으로 접근하는 게 현실적입니다.
5. 배포 방식 고르기
방식
특징
추천
DevStack
스크립트로 올인원, 개발·기능 확인용
빠른 입문
Kolla-Ansible
컨테이너 기반 멀티노드, 운영에 가까움
제대로 배우기
수동 설치
컴포넌트 하나씩, 가장 깊이 이해
자격증·심화
입문은 DevStack 올인원으로 “돌아가는 걸” 먼저 보고, 구조를 이해했으면 Kolla-Ansible로 멀티노드에 도전하는 흐름을 권합니다.
6. 정리
OpenStack은 무겁지만, 프라이빗 클라우드의 내부를 이해하는 데 이만한 교재가 없습니다. Proxmox의 중첩 가상화 위에 노드를 나눠 올리고, 필요할 때만 켜는 학습 랩으로 운영하면 미니 PC 한 대로도 충분히 공부할 수 있습니다. 다음 글에서는 OpenStack과 Proxmox 중 무엇을 선택해야 하는지, 그리고 핵심 컴포넌트를 하나씩 뜯어보겠습니다.
안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제 홈랩에서 1년 넘게 운영해온 MicroStack(마이크로스택)에 대한 솔직한 회고를 해볼까 합니다. 인프라 엔지니어라면 누구나 한 번쯤 나만의 클라우드를 꿈꾸지 않나요? 저도 그랬습니다. AWS, Azure, GCP 같은 퍼블릭 클라우드도 좋지만, 직접 바닥부터 쌓아 올리는 프라이빗 클라우드의 매력은 또 다르거든요. 특히 OpenStack(오픈스택)은 예전부터 계속 만져보고 싶었던 기술이었는데, 제 홈랩 환경에서는 너무 무겁고 복잡해서 엄두를 못 내고 있었죠.
그러다 "가볍게 OpenStack을 경험할 수 있다"는 말에 홀려 MicroStack을 만나게 됐습니다. 처음에는 "이게 진짜 OpenStack이라고?" 싶을 정도로 간편한 설치에 놀랐어요. 작은 서버 한 대로 온프레미스 클라우드를 꾸리고 싶었던 저에게는 정말 솔깃한 제안이었거든요. 제 홈랩에서 다양한 서비스를 올리고 내리면서 자유롭게 테스트하고 싶었고, Public Cloud 비용 걱정 없이 마구 실험해보고 싶다는 욕구가 컸습니다. 과연 1년 동안 MicroStack은 저의 이런 기대를 얼마나 충족시켜줬을까요? 삽질 경험과 함께 솔직한 후기를 공유해볼게요.
MicroStack은 단일 서버 위에서 LXD 컨테이너 기술을 활용해 OpenStack 핵심 구성 요소들을 경량으로 실행하는 아키텍처를 가집니다.
2. MicroStack이란 무엇인가요?
MicroStack은 Ubuntu를 개발하는 Canonical(캐노니컬)에서 만든 OpenStack 배포판 중 하나입니다. 기존 OpenStack은 수십 대의 서버와 복잡한 설정이 필요한 거대한 프로젝트인데, MicroStack은 이런 복잡성을 확 줄여서 단일 서버에서도 OpenStack의 핵심 기능들을 사용할 수 있게 해주는 경량 솔루션이에요. 쉽게 말해, "홈랩이나 소규모 환경을 위한 미니 OpenStack"이라고 생각하시면 편합니다.
LXD 기반: 컨테이너 기술인 LXD(Linux Container Daemon)를 활용해서 OpenStack의 다양한 서비스들(Nova, Neutron, Glance, Keystone 등)을 컨테이너 형태로 실행합니다. 덕분에 자원 효율성이 좋고, 격리된 환경에서 안정적으로 운영할 수 있어요.
Snap 패키징: Ubuntu의 Snap(스냅) 패키지 형태로 제공되어서 설치와 관리가 굉장히 간편합니다. snap install 한 줄이면 끝이에요. 업데이트도 자동이라 관리 부담이 적습니다.
단일 노드 지향: 기본적으로 단일 서버에서 모든 OpenStack 서비스가 돌아가는 구조를 지향합니다. 고가용성(HA, High Availability)이나 대규모 확장이 목표가 아니라, 빠르고 쉽게 OpenStack을 시작해보는 데 초점이 맞춰져 있어요.
이런 특징 덕분에 저처럼 "OpenStack은 너무 어려울 것 같고… 그래도 한 번쯤 경험해보고 싶다" 하는 분들에게는 아주 좋은 진입점이라고 생각했습니다.
3. 설치 및 초기 구성: 이렇게 쉬워도 되나?
MicroStack의 가장 큰 장점 중 하나는 바로 설치 간편성입니다. 정말 너무 쉬워서 처음엔 놀랐어요. Ubuntu 서버만 있다면 몇 가지 명령어만으로 바로 OpenStack 환경을 구축할 수 있습니다.
3.1. 설치 명령어
# MicroStack 설치
sudo snap install microstack --classic
# 초기화 (All-in-one 모드 선택, 네트워크 설정 등)
# 이 과정에서 OpenStack 서비스들이 LXD 컨테이너로 배포됩니다.
sudo microstack init --auto --control --compute --network --config
# OpenStack CLI 환경 설정 (OpenStack Client를 통해 컨트롤)
source /snap/microstack/common/etc/microstack.rc
# OpenStack 서비스 상태 확인
sudo microstack status
microstack init 명령어를 실행하면 몇 가지 질문이 나오는데, 기본적으로 All-in-one 모드로 진행하면 됩니다. 네트워크 구성이나 인증 방식 등은 나중에 다시 설정할 수 있으니 부담 없이 진행해도 괜찮아요. 이 과정에서 LXD 컨테이너들이 생성되고 그 안에 Nova(컴퓨트), Neutron(네트워킹), Glance(이미지), Keystone(인증) 같은 OpenStack 핵심 서비스들이 배포됩니다. 몇 분 기다리면 OpenStack 환경이 뚝딱 만들어지는 걸 보면서 정말 감탄했어요 🎉.
3.2. 네트워크 설정, 그리고 삽질 시작
MicroStack 설치는 쉬웠지만, 진짜 "내 것"으로 만들려면 네트워크 설정이 중요하죠. 특히 외부에서 생성된 VM(Virtual Machine)에 접근하려면 Floating IP(플로팅 IP)를 할당해야 하는데, 이를 위한 네트워크 구성을 제대로 해줘야 합니다. 저는 처음에는 내부 네트워크만 만들고 외부 연결이 안 돼서 한참을 헤맸습니다 😅.
# 외부 네트워크 생성 (내부망과 연결할 라우터 역할을 합니다)
# --external은 이 네트워크가 외부와 연결될 수 있음을 나타냅니다.
openstack network create --external --provider-physical-network extnet --provider-network-type flat ext_net
# 서브넷 생성 (외부망 IP 대역과 일치하게 설정)
# --no-dhcp 옵션을 사용해 DHCP 서버가 IP를 자동으로 할당하지 않도록 합니다 (외부망과 충돌 방지)
# --gateway는 외부망 게이트웨이 IP를 입력합니다.
openstack subnet create --network ext_net \
--subnet-range 192.168.0.0/24 \
--no-dhcp \
--gateway 192.168.0.1 \
ext_subnet
# 라우터 생성
openstack router create router1
# 라우터에 외부 네트워크 연결
openstack router set router1 --external-gateway ext_net
# 내부 네트워크 생성 (VM들이 사용할 사설 네트워크)
openstack network create int_net
# 내부 서브넷 생성
openstack subnet create --network int_net --subnet-range 10.0.0.0/24 int_subnet
# 라우터에 내부 네트워크 인터페이스 추가
openstack router add subnet router1 int_subnet
이런 식으로 네트워크를 구성해주고 나서 VM을 생성할 때 int_net에 연결하고, 필요할 경우 ext_net의 IP 대역에서 Floating IP를 할당해주면 외부에서 VM에 접근할 수 있게 됩니다. 이 부분을 이해하는 데 좀 시간이 걸렸네요. OpenStack 네트워크 개념인 Provider Network, Tenant Network, Router, Floating IP 등을 잘 알아야 해요.
OpenStack Horizon 대시보드를 통해 생성된 가상머신과 네트워크 구성을 한눈에 볼 수 있습니다.
4. 1년 운영 경험: 장점, 단점 그리고 한계
1년 동안 MicroStack을 운영하면서 느낀 장점과 단점을 솔직하게 정리해봤습니다.
4.1. 장점: 쉬운 접근성과 자원 효율성 ✅
빠른 배포 및 관리 용이성: snap과 microstack CLI 덕분에 설치, 업그레이드, 관리가 정말 편했습니다. "OpenStack은 어렵다"는 고정관념을 깨기에 충분했죠.
자원 효율성: LXD 컨테이너 기반이라 일반 가상머신보다 훨씬 가볍게 OpenStack 서비스를 운영할 수 있었습니다. 제 홈랩의 서버 자원이 제한적이라 이 점이 가장 만족스러웠어요.
OpenStack 학습 도구로 최적: 실제 OpenStack 환경에서 CLI 명령어를 직접 쳐보고, Horizon(호라이즌, 웹 대시보드)을 만져보면서 OpenStack의 핵심 개념(Nova, Neutron, Glance, Keystone 등)을 빠르게 익힐 수 있었습니다. 덕분에 회사에서 OpenStack 관련 프로젝트를 할 때 훨씬 더 빠르게 적응할 수 있었어요.
4.2. 단점 및 한계점: 삽질의 연속 ⚠️
하지만 장점만 있었던 건 아닙니다. "미니 OpenStack"이라는 태생적 한계와 함께 몇몇 삽질을 피할 수 없었습니다.
단일 노드 아키텍처의 한계: MicroStack은 기본적으로 단일 서버에 모든 서비스가 올라가는 All-in-one 구조입니다. 이는 곧 고가용성(HA)을 전혀 보장할 수 없다는 의미예요. 서버가 한 번 죽으면 모든 VM과 OpenStack 서비스가 멈춥니다. 홈랩이야 괜찮지만, 실제 운영 환경에서는 절대 사용할 수 없는 구조죠.
문제 발생 시 디버깅의 어려움: LXD 컨테이너 안에 OpenStack 서비스들이 돌아가다 보니, 문제가 생겼을 때 로그를 찾거나 디버깅하는 과정이 생각보다 복잡했습니다. 일반적인 OpenStack 설치라면 `systemctl`로 서비스를 제어하고 로그를 바로 확인할 수 있지만, MicroStack은 LXD 컨테이너 내부로 들어가서 각 서비스의 로그를 찾아야 했어요. 예를 들어 Nova 서비스에 문제가 생기면 다음과 같이 접근해야 합니다.
# MicroStack의 LXD 컨테이너 목록 확인
sudo lxc list
# nova 컨테이너 쉘 접근
sudo lxc exec microstack-nova -- bash
# 컨테이너 내부에서 nova 서비스 로그 확인 (예시)
# 경로와 파일명은 OpenStack 버전에 따라 다를 수 있습니다.
tail -f /var/log/nova/nova-conductor.log
이런 과정이 익숙지 않은 초보자에게는 진입 장벽이 될 수 있습니다.
복잡한 네트워크 구성의 제약: 위에서 보여드린 기본적인 네트워크 구성은 가능하지만, OpenStack의 고급 네트워킹 기능(예: SD-WAN 통합, 복잡한 로드밸런싱 등)을 활용하기에는 제약이 많았습니다. 특히 물리 네트워크 인터페이스를 여러 개 활용하거나 VLAN(Virtual LAN)을 섬세하게 제어하는 부분은 쉽지 않았어요.
OpenStack 버전 관리 및 호환성: Snap 패키지 덕분에 업데이트는 편하지만, 특정 OpenStack 버전(예: Wallaby, Xena)을 선택하거나 고정하기는 어려웠습니다. 항상 최신 안정화 버전으로 유지되는데, 이는 호환성 문제가 발생할 수도 있다는 의미입니다. 제가 겪었던 문제 중 하나는 특정 이미지 포맷이 지원되지 않거나, CLI와 Horizon의 기능 차이가 발생하는 경우였습니다.
커뮤니티 지원 부족: 일반적인 OpenStack 커뮤니티에 비해 MicroStack만의 정보는 상대적으로 적습니다. 문제가 생겼을 때 구글링이나 스택오버플로우에서 해답을 찾기 어려울 때가 많았어요. 결국 OpenStack 자체의 지식을 바탕으로 직접 해결해야 하는 경우가 많았습니다.
5. MicroStack vs. 다른 OpenStack 배포판: 선택의 고민
MicroStack이 편리하긴 하지만, "진짜" OpenStack을 경험하거나 운영하려는 분들에게는 다른 선택지도 있습니다. 제가 고민했던 몇 가지 옵션과 MicroStack을 비교해봤어요.
특징
MicroStack (Snap + LXD)
DevStack (스크립트 설치)
Packstack (Ansible 기반)
RDO/OpenStack-Ansible (프로덕션 배포)
주요 목적
빠른 학습, 홈랩, 소규모 테스트
개발, 테스트 환경 구축
소규모 프로덕션, 테스트
엔터프라이즈 프로덕션 환경
설치 난이도
매우 쉬움 (snap install)
쉬움 (git clone && ./stack.sh)
보통 (Ansible 지식 필요)
어려움 (복잡한 설정, HA 구성)
자원 요구량
낮음 (LXD 컨테이너)
보통 (VM 또는 베어메탈)
보통~높음
높음 (다중 노드 필수)
고가용성 (HA)
지원 안 함 (단일 노드)
지원 안 함
제한적 지원
완벽 지원
관리 용이성
매우 좋음 (Snap 업데이트)
낮음 (수동 스크립트)
좋음 (Ansible 관리)
높음 (자동화 도구)
확장성
없음
없음
제한적
매우 좋음
추천 사용자
OpenStack 입문자, 홈랩 사용자
OpenStack 개발자, 기능 테스트
소규모 운영팀, POC
대규모 클라우드 운영팀
MicroStack은 간편함이 가장 큰 장점이지만, 프로덕션 환경에 필요한 기능과 안정성에는 한계가 명확합니다.
6. 누구에게 MicroStack이 적합할까? 나의 결론 💡
1년 동안 MicroStack을 직접 운영해본 결과, 저는 다음과 같은 분들에게 MicroStack을 추천하고 싶습니다.
OpenStack 초보자 및 학습자: "OpenStack이 뭔지 한 번 경험해보고 싶다" 하는 분들에게는 이만한 진입점이 없습니다. 복잡한 설치 과정 없이 핵심 기능을 빠르게 만져볼 수 있어요. CLI 명령어와 Horizon 대시보드 사용법을 익히는 데 아주 유용합니다.
홈랩 환경에서 가벼운 프라이빗 클라우드를 원하는 분: 저처럼 개인 서버 한 대로 가상 환경을 구축하고, 다양한 OS 이미지를 올려보고 싶을 때 좋습니다. 퍼블릭 클라우드 비용이 부담스러울 때 대안이 될 수 있죠.
가벼운 PoC(개념 증명) 또는 테스트 환경이 필요한 개발자: 특정 OpenStack API를 활용하는 애플리케이션을 개발하거나, 간단한 테스트 환경을 빠르게 구축해야 할 때 유용합니다. 복잡한 프로덕션 환경을 그대로 구현할 필요가 없을 때 말이죠.
하지만 실제 프로덕션 환경에 OpenStack을 도입하려는 분이라면 MicroStack은 부적합합니다. 고가용성, 확장성, 안정성 등 엔터프라이즈 환경에서 필요한 요소들을 MicroStack은 제공하지 않거든요. 이런 경우에는 DevStack이나 Packstack으로 개념을 잡고, 더 나아가 RDO나 OpenStack-Ansible 같은 프로덕션용 배포판을 고려해야 합니다.
7. 마무리: 1년의 경험을 통해 배운 점, 그리고 다음 스텝
MicroStack 1년 운영은 저에게 많은 것을 알려줬습니다. OpenStack의 핵심 개념을 직접 손으로 익히고, 프라이빗 클라우드 운영의 재미와 동시에 한계를 명확히 깨닫게 해줬어요. 특히 "간편함"과 "안정성/확장성"은 상충되는 가치라는 것을 다시 한번 실감했습니다. 작은 홈랩에서 시작했지만, 덕분에 회사에서 더 큰 규모의 클라우드 인프라를 이해하고 설계하는 데 큰 도움이 됐습니다.
솔직히 삽질도 많이 했지만, 그 과정에서 얻은 지식과 경험은 무엇과도 바꿀 수 없는 소중한 자산이 되었습니다. OpenStack이라는 거대한 프로젝트에 대한 막연한 두려움을 깼다는 것만으로도 충분히 만족스러웠네요. 앞으로는 MicroK8s(마이크로케이츠)처럼 경량 Kubernetes(쿠버네티스) 솔루션도 홈랩에 도입해서, MicroStack과 연동하는 하이브리드 클라우드 환경을 구축해보는 것도 재미있을 것 같다는 생각이 듭니다. 홈랩은 언제나 새로운 기술을 실험하고 배우는 저만의 놀이터거든요!
혹시 여러분도 OpenStack에 관심이 있으시다면, MicroStack으로 가볍게 시작해보는 건 어떠세요? 분명 좋은 경험이 될 겁니다. 궁금한 점이 있다면 언제든 댓글로 남겨주세요. 제가 겪었던 삽질 경험을 바탕으로 최대한 도와드리겠습니다! 💪
13년차 인프라 엔지니어가 홈랩 서버 앞에서 MicroStack 대시보드를 보며 만족스럽게 웃고 있습니다.