https://stackoverflow.com/questions/16047306/how-is-docker-different-from-a-virtual-machine
Docker는 가상화 방법이 아닙니다.
컨테이너 기반 가상화 또는 운영 체제 수준 가상화를 실제로 구현한 다른 도구들에 의존하도록 되어 있습니다. 따라서, Docker는 처음에는 LXC 드라이버를 사용하고 이젠 runc라고 부르는 libcontainer로 옮겨졌습니다.
Docker는 주로 응용 프로그램 컨테이너 내부의 응용 프로그램 배포 자동화에 중점을 둡니다.
응용 프로그램 컨테이너는 단일 서비스를 패키지하고 실행하도록 설계된 반면 시스템 컨테이너는 여느 가상 머신들과 같이 여러 프로세스를 실행하도록 설계되었습니다.
따라서 Docker는 컨테이너 시스템의 컨테이너 관리 또는 응용 프로그램 배포 도구로서의 목적을 가지고 있다고 생각하면 됩니다.
다른 가상화 들과 차이 점을 알아보기 위해 가상화와 그 유형을 살펴 봄으로써 이들의 차이점을 이해하는 것이 더 쉬울 것입니다.
Virtualization 가상화
그것의 잉태 된 형태로(무언가를 품는다?), 논리적으로 메인 프레임을 분할하여 여러 응용 프로그램을 동시에 실행할 수 있는 방법으로 설계되었습니다.
그러나 기업들과 오픈소스 커뮤니티들이 어떤 식으로든 권한을 가진 인스트럭션(명령)들에 대한 조작 방법을 가질 수 있게 되었고 단일 x86기반 시스템 상의 다중 운영체제에서 동시에 실행 되게 됨으로써 이 시나리오가 크게 바뀌게 되었습니다.
Hypervisor 하이퍼바이저
하이퍼 바이저는 게스트 가상 컴퓨터가 작동하는 가상 환경 생성에 관여합니다. 게스트 시스템을 감독하고 필요에 따라 리소스가 게스트에게 할당되도록 합니다.
하이퍼바이저는 실제 시스템과 가상 시스템 사이에 위치하여 가상 시스템에 가상화 서비스를 제공합니다.
이를 실현하기 위해 가상 컴퓨터에서 게스트 운영 체제 작업을 차단하고 호스트 컴퓨터의 운영 체제에서 작업을 에뮬레이트합니다.
클라우드를 중심으로 한 가상화 기술의 급속한 발전은 Intel VT 및 AMD-V와 같은 범용 프로세서에 하드웨어 지원 통합,
젠 (Xen), VMware Player, KVM 등과 같은 하이퍼바이저를 사용하여 하나의 물리적 서버에 여러 개의 가상 서버를 생성 할 수 있게 함으로써 가상화 사용을 더욱 촉진 시켰습니다.
가상화 타입
가상화 방법은 하드웨어를 게스트 운영 체제로 모방하는 방법과 게스트 운영 환경을 에뮬레이트하는 방법에 따라 분류 할 수 있습니다. 주로 다음과 같은 세 가지 유형의 가상화가 있습니다:
Emulation 에뮬레이션
|
Paravirtualization 반가상화
|
Container-based virtualization 컨테이너 기반 가상화
|
Emulation
전체 가상화 혹은 전 가상화라고도 불려지는 에뮬레이션은 소프트웨어에서 가상 컴퓨터 OS 커널 전부를 실행합니다.
이 유형에 사용 된 하이퍼바이저는 유형 2 하이퍼 바이저로 알려져 있습니다.
게스트 OS 커널 코드를 소프트웨어 인스트럭션들로 해석해주도록 하는 호스트 운영 체제 상단에 설치됩니다. 이 해석들은 소프트웨어 상에서 전적으로 이루어지며 하드웨어는 필요치 않습니다.
에뮬레이션은 에뮬레이션 되는 환경을 지원하는 어떤 커스터마이징 되지 않은 운영체제들도 실행이 가능하도록 만들어 줍니다.
이 타입의 단점은 다른 타입의 가상화들과 비교해서 성능적인 저하를 가져 올 수 있는 추가 시스템 리소스 오버헤드가 있다는 것입니다.
VMware Player, VirtualBox, QEMU, Bochs, Parallels 등이 이 범주에 대한 예제라고 말 할 수 있습니다.
Paravirtualization 반가상화
유형 1 하이퍼바이저라고도하는 반 가상화는 하드웨어 또는 "베어 메탈 (bare-metal)"에서 직접 실행되며 가상화 서비스가 실행중인 가상 컴퓨터에 직접 제공됩니다.
운영 체제, 가상화 된 하드웨어 및 실제 하드웨어가 협업하여 최적의 성능을 얻을 수 있도록 도와줍니다. 이러한 하이퍼바이저는 일반적으로 크기가 작고 추가 리소스가 필요하지 않습니다.
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, OpenVZ, Docker 등 여러 관리 도구를 Linux 컨테이너에서 사용할 수 있습니다.
컨테이너들과 가상머신들
가상 머신들과 달리 컨테이너는 운영 체제 커널을 부팅 할 필요가 없으므로 컨테이너를 1 초 내에 만들 수 있습니다.
이 기능을 통해 컨테이너 기반 가상화는 다른 가상화 접근방식보다 독특하며 바람직한 방향으로 만들어 줄 수 있습니다.
컨테이너 기반 가상화는 호스트 시스템에 오버 헤드를 거의 또는 전혀 추가하지 않기 때문에 컨테이너 기반 가상화는 거의 네이티브와 같은 성능을 갖습니다.
컨테이너 기반 가상화의 경우 다른 가상화와 달리 추가 소프트웨어가 필요하지 않습니다. 호스트 시스템의 모든 컨테이너는 추가 자원이 필요하지 않은 호스트 시스템의 스케줄러를 공유합니다.
컨테이너 상태 (Docker 또는 LXC 이미지)는 가상 시스템 이미지와 비교할 때 크기가 작으므로 컨테이너 이미지를 쉽게 배포 할 수 있습니다.
컨테이너의 자원 관리는 cgroup을 통해 수행됩니다. Cgroup은 컨테이너가 할당 된 것보다 많은 리소스를 소비하는 것을 허용하지 않습니다.
그러나 현재 호스트 컴퓨터의 모든 리소스는 가상 컴퓨터에서 볼 수 있지만 사용할 수는 없습니다.
이것은 컨테이너와 호스트 컴퓨터에서 top 또는 htop을 동시에 실행함으로써 볼 수 있습니다. 결과는 모든 환경에서 비슷하게 출력됩니다.
기본적으로 컨테이너 인 Docker는 다른 VM이 하드웨어 가상화를 지원하는 것과는 좀 틀리게 응용 프로그램이 OS의 완전한 인스턴스를 가지고 있다고 생각되는 OS 가상화를 지원합니다.
어떤 OS든지 부팅 할 수 있는 물리적 인 기계 인 것처럼 느껴질 수 있다는 것입니다.
Docker에서 실행중인 컨테이너는 호스트 OS 커널을 공유하지만 VM에서는 자체 OS 파일을 공유합니다.
응용 프로그램을 개발하는 환경 (OS)은 "테스트"또는 "프로덕션"과 같은 다양한 서비스 환경에 응용 프로그램을 배포 할 때 동일합니다.
예를 들어, 포트 4000에서 실행되는 웹 서버를 개발하는 경우 "테스트"환경에 배포하면 해당 포트가 이미 다른 프로그램에서 사용되고 있으므로 작동을 멈춥니다.
컨테이너에는 레이어가 있습니다. OS에 대한 모든 변경 사항은 하나 이상의 레이어에 저장되고 해당 레이어는 이미지의 일부가 되므로 이미지가 있는 곳마다 종속성이 존재하게됩니다.
아래에 표시된 예에서 호스트 시스템에는 세 개의 VM이 있습니다. VM의 응용 프로그램에 분리를 제공하기 위해 OS의 전체 메모리 내 인스턴스와 함께 OS 파일, 라이브러리 및 응용 프로그램 코드의 자체 복사본이 있습니다.
아래 그림은 컨테이너들로 구성할 때, 동일한 시나리오를 보여줍니다. 여기서 컨테이너는 커널 및 라이브러리를 포함한 호스트 운영 체제를 공유만하므로 운영 체제를 부팅하거나 라이브러리를 로드 하거나 해당 파일에 대한 개인 메모리 비용을 지불 할 필요가 없습니다. 그들이 차지하는 유일한 증분 공간은 응용 프로그램이 컨테이너에서 실행되는 데 필요한 모든 메모리와 디스크 공간입니다. 응용 프로그램 환경이 전용 OS처럼 느껴지지만 응용 프로그램은 전용 호스트에 배치하는 것처럼 전개됩니다. 컨테이너 화 된 응용 프로그램은 몇 초 만에 시작되며 응용 프로그램의 더 많은 인스턴스가 VM의 경우보다 시스템에 적합합니다.
애플리케이션을 실행하기 위해 스택을 제공하는 세 가지 설정이 있습니다 (이는 컨테이너가 무엇인지 인식하고 다른 솔루션보다 훨씬 강력하게 만들어 줍니다).
1) Traditional Servers(bare metal)
2) Virtual machines (VMs)
3) Containers
1) Traditional server 스택은 운영체제와 애플리케이션을 구동해주는 물리적인 서버들로 구성됩니다.
장점
· 원시자원의 이용
· 분리
단점
· 배치 시간이 매우느림
· 고 비용
· 자원의 낭비
· 확장의 어려움
· 마이그레이션의 어려움
· 복잡한 환경설정
2) The VM stack 운영 체제를 실행하는 물리적 서버와 가상 컴퓨터, 공유 리소스 및 네트워킹 인터페이스를 관리하는 하이퍼바이저로 구성됩니다. 각 VM은 게스트 운영 체제, 응용 프로그램 또는 응용 프로그램 집합을 실행합니다.
장점
· 자원의 원활한 사용
· 확장의 용이성
· 쉬운 백업과 마이그레이션
· 비용 효율성
· 유연성
단점
· 리소스 할당의 문제
· 특정 벤더에 국한됨
· 복잡한 환경설정
3) 컨테이너 설정, 다른 스택과의 주요 차이점은 컨테이너 기반 가상화가 호스트 OS의 커널을 사용하여 분리 된 여러 게스트 인스턴스를 호스팅하는 것입니다. 이러한 게스트 인스턴스는 컨테이너라고합니다. 호스트는 물리적 서버 또는 VM이 될 수 있습니다.
잇점
· 분리성
· 가벼움
· 리소스 효율성
· 쉬운 마이그레이션
· 보안성
· 적은 오버헤드
· 제품과 개발 환경 미러링
단점
· 같은 아키텍처 공유
· 무거운 리소스 애플리케이션들
· 네트워킹과 보안 이슈들
컨테이너 설정에 대해 이전 버전과 비교한다면, 컨테이너 화가 가장 빠르고 자원 효율이 높으며 가장 안전한 설정이라고 결론을 내릴 수 있습니다. 컨테이너는 응용 프로그램을 실행하는 분리 된 인스턴스 입니다.
Docker는 레이어들은 수 초 내에 구동하는 기본 저장드라이버들(오버레이 드라이버들)을 사용하는 런타임 메모리를 확보하고,
copy-on-write 는 컨테이너 실행에 힘을 실어주도록 컨테이너가 커밋되어지는 그 위에 생성되게 하는 방식으로 스핀업 시킵니다.
1분내로 모든 것을 가상환경으로 로드 할 수 있는 VM의 경우가 될 것입니다.
이런 경량 인스턴스들은 재빌드, 이동, 및 교체가 가능합니다. 우리가 제품과 개발 환경을 미러링하게 되면서 CI / CD 프로세스에 엄청난 도움이 됩니다. 이런 장점들이 컨테이너가 다른 방식과 대비되어 경쟁력을 가질 수 있는 이유 인 것입니다.
VM과는 달리 Docker는 하드웨어의 최적의 리소스 공유에 관한 것은 아니며 패키징 응용 프로그램을 위한 "시스템"을 제공합니다
(Microservices 집합으로서 바람직하지만 필수는 아님).
rpm, debian 패키지, maven, npm + git 등의 개발자 지향 도구와
Puppet, VMWare, Xen과 같은 Ops 도구 사이의 그 어느 틈새에 가 아닐까 생각 합니다.
'이것저것' 카테고리의 다른 글
IIS App Pool과 Oracle Pooling Ado.Net의 관계 (0) | 2023.01.22 |
---|---|
JMeter Loop Count와 JMeter Thread Count (0) | 2023.01.17 |
버추얼박스에 요세미티 설치하기 (0) | 2023.01.08 |
Java Keystore에 Trusted 인증서들을 설치하기 (0) | 2023.01.07 |
OpenSSL로 원격 인증서 체인 검증하기 (0) | 2023.01.05 |