도커와 컨테이너 생태계

2016년 도커 사는 컨테이너 기술이 특정 벤더 또는 회사에 의존적으로 개발되지 않도록 중립적인 입장에서 컨테이너 표준을 정의하는 OCI(오픈 컨테이너 계획) 을 발표했습니다. OCI에서는 컨테이너를 구성하기 위해 공통적으로 구현돼야 하는 런타임 및 이미지 스펙의 표준을 정의하고 있으며 2020년 까지는 도커 컨테이너를 포함한 여러 컨테이너 기술이 OCI를 준수하고 있습니다. OCI가 발표된 이후 Moby라는 큰 프로젝트 안에서 도커 컨테이너 기술을 관리하기 시작했고 도커는 runC, containerd 그리고 도커 엔진으로 분리 됐습니다.

도커의 핵심 프로세스라고 하면 보통 도커데몬을 떠올리기 쉽지만 사실 도커 데몬은 컨테이너가 아닙니다.
실제 컨테이너 프로세스라고 부를 수 있을 만한 것은 dockerd가 아닌 runC이며 컨테이너에 1:1로 매칭되는 런타임 역할을 runC가 담당 합니다.
그리고 여러 개의 runC 컨테이너 프로세스 및 이미지를 관리하는 주체가 바로 containerd 입니다. 우리가 알고 있는 도커 엔진은 containerd와 통신해 runC를 사용할 수 있도록 하는 엔드 유저용 도구불과합니다.

즉 컨테이너를 생성하고 사용하기 위해 도커가 반드시 필요한 것은 아니며 runC와 containerd는 도커 엔진 없이도 독립적으로 사용할 수 있습니다. 흔히 도커 컨테이너라고 부르는 것은 정확히 말하자면 도커가 아니라는 점에 유의해야 합니다.

컨테이너 생태계

runC와 containerd 외에도 다양한 컨테이너들이 존재합니다. 호스트와 격리 수준을 높이는 kata 컨테이너, aws 컨테이너, aws에서 개발하고 있는 firecracker, 쿠버네티스 생태계에서 containerd에 대응되는 cri-o 및 도커 엔진에 대응되는 podman 등 다양한 목적을 위해 수많은 컨테이너 런타임이 존재합니다. 그중 도커가 가장 성숙한 기술이기 때문에 가장 많이 사용 되고 있을 뿐인 것입니다.

이를 알아야 하는 이유

컨테이너 기반의 대규모 인프라를 구성하게 되면 이러한 컨테이너 생태계 이야기는 언젠가 한번쯤 반드시 접하게 되기 때문입니다. 이런게 있다고만 알아두고 필요한 순간이 왔을때 runC와 같은 컨테이너를 생각해내는 것이 중요합니다.