저번 글에서는 서버 한 대에서 여러 운영체제를 실행할 수 있게 해주는 하이퍼바이저(Hypervisor) 에 대해 설명했습니다.
이번에는 그 다음 흐름인 컨테이너가 어떻게 하이퍼바이저의 한계를 풀어냈는지, 그리고 Docker가 Linux가 아닌 환경에서 어떻게 동작하는지까지 정리해보겠습니다.
하이퍼바이저의 한계
하이퍼바이저는 하나의 물리 서버 위에 여러 가상 서버를 띄울 수 있게 해주는 기술입니다. 서버 자원을 극한까지 활용할 수 있고 관리도 편해진다는 분명한 장점이 있죠.
하지만 치명적인 단점이 있습니다. 바로 너무 무거워서 느리다는 것입니다.
- 하이퍼바이저라는 계층을 한 번 더 거치기 때문에 성능 오버헤드가 발생합니다.
- 각 VM마다 독립적인 Guest OS를 통째로 설치해야 하므로 디스크·메모리 비용이 큽니다.
- VM 부팅 시간 또한 일반 OS 부팅과 다를 바 없이 무겁습니다.
결국 VM 하나를 띄울 때마다 운영체제 전체가 하나씩 추가되는 셈입니다.
전통적인 Linux 컨테이너
이런 단점을 보완하기 위하여 리눅스에서 컨테이너라는 기술을 개발하게 되었습니다. 대표적인 초기 기술이 바로 LXC(Linux Containers) 입니다.
컨테이너는 host os의 커널을 함께 공유합니다. 그리고 host os의 프로세스 위에서 가상의 공간을 독립적으로 확보해 그 안에서 애플리케이션을 실행합니다. 격리는 리눅스 커널의 namespace와 cgroups로 구현되는데 이 부분은 나중에 자세히 다루도록 하겠습니다.
물론 host os와 같은 커널을 공유하기 때문에 같은 os만 사용할 수 있다는 단점이 있긴 있습니다. 하지만 하이퍼바이저와 다르게 OS를 새로 설치하지 않아도 되니, 리소스 효율은 비교가 안 될 정도로 좋습니다.
도커의 등장
LXC가 등장했지만 다루기는 여전히 까다로웠습니다. 그 흐름을 일반 개발자도 손쉽게 쓸 수 있도록 추상화한 것이 바로 Docker 입니다. 이 도커의 등장으로 Linux 커널 기반으로 만들어진 컨테이너를 쉽게 활용할 수 있게 되었습니다. 가장 대표적으로 OS 세팅, 패키지 설치, 환경 구성, 실행 설정 등을 을 전부 직접 해야 했는데 Docker가 이를 자동화해준 것입니다.
Docker의 기본 흐름
Dockerfile → Image → Container
(정의) (빌드) (실행)- Dockerfile: 어떤 환경에서, 어떤 의존성을 가지고, 어떻게 실행될지를 코드로 정의한 파일
- Image: Dockerfile을 기반으로 빌드된 실행 패키지 (언어 런타임, 라이브러리, 애플리케이션 코드, 실행 환경이 한 덩어리로 묶인 것)
- Container: 이미지를 실제로 실행시킨 인스턴스
지금은 흐름만 잡으셔도 됩니다. Dockerfile과 Image의 내부 구조는 다음 글에서 더 자세히 다루겠습니다.
Window와 Mac에서는?
여기서 자연스럽게 의문이 생깁니다.
"Docker는 Linux 커널 기반이라면서요? 그럼 Linux 커널이 없는 Windows나 macOS에서는 도대체 어떻게 동작하나요?"
Windows에서는 보통 WSL2(Windows Subsystem for Linux 2) 를 사용합니다.
즉 Windows 안에서 경량 Linux 환경을 실행하고, 그 위에서 Docker가 동작합니다.
결과적으로 사용자는 Windows를 쓰고 있다고 느끼지만, 컨테이너 자체는 진짜 Linux 커널 위에서 돌아가고 있는 셈입니다.
macOS도 원리는 비슷합니다. macOS 위에 가벼운 Linux VM(LinuxKit)을 띄우고, 그 안에서 Docker 데몬을 실행합니다.
즉, Linux가 아닌 환경에서의 Docker는 결국 "보이지 않는 Linux VM" 을 활용하는 구조입니다. 이 덕분에 어떤 OS를 쓰든 동일한 컨테이너 이미지를 동일하게 실행할 수 있는 것이죠.
다음 글에서는 Dockerfile의 구조와 Image의 레이어 시스템을 좀 더 깊게 파보겠습니다. 긴 글 읽어주셔서 감사합니다!
