1. 개요
실행중인 컴퓨터의 커널에 라이브러리, 실행파일을 격리하고, 이 공간 내에 독립된 프로세스 및 네트워크를 실행시키는 기술과 이를 위한 소프트웨어 구성 일체를 이야기한다. 같은 버전 커널에서 동일한 동작을 보장한다.2. 상세
FreeBSD의 Jails라는 기술에서 시작되었다. 서버를 운영하는 입장에서 각각의 사용자 마다 개별 시스템을 구성해 할당하는 것은 그야말로 자원 낭비다. 동일한 프로세스 여러개를 하나의 시스템에 몰빵해서 실행할 수 있는 유닉스 시스템의 특성을 활용, 사용자마다 동일한 초기환경을 제공하되 사용자 간에 상호 영향을 받지 않도록 개별 사용자의 프로세스가 격리되어 실행할 수 있는 가상의 공간(jail)을 구현하는 것이다.리눅스에서는 이러한 개념을 차용한 기술이 커널 2.6.24부터 적용되었으며, LinuX Containers(LXC)라고 불려왔다. 이 LXC 기술을 이용한 서비스 중 가장 널리 사용되어 사실상 업계 표준이 된 게 바로 Docker다.
윈도우 커널에 의존하는 컨테이너 기술이 구현되긴 했다. 하지만 라이선스 문제[1]가 있고, Windows는 서버 목적보다는 개인 단말 목적의 네이티브 상태가 가장 이상적이기 때문에, 단순히 가능성만 열어두고 그 규모가 커지지는 않았다. Windows에 Windows Subsystem for Linux(WSL)이 탑재된 이후부터 리눅스 커널에 의존하는 컨테이너를 끌어다 쓸 수 있게 되면서 더 외면받고 있는 상황이다. 다만 Microsoft Azure 서버에는 컨테이너 기술이 활용되고 있다.
Mac OS는 FreeBSD의 변형이긴 하나 그 설계정책 상 사용자 수준의 권한을 넘어서는 모든 작업을 금지하기 때문에 Mac OS UI를 지원하는 컨테이너는 없다. 단지 윈도우와 마찬가지로 리눅스 커널에 의존하는 컨테이너를 가져다 쓸 수는 있다.
3. 가상머신과 차이점
가장 근본적인 차이점은 가상화 수준의 차이다.가상머신을 커널 수준까지 가상화하고 라이브러리, 실행파일을 컨테이너로 묶어서 공통된 커널위에서 가상화 하는 방법으로 가상머신과 컨테이너를 구분할 수 있다.
컨테이너는 라이브러리, 실행파일의 독립을 통해 가상 환경을 구현한다. 네트워크, 프로세스는 커널에 연결된 하드웨어에서 실행된다. 다만 하나의 컨테이너는 다른 컨테이너의 네트워크나 프로세스의 상태를 알 수 없고, 다른 컨테이너의 라이브러리와 실행파일이 격리되어야 한다.
VMware/VirtualBox/QEMU로 대표되는 가상머신 소프트웨어는 현재 사용중인 호스트 컴퓨터의 환경으로부터 독립된 가상 하드웨어를 소프트웨어적으로 구현하는데에 그 목적이 있다. 예를 들어 x86 CPU를 사용하고 Windows 10을 운영체제로 하는 컴퓨터가 있을 때, ARM CPU를 사용하는 Raspberry Pi에서 구동되는 소프트웨어를 개발하고 이를 테스트하기 위해 새로운 하드웨어를 구비하는 것은 비효율적이므로, 소프트웨어를 이용해 ARM CPU가 구동되는 하드웨어 환경을 가상으로 구현하는 식이다. 또 다른 예로 Windows 10 환경에서 Windows XP 이하에서만 돌아가는 소프트웨어를 구동해야 할 경우 가상머신 소프트웨어로 가상의 컴퓨터를 구현해 Windows XP를 설치하여 사용하는 방식도 가능하다. 이러한 가상머신의 하드웨어는 호스트 컴퓨터로부터 완벽히 독립적으로 운영되고, 커널, 라이브러리, 실행파일 또한 가상머신에 종속된다.
4. 컨테이너의 한계
컨테이너를 복사해 사용할 환경이 컨테이너를 빌드한 환경과 커널 버전이 다르면 컨테이너가 구동되지 않을 수도 있다. 리눅스 커널 5.15에서 구성한 컨테이너가 커널 리눅스 커널 6.2에서 돌아가지 않을 수도 있다는 뜻이다.만약 컨테이너가 x86_64 하드웨어에 맞는 커널에서 빌드하였지만 ARM 하드웨어에 설치된 커널이 x86_64로 만들어진 컨테이너를 호환하여 지원하던지 컨테이너가 다양한 커널을 지원한다면[2] 컨테이너는 커널에 의존하기 때문에 가상머신에 비해 효율적으로 동작할 수 있다. 보통 컨테이너에 의존하는 커널은 하드웨어 또는 가상머신에서 만든다.