가상머신 기반의 하이퍼바이저와 컨테이그대 기반의 도커 개념과 두 기술 간의 차이점

Docker는 가상화 방법이 아닙니다. 컨테이너 기반의 가상화 또는 운영 차원의 가상화를 실제로 구현한 다른 툴에 의존하게 되어 있습니다. 그래서 Docker는 처음에는 LXC 드라이버를 사용했고, 지금은 runc라고 부르는 libcontainer로 옮겨졌습니다. Docker는 주로 애플리케이션 컨테이너 내부의 애플리케이션 배포 자동화에 중점을 둡니다. 애플리케이션컨테이너는단일서비스를패키지하고실행하도록설계된반면시스템컨테이너는통상가상머신과마찬가지로여러프로세스를실행하도록설계되었습니다. 그래서 Docker는 컨테이너 시스템의 컨테이너 관리 혹은 어플리케이션 배포 툴로서의 목적을 가지고 있다고 생각하면 되겠습니다. 다른 가상화와의 차이를 알아보기 위해 가상화와 그 유형을 봄으로써 이들의 차이를 이해하는 것이 더 용이할 것입니다.Virtualization 가상화 그것이 생성된 형태로 (무엇을 품습니까?) 논리적으로 메인프레임을 분할하여 여러 개의 애플리케이션을 동시에 실행할 수 있는 방법으로 설계되었습니다. 하지만 대기업과 오픈소스 커뮤니티가 어떤 권한을 갖는 인스트럭션(명령)에 대한 조작방법을 가질 수 있고, 단일 x86 기반의 시스템상의 다중 운영 체제에서 동시에 실행되면서 이 시나리오가 크게 바뀌게 되었습니다. Hypervisor 하이퍼바이저 하이퍼바이저는 게스트 가상 컴퓨터가 동작하는 가상 환경의 발생에 관여한다. 게스트 시스템을 감독하고, 필요에 따라 리소스가 게스트에게 할당될 수 있도록 한다. 하이퍼바이저는 실제 시스템과 가상 시스템 사이에 위치해 가상시스템에 가상화 서비스를 제공한다. 이를 실현하기 위해 가상 컴퓨터에서의 게스트 운영 체제 작업을 차단하고, 호스트 컴퓨터의 운영 체제에서의 작업을 에뮬레이트한다.클라우드를 중앙으로 한 가상화 기술의 급속한 발전은 Intel VT 및 AMD-V와 같은 범용 프로세서에 하드웨어 지원 통합, 젠(Xen), VMware Player, KVM 등과 같은 하이퍼바이저를 사용하여 1의 물리적 서버에 여러 가상 서버를 발생할 수 있도록 함으로써 가상화 사용을 더욱 촉진시켰습니다. 가상화 타입의 가상화 방법은 하드웨어를 게스트 운영 체제로 모방하는 방법과 게스트 운영 환경을 에뮬레이트 하는 방법에 따라 분류할 수 있습니다. 주로 향후와 같은 3가지 타입의 가상화가 있습니다.:

Emulation 전체의 가상화 가칭은 전 가상화라고도 불리는 에뮬레이션은 소프트웨어에서 가상 컴퓨터 OS 커널 전체를 실행할 것입니다. 이 타입에 사용된 하이퍼 바이저는 타입 2의 하이퍼 바이저로 알려져 있습니다. 게스트 OS 커널 코드를 소프트웨어 설치로 해석해 주는 호스트 OS 상단에 설치합니다. 이러한 해석은 소프트웨어상에서 전면적으로 이루어지며 하드웨어는 필요하지 않습니다. 에뮬레이션은 에뮬레이션 되는 환경을 지원하는 어떠한 커스터마이즈되지 않은 OS도 실행할 수 있도록 해줍니다. 이러한 유형의 단점은 다른 유형의 가상화와 비교하여 성능적인 저하를 가져올 수 있는 추가 시스템 리소스 오버헤드가 있다는 점입니다.

>

VMware Player, Virtual Box, ZEMU, Bochs, Parallels 등이 이 범주에 대한 예제라고 이 스토리를 할 수 있습니다.Paravirtualization 반가상화 타입1 하이퍼바이저라고도 하는 반가상화는 하드웨어도 “베어 메가면(bare-metal)”에서 직접 실행되며 가상화 서비스가 실행 중인 가상 컴퓨터에 직접 제공됩니다. OS, 가상화된 하드웨어 및 실제 하드웨어가 협업하여 최적의 성능을 얻을 수 있도록 지원합니다. 이러한 하이퍼바이저는 일반적으로 크기가 작고, 추가 리소스는 필요하지 않습니다.

>

Xen, KVM 등이 이 범주에 관한 예제다.Container-based Virtualization 컨테이너 기반의 가상화 운영체제 수준 가상화라고도 하는 컨테이너 기반의 가상화는 단일 운영체제 커널 내에서 다중 분할 실행을(multiple isolated executions) 가능하게 합니다. 최고의 성능과 밀도를 자랑하며 동적 자원 관리 기능을 재공합니다. 저런 타입의 가상화가 재제공되는 분할된 가상 실행 환경을 컨테이너라고 하며 추적 프로세스 그룹으로 볼 수 있습니다.

>

컨테이너 개념은 Linux 커널 버전 2.6.24에 추가된 네임입니다. 스페이스 기능으로 할 수 있다. 컨테이너는 ID를 모든 프로세스에 추가하고 모든 시스템 호출에 대해 새로운 접근통제 검사를 추가한다. 이전-전역입니다.스페이스의 분리된 인스턴스를 발생시키는 clone() 시스템 호출 함수에 접근한다. 하이데스 공간은 다양하게 사용할 수 있지만, 가장 일반적인 사용법은 컨테이너 외부 개체에 대한 가시성이나 접근 권한이 없는 분리 컨테이너를 만드는 것입니다. 컨테이너 안에서 구동되는 과정은 비록 다른 이름입니다.공간에 위치한 프로세스와 내부적으로 커널을 공유하고 있는데 다른 오브젝트의 종류와 마찬가지로 평범한 리눅스 시스템으로 구동되고 있는 것처럼 보입니다. 예를 들어, 네 입니다.공간을 사용할 때 컨테이너 내 루트 사용자는 추가 보안을 추가함으로써 컨테이너 외에서의 루트 취급이 되지 않습니다. 컨테이너 기반의 가상화를 가능케 한 이후 주요 구성요소인 Linux 제어 그룹(cgroup)의 하위 시스템은 프로세스를 그룹화하고 총자원의 소비를 관리하는 데 사용됩니다. 일반적으로 컨테이너의 메모리나 CPU 사용을 제한하는 데 사용됩니다. 컨테이너화된 Linux 시스템에는 첫 번째 커널만 있고 커널에는 컨테이너에 대한 완전한 가시성이 있기 때문에 자원할당이나 스케줄링은 한 단계만 있습니다. LXC, LXD, systemd-nspawn, lmctfy, Warden, Linux-VServer, OpenVY, Docker 등 다양한 관리 도구를 Linux 컨테이너에서 사용할 수 있습니다.컨테이너와 가상 머신의 가상 머신과 달리 컨테이너는 운영체제 커널을 가동할 필요가 없기 때문에 컨테이너를 1초 이내에 만들 수 있습니다. 이 기능을 통해 컨테이너 기반의 가상화는 다른 가상화 접근법보다 독특하고 희망적인 방향으로 할 수 있습니다. 컨테이너 기반 가상화는 호스트 시스템에 오버헤드를 약간 거의 첨가하지 않았기 때문에 컨테이너 기반 가상화는 약간 네이티브와 동일한 성능을 가집니다.컨테이너 기반 가상화의 경우 다른 가상화와 달리 추가적인 소프트웨어는 필요하지 않습니다. 호스트 시스템의 모든 컨테이너는 추가적인 리소스가 필요 없는 호스트 시스템의 스케줄을 공유한다. 컨테이너 상태(Docker, 또한 LXC 화상)는 가상 시스템 화상과 비교하면 사이즈가 작기 때문에 컨테이너 화상을 배포하기 쉽게 만들 수 있습니다. 컨테이너 자원관리는 cgroup을 통해 이루어집니다. Cgroup은 컨테이너가 할당된 것보다 더 많은 자원을 소비하는 것을 허용하지 않습니다. 그러나 현재 호스트 컴퓨터의 모든 리소스는 가상 컴퓨터로 볼 수 있지만 사용할 수 없습니다. 이것은 컨테이너와 호스트 컴퓨터에서 톱 또한 htop을 동시에 실행함으로써 볼 수 있습니다. 결과는 모든 환경에서 유사하게 출력됩니다. 기본적으로 컨테이너인 Docker는 다른 VM이 하드웨어 가상화를 지원하는 것과는 조금 달라, 어플리케이션이 OS의 완전한 인스턴스를 가지고 있다고 의견되는 OS의 가상화를 지원한다. 어떤 OS에서도 부팅이 가능한 물리적인 기계처럼 느껴진다는 것입니다. Docker에서 실행 중인 컨테이너는 호스트 OS 커널을 공유하지만, VM에서는 독자적인 OS 파일을 공유한다. 애플리케이션을 개발하는 환경(OS)은 “테스트” 또, “프로덕션”과 같은 여러가지 서비스 환경에 응용 프로그램을 배포할 때에 같다. 예를 들어 포트4000에서 실행되는 웹 서버를 개발하는 경우 테스트 환경에 배포하면 해당 포트가 이미 다른 프로그램에서 사용되고 있기 때문에 동작을 중지합니다. 컨테이너에는 레이어가 있습니다. OS에 대한 모든 변경사항은 처음 이상의 레이어에 저장되며 그 레이어는 이미지의 일부가 되므로 이미지가 있는 장소마다 종속성이 존재합니다. 이하에 나타내는 예에서는, 호스트 시스템에는 3개의 VM가 있습니다. VM 어플리케이션으로 분리를 재공하기 위해 모든 OS 메모리 내 인스턴스와 같이 OS 파일, 라이브러리 및 어플리케이션 코드 자체 복사본이 있습니다. ​

>

아래 그림은 컨테이너로 구성할 때 동일한 시계인리오를 나타냅니다. 여기서 컨테이너는 커널 및 라이브러리를 포함한 호스트 OS를 공유할 뿐이므로, 운영체제를 가동하고 과인 라이브러리를 로드하여 과인의 해당 파일에 대한 개인 메모리 비용을 지불할 필요가 없습니다. 그들이 차지하는 유일한 증분 공간은 애플리케이션이 컨테이너에서 실행되는 데 필요한 모든 메모리와 디스크 공간입니다. 어플리케이션 환경이 전용 OS처럼 느껴지지만 어플리케이션은 전용 호스트에 배치되어 있는 것처럼 전개됩니다. 컨테이너화된 어플리케이션은 몇 초만에 시작되며, 어플리케이션보다 더 많은 인스턴스가 VM인 경우보다 시스템에 더 적합할 것입니다.

>

애플리케이션을 실행하기 위해 스택을 공급하는 세 가지 설정이 있습니다.(이것은 컨테이너가 무엇인지 인식하고 다른 솔루션보다 강하게 해줍니다.) 1) Traditional Servers (bare metal) 2) Virtual machines (VMs) Containers 1) Traditional server 스택은 운영체제와 아이플케이션을 구동하는 물리적 서버로 구성됩니다.

2) The VM stack의 운용체제를 실행하는 물리적 서버와 가상 컴퓨터, 공유 자원 및 네트워킹 인터페이스를 관리하는 하이퍼바이저로 구성됩니다. 각 VM은 게스트 OS, 어플리케이션도 어플리케이션 집합을 실행합니다.

3) 컨테이너 설정, 다른 스택과의 주된 차이는 컨테이너 기반의 가상화가 호스트 OS의 커널을 사용하여 분리된 여러 게스트 인스턴스를 호스팅한다는 점이다. 이런 게스트 인스턴스는 컨테이너라고 합니다. 호스트는 물리적 서버도 VM이 될 수 있습니다.

컨테이너 희의 설정에 대해서 전 버전과 비교하면 컨테이너 희화가 가장 빠른 자원 효율이 높아 가장 안전한 설정이라고 결론을 내릴 수 있습니다. 컨테이너히는 어플리케이션을 실행할 분리된 인스턴스입니다. Docker는 레이어는 몇 초 안에 구동되는 기본 저장 드라이버(오버레이드 드라이버)를 사용하는 런타임 메모리를 확보하고, copy-on-write는 컨테이너 희실행에 힘을 주도록 컨테이너 희가 커밋되는 그 위에 발발시키는 방법으로 스핀업시킵니다.1분 이내에 모든 것을 가상환경으로 로드할 수 있는 VM의 경우가 될 것입니다. 고란 경량 인스턴스는 재빌드, 이동 및 교환이 가능합니다. 우리가 제품과 개발 환경을 미러링하게 되어 CI/CD 프로세스에 큰 도움이 됩니다.” 이러한 장점들이 컨테이너히가 다른 방식과 대비되어 경쟁력을 가질 수 있는 이유입니다.VM과는 달리 Docker는 하드웨어의 최적의 자원 공유에 관한 것이 아니라 패키징 애플리케이션을 위한 ‘시스템’을 공급합니다(Microservices 집합으로서 바람직하지만 필수는 아님). rpm, debian패키지, maven, npm & git 등의 개발자지향 툴과 Puppet, VMWare, Xen 등의 Ops툴 사이에 있는 뭔가 틈이 있지 않을까 생각합니다.​​​