[OpenStack] Kolla-Ansible vs Native Install: 배포 방식 비교 분석

목차

• Kolla-Ansible OpenStack 배포가 왜 주목받는지
• OpenStack 설치 비교: 어떤 환경에 무엇이 맞을까
• Ansible OpenStack 구성 관점에서 보는 핵심 차이
• 1. 구성 관리 방식
• 2. 네트워크 설계 난이도
• 3. 운영 표준화
• 실전 구현: Kolla-Ansible로 OpenStack 배포 기본 흐름
• 1. 기본 패키지 준비
• 2. 인벤토리 작성 예시
• 3. globals.yml 예시
• 4. 배포 실행
• 5. OpenStack 클라이언트 환경 적용
• 반대로 Native Install은 언제 유리할까
• ⚠️ 주의사항과 트러블슈팅: 제가 실제로 막혔던 포인트
• 1. 시간 동기화(NTP, Network Time Protocol) 문제
• 2. 네트워크 인터페이스 이름 불일치
• 3. 컨테이너는 떠 있는데 서비스가 비정상
• 4. Native Install의 설정 드리프트(Configuration Drift, 설정 불일치)
• 검증과 결과 확인: 배포 후 무엇을 보면 되나
• 정리: 어떤 선택이 더 현실적인가
• 자주 묻는 질문
• Q1. 처음 배우는 입장에서는 어떤 방식이 더 나을까요?
• Q2. 홈랩에서는 어떤 쪽이 더 적합한가요?
• Q3. Ansible OpenStack 구성은 운영팀에도 유리한가요?
• Q4. OpenStack 설치 비교에서 가장 먼저 봐야 할 기준은 뭔가요?

[OpenStack] Kolla-Ansible vs Native Install 배포 비교

Kolla-Ansible OpenStack 배포를 처음 고민하시는 분들은 거의 비슷한 지점에서 막히시더라고요. 저도 처음엔 '그냥 패키지 설치해서 올리면 되는 거 아닌가?' 싶었는데, 실제로 해보니 배포 방식에 따라 운영 난이도와 장애 대응 속도가 꽤 많이 달랐습니다. 특히 홈랩과 사내 테스트베드에서 OpenStack 설치 비교를 여러 번 해보니까, 처음 설계할 때의 선택이 나중에 진짜 크게 돌아오더라고요. 이번 글에서는 Kolla-Ansible과 Native Install(네이티브 설치, 직접 패키지와 서비스 단위로 구성) 방식을 경험 기준으로 차분히 비교해보겠습니다.

혹시 지금 이런 상황이신가요? 빠르게 PoC(개념 검증, Proof of Concept)를 띄워야 하는데 운영 표준도 챙겨야 하고, 나중에 업데이트나 재배포도 염두에 두고 계신 분들 말입니다. 여기서 중요한 포인트는 단순히 '설치가 되느냐'가 아니라, 어떤 방식이 내 팀의 운영 역량과 더 잘 맞느냐입니다.

컨테이너 기반 Kolla-Ansible과 패키지 기반 Native Install의 구조 차이를 한눈에 보여주는 비교 다이어그램입니다.

Kolla-Ansible OpenStack 배포가 왜 주목받는지

쉽게 말해 Kolla-Ansible은 OpenStack 서비스를 컨테이너(Container, 애플리케이션 실행 단위)로 배포하고, Ansible(앤서블, 에이전트 없이 원격 설정을 자동화하는 도구)로 전체 구성을 밀어 넣는 방식입니다. 반면 Native Install은 각 노드에 필요한 패키지를 직접 설치하고, 서비스 설정 파일을 손으로 맞추거나 배포 자동화 스크립트를 따로 관리하는 흐름에 가깝습니다.

제가 직접 해보니 두 방식은 철학 자체가 다르더라고요. Kolla-Ansible은 표준화와 재현성에 강합니다. 반대로 Native Install은 세밀한 제어와 내부 이해에 강하죠. 처음엔 이게 뭔가 싶었는데, 몇 번 재설치를 반복하다 보니 왜 운영팀마다 선호 방식이 갈리는지 바로 이해됐습니다.

• Kolla-Ansible: 컨테이너 기반, 역할 분리 명확, 재배포와 확장이 상대적으로 편함
• Native Install: 서비스별 설정을 세밀하게 만질 수 있음, 학습에는 좋지만 운영 표준화가 어렵기 쉬움
• 공통점: 결국 Neutron(뉴트론, 네트워크 서비스), Nova(노바, 컴퓨트 서비스), Keystone(키스톤, 인증 서비스) 같은 핵심 컴포넌트를 이해해야 안정적으로 굴러감

OpenStack 설치 비교: 어떤 환경에 무엇이 맞을까

이제 본론으로 들어가 보겠습니다. OpenStack 설치 비교를 할 때는 설치 편의성만 보면 안 됩니다. 운영 중 변경 작업, 장애 복구, 로그 추적, 업그레이드 전략까지 같이 봐야 하거든요. 저도 예전엔 설치만 되면 끝이라고 생각했었는데, 그 뒤에 남는 유지보수 비용이 더 크더라고요. 삽질 좀 했습니다 ㅎㅎ

비교 항목	Kolla-Ansible	Native Install
배포 방식	컨테이너 이미지와 Ansible 플레이북 기반	패키지 설치와 서비스별 수동 설정 중심
초기 진입 장벽	변수 구조와 네트워크 이해가 필요	설치 흐름은 단순해 보이지만 전체 의존성 파악이 어려움
재현성	높음	운영자 숙련도에 따라 차이 큼
문제 분석	컨테이너 로그와 Ansible 결과를 함께 봐야 함	서비스 단위 로그 확인은 직관적이나 변경 이력 관리가 어려움
업데이트/재배포	자동화에 유리	절차 문서화가 부족하면 리스크 큼
추천 환경	반복 배포, 표준화, 다노드 테스트베드	학습용, 디버깅 중심, 서비스 구조 파악 목적

제 경험상 팀 단위 운영이라면 Kolla-Ansible 쪽이 훨씬 덜 힘들었습니다. 반면 OpenStack 내부 구조를 깊게 공부하려면 Native Install도 한 번은 꼭 해볼 만합니다. 왜냐하면 서비스가 어떤 순서로 붙고, 어디서 설정 충돌이 나는지 몸으로 익히게 되거든요.

Ansible OpenStack 구성 관점에서 보는 핵심 차이

1. 구성 관리 방식

Kolla-Ansible은 보통 전역 설정과 서비스별 오버라이드(override, 기본 설정 덮어쓰기)를 분리해서 관리합니다. 이게 처음엔 조금 낯설어요. 하지만 실제로 써보니까 역할(Role)과 변수(Variable)가 정리돼 있어서, 나중에 다시 볼 때 덜 헷갈리더라고요.

2. 네트워크 설계 난이도

OpenStack은 네트워크에서 많이 넘어집니다. 관리망, 터널망, 외부망을 어떻게 나눌지에 따라 Neutron 구성이 완전히 달라지니까요. Native Install은 서비스 설정 파일을 직접 만지는 만큼 자유도는 높지만, 실수 한 번 하면 어디서부터 틀어졌는지 찾는 데 시간이 오래 걸렸습니다.

3. 운영 표준화

운영 문서가 중요한 조직이라면 OpenStack 배포 자동화 측면에서 Kolla-Ansible이 확실히 유리합니다. 인벤토리(inventory, 관리 대상 호스트 목록)와 변수 파일만 정리되면 재현성이 좋거든요. 이건 새 장비 들어왔을 때 정말 체감됩니다.

컨트롤 노드, 컴퓨트 노드, 네트워크 노드 사이에서 Ansible과 컨테이너 서비스가 어떻게 연결되는지 보여주는 구성도입니다.

실전 구현: Kolla-Ansible로 OpenStack 배포 기본 흐름

이제 실전 쪽 이야기를 해보겠습니다. 여기서는 Kolla-Ansible OpenStack 배포의 전형적인 흐름을 예시로 보겠습니다. 배포판이나 릴리스에 따라 세부 패키지 이름은 조금 달라질 수 있으니, 실제 적용 전에는 운영 중인 환경 기준으로 문서를 꼭 맞춰보셔야 합니다. 저는 이런 식으로 접근하면 시행착오가 많이 줄더라고요.

1. 배포용 제어 노드(Control Node)를 준비합니다.
2. Ansible과 Kolla-Ansible을 설치합니다.
3. 인벤토리와 전역 설정 파일을 작성합니다.
4. 네트워크 인터페이스와 VIP(Virtual IP, 가상 IP)를 정의합니다.
5. 사전 점검(prechecks)을 실행합니다.
6. 배포 후 초기화와 검증을 진행합니다.

1. 기본 패키지 준비

python3 -m venv /opt/kolla-venv
source /opt/kolla-venv/bin/activate
pip install -U pip
pip install 'ansible>=6,<9' kolla-ansible
mkdir -p /etc/kolla

여기서 중요한 포인트! Python 가상환경(virtual environment, 격리된 파이썬 실행 환경)을 써두면 나중에 의존성 꼬임이 줄어듭니다. 별거 아닌 것 같아도 이거 진짜 편하더라고요.

2. 인벤토리 작성 예시

all:
  hosts:
    controller01:
      ansible_host: 192.168.10.11
    compute01:
      ansible_host: 192.168.10.21
  children:
    control:
      hosts:
        controller01:
    network:
      hosts:
        controller01:
    compute:
      hosts:
        compute01:
    monitoring:
      hosts:
        controller01:
    storage:
      hosts:
        controller01:

홈랩에서는 올인원 또는 2노드 구성으로 시작하는 경우가 많습니다. 저도 처음엔 욕심내서 역할을 너무 쪼갔다가 오히려 디버깅 포인트만 늘어났었네요. 처음에는 단순하게 가는 게 좋습니다.

3. globals.yml 예시

kolla_base_distro: "ubuntu"
kolla_install_type: "source"
openstack_release: "2023.2"
kolla_internal_vip_address: "192.168.10.100"
network_interface: "eth0"
neutron_external_interface: "eth1"
enable_haproxy: "yes"
enable_cinder: "yes"
enable_horizon: "yes"

버전이나 배포판 조합은 실제 지원 매트릭스를 확인해서 맞추셔야 합니다. 제가 예전에 여기 대충 맞췄다가 컨테이너는 떠 있는데 서비스 등록이 꼬여서 한참 봤습니다. 드디어 됐다 싶으면 다른 데서 막히고, 그런 순간이 꼭 옵니다.

4. 배포 실행

kolla-ansible -i ./multinode bootstrap-servers
kolla-ansible -i ./multinode prechecks
kolla-ansible -i ./multinode deploy
kolla-ansible -i ./multinode post-deploy

이 순서대로 가면 됩니다. 특히 prechecks는 꼭 보셔야 해요. DNS, 시간 동기화, 인터페이스 정의 같은 기본 조건이 여기서 많이 걸립니다.

5. OpenStack 클라이언트 환경 적용

source /etc/kolla/admin-openrc.sh
openstack service list
openstack network agent list
openstack hypervisor list

여기까지 오면 1차 확인은 끝입니다. 서비스 카탈로그(Service Catalog, API 엔드포인트 목록)와 하이퍼바이저(Hypervisor, 가상화 호스트) 인식 상태를 먼저 보는 습관을 들이면 좋습니다.

Kolla-Ansible 배포 과정에서 사전 점검과 실제 배포가 진행되는 흐름을 홈랩 분위기로 표현한 이미지입니다.

반대로 Native Install은 언제 유리할까

그렇다고 Native Install이 무조건 불리한 건 아닙니다. 저도 실제로 써보니까 서비스 구조를 이해하는 데는 정말 도움이 컸습니다. 예를 들어 Keystone 설정이 어디서 인증 토큰 흐름에 영향을 주는지, Neutron ML2 플러그인(ML2 Plugin, 네트워크 드라이버 프레임워크)과 브리지 설정이 어떻게 맞물리는지 직접 보게 되거든요.

특히 이런 경우엔 Native Install도 충분히 가치 있습니다.

• 단일 노드 학습 환경을 빠르게 만들고 싶을 때
• 컨테이너 추상화보다 서비스 파일과 로그를 직접 보고 싶을 때
• 특정 컴포넌트의 동작을 깊게 디버깅해야 할 때
• 자동화보다 구조 이해가 우선일 때

다만 운영 관점에서는 사람이 바뀌거나 시간이 지나면 설정이 점점 꼬이기 시작합니다. 정말 많이 봤거든요. 문서가 조금만 부실해도 '이 설정 누가 왜 넣었지?'가 반복되더라고요.

⚠️ 주의사항과 트러블슈팅: 제가 실제로 막혔던 포인트

1. 시간 동기화(NTP, Network Time Protocol) 문제

OpenStack은 인증 토큰과 서비스 통신에서 시간 차이에 민감합니다. Kolla-Ansible이든 Native Install이든 노드 간 시간이 어긋나면 묘한 인증 실패가 납니다. 겉으로는 네트워크 문제처럼 보이는데, 알고 보면 시계 문제인 경우가 있더라고요.

2. 네트워크 인터페이스 이름 불일치

이건 홈랩에서 특히 자주 나옵니다. 예전 문서 보고 eth0, eth1으로 적어놨는데 실제 장비는 ens18, ens19인 경우요. 별거 아닌 오타 같은데 외부 네트워크 바인딩이 안 되고 Floating IP(플로팅 IP, 외부 접근용 가상 IP)도 꼬입니다.

3. 컨테이너는 떠 있는데 서비스가 비정상

Kolla-Ansible에서 흔히 겪는 착시입니다. docker ps나 podman ps 기준으로는 떠 있어도, 내부 서비스가 정상 등록되지 않았을 수 있습니다. 그래서 저는 항상 컨테이너 상태만 보지 않고 OpenStack API 응답까지 같이 확인합니다.

4. Native Install의 설정 드리프트(Configuration Drift, 설정 불일치)

처음엔 한 대에서 잘 되는데, 두 번째 노드부터 미묘하게 설정이 다르기 시작합니다. 결국 장애가 나면 원인 추적이 어려워져요. 여기서 중요한 포인트는 자동화되지 않은 반복 작업은 결국 누락을 만든다는 점입니다.

• ⚠️ 사전 점검 체크리스트를 문서화하세요
• ⚠️ 네트워크 맵과 인터페이스명을 먼저 확정하세요
• ⚠️ 배포 직후 서비스 목록, 에이전트 목록, 하이퍼바이저 목록을 반드시 확인하세요
• 💡 장애 분석 시에는 인프라 로그와 OpenStack API 결과를 같이 보세요

검증과 결과 확인: 배포 후 무엇을 보면 되나

Kolla-Ansible OpenStack 배포가 끝났다고 바로 안심하면 안 됩니다. 실제 검증은 이제부터거든요. 저는 보통 아래 순서로 확인합니다.

1. Keystone 인증 정상 여부 확인
2. Nova 컴퓨트 서비스 등록 확인
3. Neutron 에이전트 상태 확인
4. Horizon 대시보드 접속 확인
5. 테스트 네트워크와 인스턴스 생성 확인

source /etc/kolla/admin-openrc.sh
openstack token issue
openstack compute service list
openstack network agent list
openstack image list
openstack server list

실제로 써보니까 이 단계에서 가장 중요한 건 '서비스가 보이느냐'보다 '실제 워크로드가 도는가'였습니다. 테스트 인스턴스 하나 띄워보고, 네트워크 붙이고, 콘솔 접속까지 해보면 훨씬 확실합니다. 🎉

Horizon 대시보드와 CLI 결과를 통해 배포 성공 여부를 교차 검증하는 장면입니다.

정리: 어떤 선택이 더 현실적인가

결론부터 말씀드리면, 반복 가능한 운영 환경이 목표라면 Kolla-Ansible 쪽이 더 현실적입니다. 특히 팀 단위로 관리하거나 테스트베드를 여러 번 재현해야 한다면 OpenStack 배포 자동화의 장점이 확실히 드러납니다. 반면 Native Install은 구조 학습과 세밀한 디버깅에 강합니다. 저도 처음엔 Native Install로 내부를 익히고, 나중엔 Kolla-Ansible 쪽으로 운영 방식을 옮겨가는 흐름이 가장 자연스러웠습니다.

혹시 지금 둘 중 하나를 선택해야 하는 상황이라면 이렇게 보시면 됩니다.

• 빠른 표준화와 재배포가 필요하다면 Kolla-Ansible
• OpenStack 내부 구조 학습이 우선이라면 Native Install
• 장기 운영까지 본다면 자동화와 문서화가 쉬운 쪽을 선택

다음 글에서는 Kolla-Ansible 환경에서 네트워크 분리와 외부망 연결, 특히 Neutron 브리지 구성을 조금 더 깊게 다뤄볼 예정입니다. 이전 글에서 다뤘던 리눅스 브리지와 VLAN 설계 내용을 같이 보시면 훨씬 이해가 빠르실 거예요.

두 배포 방식의 선택 기준과 운영 포인트를 빠르게 복습할 수 있도록 정리한 요약 인포그래픽입니다.

자주 묻는 질문

Q1. 처음 배우는 입장에서는 어떤 방식이 더 나을까요?

OpenStack 구조를 제대로 익히고 싶다면 Native Install을 한 번 경험해보는 게 도움이 됩니다. 다만 실제 운영까지 바로 생각하신다면 Kolla-Ansible이 더 덜 고생스럽습니다.

Q2. 홈랩에서는 어떤 쪽이 더 적합한가요?

반복 실험이 많고 초기화 후 다시 띄우는 일이 잦다면 Kolla-Ansible이 편합니다. 반대로 서비스별 설정을 직접 뜯어보고 싶은 학습형 홈랩이라면 Native Install도 괜찮습니다.

Q3. Ansible OpenStack 구성은 운영팀에도 유리한가요?

네, 인벤토리와 변수 파일 기준으로 변경 이력을 관리하기 쉬워서 협업에 유리합니다. 특히 사람 손을 덜 타게 만드는 점이 큽니다.

Q4. OpenStack 설치 비교에서 가장 먼저 봐야 할 기준은 뭔가요?

설치 성공 여부보다 재현성, 운영 문서화, 장애 대응 흐름을 먼저 보시는 게 좋습니다. 결국 오래 남는 건 운영 부담이거든요.

📚 함께 읽으면 좋은 글

• OpenStack Heat 기반 인프라 자동화: 비용 효율성 심층 분석
• OpenStack 멀티노드 클러스터 1년 운영 회고
• OpenStack Neutron 네트워크 장애 진단 및 해결 5단계