From b06a81ae64ef92f7587365640ce91a29947d9091 Mon Sep 17 00:00:00 2001 From: seongyeonajou Date: Fri, 13 Mar 2026 23:10:00 +0900 Subject: [PATCH] =?UTF-8?q?docs:=205=EC=9E=A5=201=EC=A0=88~5=EC=A0=88=20Gl?= =?UTF-8?q?ance=20=EA=B0=95=EC=9D=98=20=EB=AC=B8=EC=84=9C=20=EC=A0=84?= =?UTF-8?q?=EC=B2=B4=20=EC=9E=91=EC=84=B1=20(=EC=9D=B4=EC=84=B1=EC=97=B0)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- lectures/ch5/ch5_1_lec.qmd | 70 +++++++++++++++++++++ lectures/ch5/ch5_2_lec.qmd | 106 ++++++++++++++++++++++++++++++++ lectures/ch5/ch5_3_lec.qmd | 87 ++++++++++++++++++++++++++ lectures/ch5/ch5_4_lec.qmd | 121 +++++++++++++++++++++++++++++++++++++ lectures/ch5/ch5_5_lec.qmd | 90 +++++++++++++++++++++++++++ 5 files changed, 474 insertions(+) create mode 100644 lectures/ch5/ch5_1_lec.qmd create mode 100644 lectures/ch5/ch5_2_lec.qmd create mode 100644 lectures/ch5/ch5_3_lec.qmd create mode 100644 lectures/ch5/ch5_4_lec.qmd create mode 100644 lectures/ch5/ch5_5_lec.qmd diff --git a/lectures/ch5/ch5_1_lec.qmd b/lectures/ch5/ch5_1_lec.qmd new file mode 100644 index 0000000..9d87a83 --- /dev/null +++ b/lectures/ch5/ch5_1_lec.qmd @@ -0,0 +1,70 @@ +--- +title: "가상 이미지에 대한 이해 (raw, qcow2 등)" +--- + +# OpenStack Glance 서비스 및 가상 이미지 포맷 분석 + +## 1. 개요 +* OpenStack에서 가상 머신(VM)의 근간이 되는 OS 템플릿을 관리하는 Glance 서비스와 가상 이미지 포맷의 특성을 분석합니다. +* 클라우드 환경에서 운영체제 이미지는 단순한 파일이 아닌, 인프라의 성능과 저장 공간 효율성을 결정짓는 핵심 자산입니다. + +## 2. 가상 이미지(Virtual Image)의 정의 및 역할 +가상 이미지는 가상 머신(VM)을 실행하기 위해 필요한 운영체제(OS), 애플리케이션, 그리고 시스템 설정 데이터가 포함된 '디지털 템플릿' 입니다. + +* **기술적 정체**: 물리적 하드디스크의 상태를 하나의 파일로 캡처(Capture)한 바이너리 데이터 덩어리입니다. +* **클라우드에서의 역할**: 매번 OS를 수동으로 설치할 필요 없이, 미리 구성된 이미지를 복제하여 수초 내에 동일한 환경의 인스턴스를 대량으로 배포하는 근간이 됩니다. + +## 3. 가상 이미지 포맷의 종류 및 비교 분석 +클라우드 생태계에는 다양한 하이퍼바이저(Hypervisor)가 존재하며, 각 환경에 최적화된 여러 이미지 포맷이 사용됩니다. + +| 포맷 | 풀 네임 | 주요 특징 및 용도 | +|---|---|---| +| **RAW** | Raw Binary | 가공되지 않은 순수 디스크 데이터. 구조가 단순하여 I/O 성능이 가장 뛰어나지만, 실제 데이터와 무관하게 전체 용량을 점유합니다. | +| **QCOW2** | QEMU Copy-On-Write 2 | OpenStack의 표준 포맷. 쓴 만큼만 용량을 차지하는 'Thin Provisioning'과 '스냅샷' 기능을 지원하여 클라우드 운영 효율이 가장 높습니다. | +| **VMDK** | Virtual Machine Disk | VMware 환경의 표준 규격입니다. 엔터프라이즈 환경에서 널리 쓰이며 오픈스택과의 호환성도 뛰어납니다. | +| **VHD/VHDX** | Virtual Hard Disk | Microsoft Hyper-V 및 Azure에서 주로 사용되는 포맷입니다. | +| **VDI** | VirtualBox Disk Image | Oracle VirtualBox의 네이티브 포맷으로 주로 개인 개발 환경에서 사용됩니다. | +| **ISO** | Optical Disk Image | CD/DVD 등의 광학 미디어를 파일화한 것으로, 주로 OS 설치용 매체로 활용됩니다. | + +## 4. Glance의 이미지 처리 메커니즘 +Glance 서비스가 사용자로부터 이미지를 받아 저장하고 관리하는 상세 과정은 다음과 같습니다. + +### 4.1 이미지 등록 및 업로드 라이프 사이클 +1. **API 접수 (Request)**: 사용자가 이미지 업로드를 요청하면 Glance API가 이를 수신합니다. +2. **메타데이터 기록 (Registry)**: 이미지의 이름, 포맷, 가시성(Visibility) 등의 정보를 Glance DB에 먼저 기록합니다. (상태: queued) +3. **바이너리 스트리밍 (Storage)**: 실제 이미지 본체 데이터를 드라이버를 통해 Backend Store (NAS, Swift, Ceph 등)로 전송합니다. (상태: saving) +4. **무결성 검증 (Checksum)**: 전송이 끝나면 MD5/SHA-256 해시값을 대조하여 데이터가 변조되거나 깨지지 않았는지 확인합니다. +5. **최종 활성화 (Active)**: 검증이 완료되면 이미지를 사용할 수 있는 상태인 active 로 변경합니다. + +### 4.2 이미지 변환 및 배포 최적화 +* **Image Conversion**: 특정 하이퍼바이저가 지원하지 않는 포맷일 경우, Glance는 내부도구(qemu-img)를 사용하여 가상 머신이 읽을 수 있는 포맷으로 변환 과정을 거칩니다. +* **Image Caching**: 자주 호출되는 이미지는 컴퓨팅 노드(Nova)에 캐싱하여 네트워크 트래픽을 줄이고 배포 속도를 가속화합니다. + +## 5. Glance 이미지 관리 논리 구조 +```mermaid +graph TD + User((User)) + API[Glance API] + DB[(Glance DB: Metadata)] + Store{Backend Store} + + User -- "1. Upload Request" --> API + API -- "2. Write Metadata" --> DB + + subgraph "Image Processing" + API -- "3. Stream Binary" --> Store + end + + Store -- "4. Checksum" --> API + API -- "5. Set Status: Active" --> User + + subgraph "Supported Formats" + F1[RAW / QCOW2] + F2[VMDK / VHD] + F3[ISO / VDI] + end + + Store -.-> F1 + Store -.-> F2 + Store -.-> F3 +``` \ No newline at end of file diff --git a/lectures/ch5/ch5_2_lec.qmd b/lectures/ch5/ch5_2_lec.qmd new file mode 100644 index 0000000..e1a9428 --- /dev/null +++ b/lectures/ch5/ch5_2_lec.qmd @@ -0,0 +1,106 @@ +--- +title: "Image Metadata 구조" +--- + +# OpenStack Glance Image Metadata 구조 및 체계 분석 + +## 1. 개요 +클라우드 환경에 이미지를 업로드하면 용량이나 디스크 포맷(QCOW2 등) 같은 '물리적인 기본 정보'는 자동으로 기록됩니다. 하지만 수십, 수백 개의 이미지가 운영되는 실제 환경에서는 이런 기본 정보만으로 인프라를 제대로 통제하기 어렵습니다. 실제(실무) 환경에서는 배치 문제, 보안 통제, 자원 관리와 같은 실무적인 고민들이 발생할 수 있습니다. 이러한 문제를 해결하기 위해, 관리자가 직접 이미지에 세밀한 '꼬리표(태그)'를 달아 목적에 맞게 분류하고 제어하는 기능이 바로 사용자 정의 메타데이터(Custom Metadata)입니다. + +## 2. 사용자 정의 메타데이터 관리 명령어 CRUD +오픈스택 CLI에서는 '추가'와 '수정'이 하나의 명령어(set)로 통합되어 동작하는 것이 특징입니다. + +### 2.1 추가 및 수정 (Add / Update) +* **명령어**: `set` +* **원리**: 입력한 키(Key)가 기존에 없으면 새롭게 추가되고, 이미 존재하는 키라면 입력한 값(Value)으로 수정(덮어쓰기) 됩니다. + +```bash +# 사용법 +openstack image set-property <키>=<값> <이미지ID_또는_이름> + +# 예시 (해당 이미지가 프론트엔드 부서용임을 추가/수정할 때) +openstack image set-property department=frontend_dev ubuntu-24.04-custom +``` + +### 2.2 삭제 (Delete) +* **명령어**: `unset` +* **원리**: 더 이상 필요 없는 사용자 정의 속성을 지정하여 이미지에서 완전히 떼어냅니다. + +```bash +# 사용법 +openstack image unset-property <키> <이미지ID_또는_이름> + +# 예시 (부서 지정 속성을 삭제할 때) +openstack image unset-property department ubuntu-24.04-custom +``` + +### 2.3 적용 결과 확인 (Read / Verify) +* **명령어**: `show` +* **원리**: 메타데이터를 조작한 후에는 반드시 해당 이미지의 전체 정보를 조회하여 properties 항목에 변경 사항이 잘 들어갔는지 확인해야 합니다. + +```bash +# 사용법 (결과창의 properties 필드 확인) +openstack image show ubuntu-24.04-custom +``` + +> **💡 TIP**: OpenStack CLI 환경에서는 메타데이터의 '추가'와 '수정'을 별도의 명령어 구분 없이 `set` 명령어 하나로 처리합니다. 키(Key)의 존재 여부에 따라 자동으로 분기되기 때문에, 작업 후에는 반드시 `show` 명령어로 검증하는 습관이 필요합니다. + +## 3. Metadata 논리 구조도 +아래 다이어그램은 Glance 데이터베이스 내에서 기본 속성과 사용자 정의 속성이 어떻게 구조화되어 관리되는지 보여줍니다. + +```mermaid +graph TD + %% 전체 서비스 구조 + GlanceDB[(Glance Database)] --- ImageObject[Image Object Entity] + + %% 이미지 객체 하위 구조 + ImageObject --> BaseProps[Base Properties
기본 속성 - 필수/고정] + ImageObject --> CustomProps[User-defined Properties
사용자 정의 속성 - 선택/가변] + + %% 기본 속성 세부 항목 + subgraph "System Mandatory Fields" + BaseProps --> B1[UUID / Name] + BaseProps --> B2[Status: active, saving...] + BaseProps --> B3[Disk Format: RAW, QCOW2...] + BaseProps --> B4[Container Format: bare...] + BaseProps --> B5[Min RAM / Min Disk] + end + + %% 사용자 정의 속성 세부 항목 + subgraph "Customizable Metadata Schema" + CustomProps --> C1[OS Distro: Ubuntu, Windows...] + CustomProps --> C2[Architecture: x86_64, ARM64...] + CustomProps --> C3[HW Virtualization: hw_scsi_model...] + CustomProps --> C4[Visibility: Public, Private, Shared] + end + + %% 실제 데이터와 연결 + ImageObject -->|Pointer| BackendStore{Glance Backend Store
Actual Image Binary Data} + + %% 스타일 정의 + style ImageObject fill:#f9f,stroke:#333,stroke-width:2px + style GlanceDB fill:#e1f5fe,stroke:#01579b + style BackendStore fill:#fff3e0,stroke:#e65100 +``` + +## 4. Metadata 아키텍처 및 저장 원리 +Glance의 이미지는 '이미지 바이너리 데이터'와 이를 설명하는 '메타데이터'로 분리되어 관리됩니다. + +* **데이터베이스 관리**: 메타데이터는 빠른 검색과 인덱싱을 위해 Glance 데이터베이스(DB) 내에 구조화된 형태로 저장됩니다. +* **스토어 분리**: 실제 대용량 이미지 파일은 Glance 백엔드 스토어(Backend Store)에 보관되며, 메타데이터는 이 위치를 가리키는 포인터 정보를 포함합니다. +* **검증 프로세스**: 사용자가 VM 생성을 요청할 시, 시스템은 메타데이터를 우선 조회하여 하드웨어 사양(Min RAM 등)의 적합성 여부를 검토합니다. + +## 5. 주요 구성 범주 분석 + +### 5.1 시스템 기본 속성 (Base Properties) +이미지 등록 시 시스템에 의해 필수적으로 요구되거나 생성되는 고유 속성입니다. +* **ID / Name**: 이미지의 고유 식별 번호 및 명칭 +* **Status**: 현재 이미지의 가용 상태 (예: active, queued) +* **Disk Format**: 가상 디스크 저장 방식 (예: RAW, QCOW2) +* **Resource Constraints**: 구동에 필요한 최소 RAM 및 디스크 용량 명시 + +### 5.2 사용자 정의 속성 (Image Properties) +운영 효율성을 위해 관리자가 임의로 부여하는 키-값(Key-Value) 형태의 메타데이터입니다. +* **OS Information**: 운영체제의 배포판 및 버전 정보 +* **Hardware Properties**: 특정 가상 하드웨어 모델(NIC, 디스크 컨트롤러) 지정 +* **Visibility**: 이미지의 공개 및 공유 범위 정의 (Public, Private, Shared) \ No newline at end of file diff --git a/lectures/ch5/ch5_3_lec.qmd b/lectures/ch5/ch5_3_lec.qmd new file mode 100644 index 0000000..7b85190 --- /dev/null +++ b/lectures/ch5/ch5_3_lec.qmd @@ -0,0 +1,87 @@ +--- +title: "Glance Backend Store에 대한 개념" +--- + +# OpenStack Glance Backend Store 개념 및 구조 분석 + +OpenStack Glance의 스토리지 아키텍처를 이해할 때, 가장 먼저 짚고 넘어가야 할 부분은 '실제 저장 공간'과 이를 연결하는 '설정 영역'의 차이를 명확히 구분하는 것입니다. 실무 환경에서는 이 두 가지를 혼용해서 부르기 쉽지만, 시스템 상에서는 엄연히 다른 역할을 수행합니다. + +* **Glance Backend Store (물리/논리적 저장소)**: 가상 머신의 이미지가 실제로 보관되는 '물리적 또는 논리적인 저장 공간 그 자체'를 의미합니다. 로컬 서버의 하드디스크(file), 분산 객체 스토리지(swift), 블록 스토리지(cinder 또는 ceph) 등이 여기에 해당하며, 비유하자면 이미지가 쌓이는 '실제 창고'입니다. +* **[glance_store] (연동 설정 구역)**: Glance 프로그램이 위에서 언급한 창고(Backend Store)들을 찾아가기 위해 사용하는 `glance-api.conf` 파일 내의 설정 섹션입니다. 어떤 드라이버를 로드할지, 저장소의 주소는 어디인지, 인증 계정은 무엇인지를 정의하며, 창고 문을 열기 위한 '내비게이션과 열쇠' 역할을 합니다. + +## 1. Glance Backend Store 구조 +아래 다이어그램은 사용자 요청이 Glance API를 거쳐 실제 물리적 저장소인 백엔드 스토어에 도달하는 논리적 흐름을 나타냅니다. + +```mermaid +graph LR + User[Client / User] -- API Request --> G_API[Glance API] + G_API -- Metadata Query --> G_DB[(Glance DB)] + + subgraph "Glance Backend Stores" + G_API -- "Store Driver (Store Library)" --> Drivers{Storage Drivers} + Drivers -- File System --> Local[Local Disk / NFS] + Drivers -- Object Storage --> Swift[OpenStack Swift / Ceph RGW] + Drivers -- Block Storage --> Cinder[OpenStack Cinder] + Drivers -- Distributed --> Ceph[Ceph RBD] + end + + %% 스타일 정의 + style G_API fill:#f9f,stroke:#333,stroke-width:2px + style G_DB fill:#e1f5fe,stroke:#01579b + style Drivers fill:#fff3e0,stroke:#e65100 +``` + +## 2. 주요 백엔드 스토어 유형 및 특징 +Glance는 인프라 환경의 규모와 요구 성능에 따라 다음과 같은 다양한 스토어 타입을 지원합니다. + +| 스토어 타입 | 기술적 특성 | 활용 사례 | +|---|---|---| +| **File (Filesystem)** | 호스트 서버의 로컬 디스크나 NFS(Network File System)를 이용하는 방식입니다. | 단일 노드 테스트 혹은 소규모 환경 | +| **Swift** | OpenStack의 오브젝트 스토리지 서비스인 Swift와 연동하여 데이터를 분산 저장합니다. | 대규모 클라우드 및 고가용성 보장 필요 시 | +| **Ceph (RBD)** | 분산 스토리지 솔루션인 Ceph를 백엔드로 사용하며, 현재 실무에서 가장 많이 선호되는 방식입니다. | 고성능, 확장성 중심의 엔터프라이즈 인프라 | +| **Cinder** | OpenStack의 블록 스토리지인 Cinder를 이미지 저장소로 활용합니다. | 스토리지 인프라를 Cinder로 통합 운영할 경우 | +| **HTTP** | 외부 웹 서버에 있는 읽기 전용 이미지를 가져오는 방식입니다. | 외부 공개 이미지를 직접 배포할 경우 | + +## 3. 백엔드 스토어의 동작 원리 +사용자가 이미지를 업로드하거나 다운로드할 때 Glance는 다음과 같은 순서로 백엔드 스토어와 상호작용합니다. + +1. **드라이버 호출**: Glance API는 설정 파일(`glance-api.conf`)에 정의된 백엔드 스토어 드라이버를 로드합니다. +2. **데이터 전달**: 사용자가 전송한 이미지 바이너리 데이터를 선택된 드라이버를 통해 백엔드 저장소로 스트리밍합니다. +3. **위치 정보(Location URI) 저장**: 업로드가 완료되면, 이미지가 저장된 물리적 위치 주소를 생성하여 Glance DB의 메타데이터 영역에 기록합니다. + +## 4. glance-api.conf 설정 파일과 백엔드 스토어 연동 +Glance API와 저장소 간의 통신 로직은, 실제 서버의 `/etc/glance/glance-api.conf` 파일 내 `[glance_store]` 섹션 설정을 통해 제어됩니다. 스토리지 설정의 원리를 가장 직관적으로 이해하기 위해, 성격이 완전히 대비되는 두 가지 방식인 File 스토어(로컬)와 Swift 스토어(외부 네트워크)의 설정 방법을 비교해 보겠습니다. + +* **File과 Swift의 차이**: File 방식은 내 서버의 로컬 하드디스크에 이미지를 저장하므로 단순히 '저장할 폴더 경로'만 알려주면 됩니다. 반면 Swift는 네트워크 너머에 있는 독립된 대규모 객체 스토리지이므로, 단순히 주소뿐만 아니라 "내가 누구인지" 증명하는 인증(Authentication) 정보가 필수적으로 추가되어야 한다는 뚜렷한 구조적 차이가 있습니다. + +### 4.1 File 스토어 설정 예시 (로컬 디스크 기반) +가장 기본적인 형태로, 단일 노드 테스트 환경 등에서 주로 사용됩니다. + +```ini +[glance_store] +# 사용 가능한 스토어 드라이버 목록 +stores = file, http +# 이미지를 업로드할 때 사용할 기본 스토어 지정 +default_store = file +# (File 전용) 이미지가 실제로 저장될 로컬 서버의 절대 경로 +filesystem_store_datadir = /var/lib/glance/images/ +``` + +### 4.2 Swift 스토어 설정 예시 (분산 객체 스토리지 연동) +외부 스토리지와 연동해야 하므로, 인증 서버(Keystone)의 주소와 Glance 서비스 계정 정보가 추가로 필요합니다. + +```ini +[glance_store] +stores = swift, http +default_store = swift + +# (Swift 전용) 인증을 처리할 Keystone 서버 주소 +swift_store_auth_address = http://controller:5000/v3/ + +# (Swift 전용) Swift에 접근하기 위한 Glance 서비스 계정 이름 및 비밀번호 +swift_store_user = service:glance +swift_store_key = + +# (Swift 전용) 이미지를 담을 Swift 컨테이너(버킷) 명칭 +swift_store_container = glance +``` \ No newline at end of file diff --git a/lectures/ch5/ch5_4_lec.qmd b/lectures/ch5/ch5_4_lec.qmd new file mode 100644 index 0000000..3787f94 --- /dev/null +++ b/lectures/ch5/ch5_4_lec.qmd @@ -0,0 +1,121 @@ +--- +title: "private / public / shared image 차이" +--- + +# OpenStack Glance 이미지 공개 범위(Visibility) 및 공유 체계 분석 + +## 1. 이미지 공개 범위(Visibility) 분류 및 CLI 설정 +Glance는 이미지의 용도와 보안 수준에 따라 다음과 같이 세 가지 주요 가시성 등급을 제공합니다. +* **Private (개인)**: 이미지를 생성한 프로젝트 내에서만 사용 가능합니다. (기본값) +* **Public (공용)**: 클라우드 내 모든 프로젝트가 사용 가능합니다. (보안상 최고 관리자 권한 필요) +* **Shared (공유)**: 소유자가 지정한 특정 프로젝트와 공유합니다. + +### 1.1 이미지 최초 생성 시 지정 (create) +이미지를 Glance에 최초로 업로드할 때 옵션을 부여하여 가시성을 확정합니다. (미지정 시 기본값은 private으로 들어갑니다.) + +```bash +# 1. 프로젝트 전용(Private)으로 생성할 때 +openstack image create --private --file ubuntu.qcow2 ubuntu-image + +# 2. 클라우드 전체 공개 (Public)로 생성할 때 (최고 관리자 권한 필요) +openstack image create --public --file ubuntu.qcow2 ubuntu-public-image +``` + +## 2. 운영 중인 이미지의 범위 변경 (set) +이미 등록되어 운영 중인 이미지의 공개 범위를 사후에 변경할 때 사용합니다. + +```bash +# 1. 특정 이미지를 소유 프로젝트 전용 (Private)으로 제한할 때 +openstack image set --private + +# 2. 특정 이미지를 타 프로젝트와 공유 (Shared) 할 수 있는 상태로 변경할 때 +openstack image set --shared +``` + +## 3. 상태 전환(Transition) 및 삭제 권한 통제 +이미지의 가시성을 변경하거나 완전히 삭제하는 작업은 클라우드 인프라 전체에 영향을 미칠 수 있습니다. 따라서 오픈스택은 이를 엄격한 권한(RBAC) 기반으로 통제합니다. + +### 3.1 가시성 상태 전환 통제 +* **Private <-> Shared (유연한 전환)**: + * **권한**: 소유자(Owner) + * **사유**: 내 자원을 특정 대상에게만 보여주거나 다시 회수하는 것이므로, 소유자 권한 내에서 자유롭게 통제할 수 있습니다. +* **Private / Shared -> Public (승격)**: + * **권한**: 최고 관리자(Admin) 필수 + * **사유 (보안)**: 일반 사용자가 검증되지 않은 악성 이미지를 마음대로 전체 공개로 올려버리는 것을 막기 위한 보안 통제입니다. +* **Public -> Private (강등)**: + * **권한**: 최고 관리자(Admin) 필수 + * **사유 (가용성)**: Public 이미지는 이미 다른 수많은 프로젝트에서 믿고 가져다 쓰고 있는 공용 자원입니다. 이를 갑자기 Private으로 숨겨버리면 타 프로젝트의 서비스 가용성에 치명적인 장애를 유발할 수 있습니다. + +### 3.2 이미지 삭제 통제 +삭제 명령어(`openstack image delete `)는 단순하지만, 실행 주체에 따라 결과가 완전히 달라집니다. +* **소유자 (Owner)**: 자신이 생성한 Private 및 Shared 이미지만 삭제할 수 있습니다. 공유받은 이미지의 원본이나, 인프라의 Public 이미지는 삭제할 수 없습니다. +* **시스템 관리자 (Admin)**: 스토리지 용량을 갉아먹는 좀비 자원을 회수하거나 악성 이미지를 격리하기 위해, 가시성이나 소유권에 상관없이 인프라 내의 모든 이미지를 강제로 삭제할 수 있는 권한을 가집니다. + +## 4. 타 프로젝트와의 이미지 공유 +OpenStack에서 이미지를 타 프로젝트와 공유하는 과정은 일반적인 클라우드 드라이브의 단방향 통보 방식과 다릅니다. 반드시 '제공자의 할당(Add)'과 '수신자의 수락(Accept)'이라는 양방향 합의 구조를 거치며, 이는 인프라 운영 및 보안 측면에서 두 가지 중요한 목적을 가집니다. + +* **자원 관리**: 수많은 부서가 쏟아내는 이미지들로 인해 내 프로젝트의 대시보드가 어지럽혀지는 것을 막고, 꼭 필요한 '표준 이미지'만 선별하여 구독할 수 있게 합니다. +* **보안 및 스팸 방지**: 악의적인 사용자나 타 부서가 검증되지 않은 대용량 이미지를 내 프로젝트에 무단으로 Spamming하여 스토리지 할당량을 소진시키거나, 보안 위협을 일으키는 것을 원천적으로 차단합니다. + +실제 공유 절차는 제공자와 수신자의 역할로 나뉘어 진행됩니다. + +### 4.1 공유 멤버 추가 (제공자 측면) +원본 이미지의 소유자는 자신이 만든 이미지를 사용할 대상 프로젝트(Target Project)를 지정하여 권한을 부여합니다. + +```bash +# 특정 프로젝트를 이미지 사용 멤버로 추가 +openstack image add project <공유할_Image_ID> <대상_Project_ID> +``` + +### 4.2 대기 상태 (Pending) +제공자가 멤버를 추가하더라도, 대상 프로젝트의 이미지 목록에는 즉시 나타나지 않으며 숨겨진(대기) 상태로 머물게 됩니다. 이는 원치 않는 이미지가 대상 프로젝트의 리스트를 어지럽히는 것을 방지하는 1차 방어선입니다. + +### 4.3 검증 및 수락/거절 (수신자 측면) +공유받은 프로젝트의 관리자는 해당 이미지가 안전하고 실제 업무에 필요한 자원인지 확인한 후, 수락해야만 자신의 이미지 목록에 활성화되어 가상 머신 생성에 활용할 수 있습니다. + +```bash +# 공유받은 이미지를 내 프로젝트에 활성화(수락) +openstack image set --accept <공유받은_Image_ID> + +# (참고) 원치 않거나 의심스러운 이미지일 경우 거절하여 목록에서 영구 배제 +openstack image set --reject <공유받은_Image_ID> +``` + +## 5. 이미지 공개 범위 논리 구조 + +아래 다이어그램은 각 공개 범위 설정에 따라 이미지에 접근할 수 있는 프로젝트의 범위를 보여줍니다. + +```mermaid +graph TD + subgraph "OpenStack Cloud" + AdminProject[Admin Project] + ProjectA[Project A
Owner] + ProjectB[Project B
Member] + ProjectC[Project C
Others] + end + + subgraph "Image Visibility Types" + PublicImage((Public Image)) + PrivateImage((Private Image)) + SharedImage((Shared Image)) + end + + %% Public 연결 + PublicImage --> AdminProject + PublicImage --> ProjectA + PublicImage --> ProjectB + PublicImage --> ProjectC + + %% Private 연결 + PrivateImage === ProjectA + + %% Shared 연결 + SharedImage --- ProjectA + SharedImage --> | Accept Membership | ProjectB + + %% 스타일 정의 + style PublicImage fill:#e1f5fe,stroke:#01579b + style PrivateImage fill:#ffebee,stroke:#c62828 + style SharedImage fill:#f1f8e9,stroke:#33691e + style ProjectA font-weight:bold,stroke-width:2px +``` \ No newline at end of file diff --git a/lectures/ch5/ch5_5_lec.qmd b/lectures/ch5/ch5_5_lec.qmd new file mode 100644 index 0000000..e71f102 --- /dev/null +++ b/lectures/ch5/ch5_5_lec.qmd @@ -0,0 +1,90 @@ +--- +title: "ubuntu server iso이미지를 glance에 올려서 인스턴스를 만드는 방법" +--- + +# OpenStack 클라우드 이미지 배포 및 골든 이미지 제작 가이드 + +## 1. 클라우드 환경의 이미지 운영 +전통적인 PC 가상화 환경(VMware, VirtualBox 등)에서는 빈 가상 머신에 ISO(CD)를 삽입하고 관리자가 콘솔 화면을 보며 수동으로 OS를 설치합니다. 하지만 수십, 수백 대의 서버를 즉각적으로(수초 이내에) 확장해야 하는 클라우드 환경에서는 이러한 수동 설치 방식이 적합하지 않습니다. 또한, OpenStack 자체는 인프라 플랫폼일 뿐 운영체제 이미지를 내장하여 제공하지 않습니다. 따라서 실무 환경에서는 Ubuntu (Canonical), CentOS 등 각 OS 벤더사에서 클라우드 환경에 맞게 사전 구성하여 배포하는 '공식 클라우드 이미지(Cloud Image, 주로 QCOW2 포맷)'를 다운로드하여 사용하거나, 보안 및 사내 표준에 맞춰 완벽하게 세팅을 끝낸 '골든 이미지(Golden Image)'를 직접 제작하여 인스턴스를 자동 배포합니다. + +## 2. 관련 서비스 및 상호작용 +* **Glance (Image Service)**: 단순한 ISO 미디어뿐만 아니라, QCOW2, RAW, VMDK 등 인스턴스 구동에 필요한 다양한 형태의 가상 머신 이미지와 메타데이터를 통합 보관하고 제공합니다. +* **Nova (Compute)**: 사용자의 생성 요청을 받아 Glance로부터 적절한 이미지를 가져오고, 하이퍼바이저를 제어하여 실제 인스턴스(가상 머신)를 프로비저닝하고 구동합니다. +* **Cinder (Block Storage)**: 인스턴스에 영구적으로 연결할 수 있는 데이터 볼륨을 제공합니다. (골든 이미지를 수동으로 제작할 때, OS가 설치될 베이스 볼륨 역할도 수행합니다.) + +```mermaid +graph TD + subgraph "OpenStack Core Services" + G[Glance: 클라우드/골든 이미지 제공] + N[Nova: 인스턴스 프로비저닝 및 제어] + C[Cinder: 영구 블록 스토리지 제공] + end + G -->|"1. 배포용 이미지 전달"| N + N -->|"2. 인스턴스 구동"| I[Instance: Cloud-init 기반 자동 부팅] + C -.->|"3. (선택) 데이터 볼륨 연결"| I + + %% 무채색(Grayscale) 스타일 정의 + style G fill:#e0e0e0,stroke:#333,stroke-width:2px,color:#000 + style N fill:#d0d0d0,stroke:#333,stroke-width:2px,color:#000 + style C fill:#c0c0c0,stroke:#333,stroke-width:2px,color:#000 + style I fill:#f9f9f9,stroke:#333,stroke-width:2px,color:#000 +``` + +## 3. Glance의 역할과 지원 포맷 확장 +Glance는 단순한 ISO 설치 미디어 저장소가 아닙니다. 클라우드 인스턴스 구동에 필요한 다양한 형태의 가상 머신 디스크 이미지를 종합적으로 보관하고 관리하는 핵심 레지스트리입니다. +* **지원 포맷**: qcow2(KVM/QEMU 기본, 가장 널리 사용), raw(비압축 고성능), iso(설치 미디어 및 복구용), vmdk(VMware 호환) 등 + +## 4. 공식 클라우드 이미지 다운로드 및 등록 가이드 +가장 대중적인 Ubuntu 24.04 LTS 버전을 기준으로, 벤더사가 제공하는 클라우드 이미지를 Glance에 등록하는 절차입니다. + +### 4.1 공식 이미지 다운로드 +* Ubuntu 공식 클라우드 이미지 저장소([https://cloud-images.ubuntu.com/)에서](https://cloud-images.ubuntu.com/)에서) `.img` 또는 `.qcow2` 확장자를 가진 최신 클라우드 이미지를 다운로드합니다. (예: `ubuntu-24.04-server-cloudimg-amd64.img`) + +### 4.2 Glance에 이미지 등록 (CLI 방식) +터미널에서 아래 명령어를 통해 다운로드한 QCOW2 이미지를 Glance에 업로드합니다. + +```bash +openstack image create "Ubuntu-24.04-Cloud" \ + --file ./ubuntu-24.04-server-cloudimg-amd64.img \ + --disk-format qcow2 \ + --container-format bare \ + --public +``` + +> **(참고) Horizon 대시보드 등록 방식**: 웹 UI 환경에서는 [프로젝트] -> [Compute] -> [이미지] -> [이미지 생성] 메뉴로 진입하여, 다운로드한 파일을 업로드하고 포맷을 QCOW2로 지정하여 생성할 수 있습니다. + +## 5. 클라우드 네이티브 인스턴스 자동 배포 (Cloud-init) +클라우드 이미지를 사용하면 콘솔(VNC) 화면을 열어 마우스로 클릭할 필요가 없습니다. 인스턴스 생성 시 `cloud-init` 이라는 클라우드 자동화 스크립트를 주입(User-Data)하여 모든 초기 설정을 자동화합니다. +* **자동화 요소**: IP 주소 할당, 호스트 네임(Hostname) 설정, 기본 패스워드 지정, SSH Key-pair 주입, 초기 필수 패키지 설치 등 +* **결과**: 사용자의 개입 없이, 생성 명령 즉시 부팅 및 접속이 가능한 완성된 서버가 제공됩니다. + +## 6. ISO를 활용한 '골든 이미지(Golden Image)' 제작 +클라우드 환경에서 일반적인 인스턴스 생성은 벤더사가 제공하는 공식 QCOW2 이미지를 사용하지만, ISO 파일이 전혀 사용되지 않는 것은 아닙니다. 공식 배포 이미지만으로는 사내 보안 규정(특정 파티션 분리, 커스텀 커널 적용 등)을 충족하기 어려울 때, 사용자가 직접 ISO를 이용해 OS를 설치하고 설정을 마친 원본 이미지를 제작해야 합니다. 이렇게 세팅이 완료된 커스텀 마스터 이미지를 실무에서는 '골든 이미지'라고 부르며, 다음의 과정을 거쳐 제작됩니다. + +1. **ISO 기반 수동 설치**: Glance에 ISO 파일을 업로드한 후, 이를 부팅 소스로 삼아 인스턴스를 생성합니다. 관리자는 VNC 콘솔에 접속하여 파티션 설정 및 OS 설치를 수동으로 진행합니다. +2. **패키지 및 보안 설정**: OS 설치가 완료되면, 운영에 필요한 필수 패키지 설치, 방화벽 설정, 사내 보안 정책 등을 적용합니다. +3. **시스템 초기화**: 생성될 이미지가 다른 인스턴스에 복제될 때 충돌이 발생하지 않도록, 기존 인스턴스에 종속된 고유 정보(MAC 주소, SSH 호스트 키, 로그 파일 등)를 삭제하고 초기화합니다. +4. **스냅샷 생성 및 등록**: 모든 준비가 완료된 인스턴스의 스냅샷을 생성합니다. 이 스냅샷은 새로운 QCOW2 포맷의 이미지로 추출되어 Glance에 등록되며, 이후부터는 ISO 수동 설치 과정을 생략하고 이 골든 이미지를 바탕으로 다수의 인스턴스를 자동 생성하게 됩니다. + +## 7. 전체 인스턴스 생성 시퀀스 흐름도 + +```mermaid +sequenceDiagram + participant Admin as 관리자 (Admin) + participant User as 사용자 (User) + participant Glance as Glance (Image Service) + participant Nova as Nova (Compute Service) + participant CloudInit as Cloud-init (Guest OS) + + Note over Admin, Glance: [사전 준비 단계] + Admin->>Glance: 1. QCOW2 이미지(공식 또는 골든 이미지) 업로드 + + Note over User, CloudInit: [인스턴스 자동 배포 단계] + User->>Nova: 2. 인스턴스 생성 요청 (User-data: 초기 설정 스크립트 전달) + Nova->>Glance: 3. 인스턴스 생성을 위한 지정 이미지 요청 + Glance-->>Nova: 4. 이미지 바이너리 데이터 전달 + Nova->>Nova: 5. 하이퍼바이저에 가상 머신(VM) 생성 및 부팅 실행 + Nova->>CloudInit: 6. 메타데이터 및 User-data 스크립트 주입 + CloudInit->>CloudInit: 7. Guest OS 내부 설정 자동화 (IP, 계정, SSH Key 등) + CloudInit-->>User: 8. 프로비저닝 완료 및 접속 대기 상태 전환 +``` \ No newline at end of file