가상머신

시스템 가상머신이란?

실제 시스템에서 가상의 시스템을 에뮬레이션하여 실행하는 소프트웨어.

일반적으로 실제 시스템을 “Host”, 가상 시스템을 “Guest” 라고 표현

시스템 가상머신을 사용하는 이유

하나의 하드웨어와 자원을 공유

하나의 하드웨어 위에 여러 OS 등을 실행 가능.

격리성 (독립성)

게스트끼리는 서로 격리되어 있기 때문에 호스트나 다른 게스트에 영향을 주지 않음.(보안에도 매우 유리함)

캡슐화

만들어진 게스트들은 복제되어 다른 호스트나 같은 호스트에서도 여러개로 구동이 가능.

서로 다른 버전과 환경으로 구동되는 두개의 서버가 있다고 했을 때 개발자의 개발 환경을 간편하게 구축 가능하다.

(가상머신이 없다면 별도의 하드웨어 또는 듀얼부팅 등으로 여러 OS를 동시에 설치하고 다른 환경을 만들어서 개발을 해야 한다)

서버의 하드웨어를 변경해도 가상머신 이미지만 복제하면 바로 적용이 가능.

하이퍼바이저

가상화 머신 모니터 (Virtual Machine Monitor),

가상화 머신 매니저(Virtual Machine Manager) 라고도 함. (VMM)

물리적인 하드웨어와 OS(게스트)를 분리하는 기능.

가상화의 종류

하이퍼바이저형 가상화 (TYPE 1)

Host OS 없이 하드웨어 가상화를 전담하는 소프트웨어인 하이퍼바이저를 설치하여 하드웨어와 가상 환경을 제어하는 방식.

전가상화

하드웨어 전체를 가상화.

Guest는 자신이 가상 머신 위에서 돌아가는지 모름.

OS의 제약이 없이 사용이 가능하다.

반가상화

각 Guest들의 OS가 하드웨어가 이해 가능한 명령으로 번역하여 전달.

Guest는 자신이 가상 머신 위에 동작하고 있다는걸 인식 가능함.

OS의 제약이 있다. (대부분의 경우 오픈소스 OS 만 가능, 커널수정 필요함)

TYPE1 가상화

가상화의 종류

호스트형 가상화 (TYPE 2)

Host OS 위에 Guest OS가 구동되는 방식.

쉬운 구축이 가능하지만 Host OS 위에 Guest OS 를 작동시키기 때문에 성능상 오버헤드가 심함.

여기서 말하는 하이퍼바이저는 VM Ware나 Virtual Box 같은 가상화 소프트웨어.

(가상의 하드웨어 에뮬레이팅) 오버헤드 큼

시스템 가상머신의 단점

가상 머신은 물리적 컴퓨터보다 효율성이 떨어지고 실행 속도도 느림

Guest OS들을 복제하게 되면 이미지의 파일의 용량이 매우 큼. (OS 전체를 이미지화 하기 때문)

실행 환경만 격리되면 되는 환경에서는 환경 뿐만 아니라 모든 하드웨어 주변 장치까지 가상화가 되어 효율성이 좋지 못함.

단순히 서로 다른 서버의 환경만 필요할 경우 비효율적.

컨테이너

격리된 컴퓨팅 공간 또는 컴퓨팅 환경을 의미.

커널을 공유하면서 프로세스를 격리된 환경 에서 실행하는 기술.

리눅스에는 대표적으로 LinuX Container라 불리는 LXC가 존재.

윈도우에서도 리눅스와 비슷한 컨테이너 기술이 존재.

구글에서는 2014년에 모든 서비스가 컨테이너로 구동중. 매주 20억개의 컨테이너의 실행.

컨테이너의 장점

빠른 시작과 종료

VM과 다르게 이미 Host OS가 실행중이기 때문에 단순히 격리된 “프로세스”를 실행 하는 수준의 시작과 종료가 가능함. (수초내에 시작이 가능)

컨테이너의 실행은 OS입장에서는 그저 하나의 프로세스 실행과 같음

적은 오버헤드

__ __ 가상화를 위한 하드웨어 에뮬레이션이 없어 오버헤드가 낮음.

(적은거지 없는게 아님)

적은 이미지 용량 (경량화 가능)

커널과 기타 Host OS에 대한 파일이나 코드가 없기 때문에 VM에 비해 적은 용량의 이미지를 가지고 공유가 가능

컨테이너의 단점

커널의 공유

OS 커널을 공유하므로 독립된 커널에서의 실행은 불가능.

Host OS에 종속

Host OS의 커널을 사용하기 때문에 다른 OS의 커널을 사용하는 컨테이너는 구동이 불가능.

VM과 비교하여 상대적으로 보안에 취약

__ __ 커널이 공격당하면 실행중인 모든 컨테이너에 문제가 발생. (VM은 완전 독립)

시스템 컨테이너와 애플리케이션 컨테이너

시스템 컨테이너

다수의 프로세스가 같은 환경을 공유하는 것을 목표.

시작시 init을 실행하여 설정과 각종 데몬의 실행이 가능

애플리케이션 컨테이너

독립적인 환경에서 하나의 프로세스를 실행하는 것을 목표.

nginx를 실행하고 싶다면 nginx만 동작하는 컨테이너 구성이 가능

리눅스 컨테이너 - chroot

chroot 명령어를 이용한 디렉터리 경로의 격리 방법. (1979년 유닉스에서 처음 구현된 기능)

해당 명령어를 이용하여 루트 디렉토리를 설정하면 “chroot jail” 이라는 환경이 생성되고 이 안에서는 밖의 디렉토리의 접근이 불가능해짐.

서버의 정보유출 최소화를 위해 보통 사용되어짐.

리눅스 컨테이너 - cgroups, cnamespaces

리눅스 커널의 cgroups는 CPU, 메모리, 디스크, 네트워크 자원을 할당하여 가상 공간 제공. (사용량 제한 등도 가능함)

커널의 namespaces 는 프로세스 트리, 계정, 파일시스템, IPC 등을 격리하여 호스트와 별개의 공간을 만듬.

chroot와 cgroups와 namespaces 명령어들을 이용하여 초보적인 수준의 가상 컨테이너 환경의 구축이 가능함.

컨테이너 런타임

컨테이너 __ __런타임은 컨테이너를 실행하고 관리하는 도구입니다.

호스트 운영체제가 제공하는 저수준 컨테이너 서비스를 사용하여 컨테이너를 만들거나 없애는 도구.

컨테이너들이 실행되어질 수 있는 발판을 마련해주는 소프트웨어라고 보면 될 것 같다.

LXC (LinuX Container)

시스템 컨테이너 런타임중 하나.

컴퓨터를 통째로 가상화하여 OS를 실행하는 것이 아닌 리눅스 커널 레벨에서 제공하는 일종의 격리(Isolate)된 가상 공간.

이 가상 공간에는 OS가 설치되지 않기 때문에 가상 머신이라 하지 않고, 컨테이너라 부름.

LXC는 cgroups와 namespaces를 이용하여 가상의 공간을 제공.

하지만 LXC는 마치 운영체제처럼 동작하여 실행 환경을 그대로 다른 곳으로 복사하는 것이 쉽지 않음.

사용법이 어려움.

이외의 컨테이너 런타임들

LXD

LXC에서 기능이 강화되고 편리한 인터페이스 제공

CRI-O

__ __ 쿠버네티스를 위한 경량 컨테이너 런타임

Kata 컨테이너

__ __ 오픈스택 재단에서 개발중인 경량 VM 기반의 컨테이너 런타임. (안정성 확보)

컨테이너 오케스트레이션

컨테이너 오케스트레이션은 다수의 컨테이너를 적절하게 분산하고 스케줄링하는 방법과 도구입니다.

쿠버네티스, 아마존ESC, 랜처, 노마드 등이 존재함.

도커(Docker)

2013년에 발표되고 애플리케이션 컨테이너를 지향하는 런타임.

초기의 도커는 리눅스 컨테이너(LXC) 를 기반으로 컨테이너를 생성하고 관리.

현재는 LXC 외에 libcontainer 라는

별도의 실행 드라이버를 만들어

우분투 버전 외에 다양한 리눅스

를 지원.

따라서 맥 OS나 윈도우에서도

사용할 수 있는 가능성이 생김.

도커는 사실상 예전부터 있던 컨테이너 기술을 사용하기 쉽고 간단하게 다루도록 하는 런타임.

도커라는 이름도 컨테이너를 다루는 항만에서 일하는 ‘부두 노동자’를 뜻함.

도커는 LXC에 비해서 매우 쉽게 컨테이너를 생성, 구축, 이미지 전송, 이미지 버전 관리에 있어 뛰어나다.

리눅스와 리눅스 아닌 운영체제에서의 도커의 구조

리눅스가 아닌 운영체제에서는 경량의 VM 이 게스트로 리눅스를 구동하여 그 위에서 도커가 동작하게 된다.

도커 이미지와 컨테이너

도커는 이미지와 컨테이너라는 개념이 존재.

__컨테이너는 도커가 이미지를 실행한 상태를 말함. __

(비유: 이미지->실행파일, 컨테이너-> 프로세스)

이미지는 “베이스 이미지” 라는 이미지가 존재함.

__이 베이스 이미지에는 리눅스 배포판의 유저랜드만 설치된 파일을 뜻함. __

(유저 공간에서 실행되는 실행 파일과 라이브러리를 유저랜드 라고 말함)

제로에서부터 도커 이미지를 만들수도 있지만 보통은 리눅스 배포판을 베이스 이미지로 삼아 커스텀 이미지를 만들게 됨. (우분투, 데비안, 레드헷, 오픈수세, 젠투, 아치, 아마존 등등등… 베이스 이미지 제공)

베이스 이미지로부터 도커 이미지를 생성 했다면 베이스 이미지에서 바뀐 부분만 이미지로 생성하게 되고, 실행할 때는 베이스 이미지에서 바뀐 부분을 합쳐서 실행. (우측 상단 이미지처럼)

도커 이미지는 16진수로 된 ID로 구분하고, 각각의 이미지는 독립적.

우측 하단의 이미지에서 도커 이미지의 의존 관계를 볼 수 있음.

즉 도커 이미지는 이미지를 통째로 생성하는게 아닌 바뀐 부분만 생성하고 부모 이미지를 계속 참조하는 방식으로 동작. (레이어)

Union Mount, Union File System

도커의 이미지들은 읽기 전용 상태이고, 여기서 내용이 바뀌게 되면 원래 이미지를 수정하지 않고, 쓰기 가능한 이미지를 생성하고 내용을 기록하게 됨.

이러한 방식을 Union Mount 라고 하고 이 마운트를 지원하는 파일 시스템을 Union File System 이라고 부름.