본문

https://gngsn.tistory.com/128

Background

VMware

아주 예전에는 하나의 서버 당 하나의 애플리케이션에서 동작.

동일한 서버에서 여러 개의 애플리케이션을 운영 면에서나 보안면에서나 안전하게 실행시키는 기술이 없었음.

그래서 새로운 애플리케이션이 필요할 때마다 서버를 구매해야했고, 무조건 성능과 규모가 좋은 것을 구매하느라 낭비가 심했음.

그러다가 "가상 머신 VM"이라는 개념이 세상에 나오게 되고, 하나의 운영체제 위의 여러 OS를 실행시켜 낭비를 크게 줄임

하지만, 가상머신도 결함을 갖고 있었는데, 하나의 VM마다 "고유한 OS"가 필요하기 때문에, 각각 CPU, RAM 및 기타 리소스를 소비하며 보다 많은 시간과 자원을 낭비하게 됨.

Container

위의 VM 모델의 단점들로 인해 구글과 같은 대형 회사들은 컨테이너 기술을 사용해왔음.

컨테이너 모델에서 컨테이너는 VM과 유사.
주요 차이점은 컨테이너에 자체적인 "하나의 완전한 OS"가 필요하지 않다는 점.

실제로 컨테이너 모델에서는 단일 호스트의 모든 컨테이너는 호스트의 OS를 공유.
이것은 CPU, RAM 및 스토리지와 같은 막대한 양의 시스템 리소스가 확보된다는 의미.
또한, OS 라이센스 비용을 절감할 수 있고 OS 패치 및 유지보수의 오버헤드를 줄여주며 VM의 문제를 해결할 수 있었음.

결과적으로 VM에서 컨테이너를 사용한 후 시간이나 리소스 및 네트워크를 절감할 수 있게 됨.

초기 Docker Engine

초기 Docker는 현재 모델과는 다르게 Docker Daemon, LXC라는 두 개의 주요 구성을 가지고 있음

Docker Daemon

이때 Docker Daemon은 현재의 Docker Daemon과는 달랐음.

The Docker Daeomn는 "모놀리식 바이너리(모듈화가 되어있지 않음)"

Docker Daemon에 Docker Client, the Docker API, container runtime, image builds 등을 비롯한 많은 코드를 담고 있었음.

LXC

LXC는 "단일 컨트롤 호스트 상"에서 여러 개의 고립된 리눅스 시스템(컨테이너)들을 실행하기 위한 "운영 시스템 레벨 가상화" 방법

daemon에게 linux kernel에 존재하는 컨테이너의 기본 building block에 대한 namespace, cgroups(control groups)와 같은 접근을 제공.

LXC의 문제점

Docker는 LXC에 의존하면 리눅스 배포판/버전마다 LXC 동작이 달라 런타임이 흔들릴 수 있어서, 외부 의존성을 줄이고 "호스트 환경 전반에 일관된 실행"을 확보하려고 go언어로 개발된 "libcontainer"를 독자적으로 개발.

이후 Docker는 0.9부터 기본 실행 드라이브를 libcontainer로 전환