컨테이너 기술은 현대 애플리케이션 배포와 관리를 단순화하는 핵심 요소로 자리 잡았습니다. 그러나, 컨테이너를 실제로 실행할 때 일어나는 내부 작업은 어떻게 이루어질까요? 이번 글에서는 Docker, runC, gVisor, Kata 컨테이너와 같은 주요 컨테이너 런타임이 어떻게 작동하는지 고수준에서 살펴보겠습니다.
Docker 컨테이너 실행의 내부 동작
먼저, docker run nginx 명령을 예로 들어보겠습니다. 이 명령을 실행하면 Docker는 다음과 같은 단계를 거칩니다:
-
명령 전달: Docker CLI는 사용자가 입력한 명령을 RESTful API 요청을 변환하여 Docker 데몬(dockred)에 전달합니다.
-
이미지 확인: Docker 데몬은 로컬에 Nginx 이미지가 있는지 확인합니다. 만약 이미지가 없다면, Docker 레지스트리(기본적으로 Docker Hub)에서 이미지를 다운로드 합니다.
-
컨테이너 시작: 이미지를 다운로드한 후, Docker 데몬은 containerd에 호출을 보내 컨테이너를 시작합니다.
Containerd와 runC
Docker의 중요한 구성 요소인 containerd는 이미지를 OCI(오픈 컨테이너 이니셔티브) 호환 번들로 변환하고, 이 번들을 containerd-shim을 통해 runC에 전달합니다. runC는 커널의 네임스페이스와 CGroups를 사용하여 컨테이너를 생성하고 실행합니다.
RunC: 기본 컨테이너 런타임
runC는 OCI 표준을 준수하는 기본 컨테이너 런타임입니다. Docker를 사용하지 않고도 runC CLI를 통해 직접 컨테이너를 실행할 수 있습니다. 그러나 이미지 관리, 네트워킹, 볼륨 관리 등의 기능이 부족하기 때문에 runC만으로는 컨테이너의 수명 주기를 관리하기가 어렵습니다. runC는 Podman 및 CRI-O와 같은 다른 컨테이너 도구에서도 기본 런타임으로 사용됩니다.
다른 컨테이너 런타임: Kata 컨테이너와 gVisor
Kata 컨테이너
Kata 컨테이너는 경량의 가상 머신을 사용하여 격리된 환경을 제공합니다. 이는 kata-runtime을 사용하여 컨테이너를 실행합니다. Kata 컨테이너는 높은 보안성과 격리를 제공하면서도 OCI 호환성을 유지하므로 Docker CLI를 통해 쉽게 사용할 수 있습니다.
gVisor
gVisor는 사용자 공간 커널을 통해 컨테이너의 보안을 강화합니다. gVisor는 Runsc라는 런타임을 사용하여 컨테이너를 실행하며, 마찬가지로 OCI 호환성을 유지하여 Docker CLI와 호환됩니다.
Docker CLI로 다양한 런타임 사용하기
Docker CLI를 사용하여 특정 런타임을 지정하여 컨테이너를 실행할 수 있습니다. 예를 들어, Kata 컨테이너와 gVisor를 사용할 때 다음과 같은 명령을 사용할 수 있습니다:
docker run --runtime=kata-runtime nginx
docker run --runtime=runsc nginx이 명령어는 각각 Kata 컨테이너와 gVisor 런타임을 사용하여 Nginx 컨테이너를 실행합니다.
마무리
컨테이너 기술은 단순히 Docker만을 의미하지 않습니다. 다양한 런타임 옵션을 통해 보안성과 성능을 최적화할 수 있습니다. runC, Kata 컨테이너, gVisor와 같은 런타임은 각기 다른 장점을 제공하며, 사용 사례에 맞게 선택할 수 있습니다. Docker CLI를 통해 이러한 다양한 런타임을 손쉽게 사용할 수 있으므로, 컨테이너 기술의 전체적인 이해와 활용이 더욱 중요해지고 있습니다. 이상으로, 컨테이너 실행의 내부 동작과 다양한 런타임에 대해 살펴보았습니다.
