[Docker] 도커 컨테이너, 가상화, 내부구조 (feat. VM vs Container)

💡 본 문서는 'Docker 컨테이너, 가상화, 내부구조'에 대해 정리해놓은 글입니다.
기본적으로 Docker가 생겨난 배경부터 Docker의 기반 기술에 대해 상세하게 정리해놓은 글이니 참고부탁드립니다.

1. 컨테이너 기술의 탄생 배경

1.1 가상화 기술: Virtual Machine, Hypervisor...

1.1.1 Virtual Machine(이하 VM)

가상화 기술 발전 이전에는 하나의 서버에 하나의 애플리케이션만 구동시킬 수 있었습니다. 하나의 서버에 하나의 OS, 프로그램 만을 운영하기 때문에 안정적이었지만, 남는 서버 자원을 그대로 방치시키기 때문에 비효율적인 경우가 많았습니다.

이런 비효율성을 극복하기 위해 등장한 것이 '가상화 기술'이며, 이는 물리적인 하드웨어 자원을 논리적인 리소스로 제공하여 각 프로세스에 할당합니다. 그 중에서도 '하이퍼바이저' 기반의 가상화가 많이 이용되었습니다. 하이퍼바이저는 논리적으로 분할된 공간에서 VM 이라는 독립된 가상환경을 만들고 호스트 시스템에서 VM 에 깔린 게스트 OS 를 구동 및 모니터링 하는 역할을 합니다(하이퍼바이저에 대해서는 하단의 '1.2 hypervisor (이하 하이퍼바이저)'를 참고하시기 바랍니다.). 하이퍼바이저를 통해 가상화를 적용하면 물리적인 서버의 OS 위에 하나 혹은 그 이상의 독립적인 운영체제가 돌아갈 수 있습니다. 

이 방법을 사용하면 서버에서 하나의 OS 만 돌릴 때 보다 물리적 서버의 자원을 더 효율적으로 사용할 수 있지만, 각각의 OS 들을 위해 매번 자원을 할당하고 부팅을 해야하기 때문에 시간 및 리소스 소모가 큽니다.

위에서 언급했듯이 VM은 some level of hardware와 kernel virtualization 을 통해 guest os를 실행시킵니다. 하이퍼바이져 라는 소프트웨어가 존재하여 virtualized hw, virtual network interface, virtual cpu 등을 제공하여 VM을 구현시켰고, VM은 guest kernel을 가져서 만들어진 virtual hw에 접근합니다. 하지만 이 방법은 가상화해야할 파트가 너무 많아 cost가 큽니다. 위 나열한 컴포넌트들처럼 한 머신에 isolated group이 많은데, 이를 또 나눠서 VM을 만드는 HW virtualization이 필요하기에 좋은 방법이 아닙니다.

1.1.2 Hypervisor (이하 하이퍼바이저)

가상 머신 모니터라고도 불리는 하이퍼바이저는 하이퍼바이저 운영 체제와 가상 머신의 리소스를 분리하여 가상 머신의 생성과 관리를 지원합니다. 이러한 하이퍼바이저에는 두가지 유형이 있으며, Type-1과 Type-2 하이퍼바이저가 있습니다.

TYPE-1 하이퍼바이저 (Bare Metal)

네이티브, 베어 메탈 또는 microkernelized 하이퍼바이저라고도 불리는 Type-1 하이퍼바이저는 호스트의 H/W에서 직접 구동되어 게스트 OS를 관리합니다. 호스트 운영 체제 대신 VM 리소스는 하이퍼바이저에 의해 H/W에 직접 예약되기에 Type-2에 비해 오버헤드가 적습니다. 이러한 Type-1 하이퍼바이저는 엔터프라이즈 데이터 센터와 서버 기반 환경에서 가장 일반적으로 사용됩니다.

• e.g. KVM, Microsoft Hyper-V, Citrix XenServer, VMware vSphere
  • KVM은 2007년에 Linux 커널로 통합되었으므로 현대적인 버전의 Linux를 사용하는 경우 이미 KVM 액세스 권한을 갖고 있습니다. 
• 추가적으로 Type-1 Hypervisor는 성능 개선을 위해 게스트OS의 수정이 필요하느냐로 전가상화, 반가상화 방법으로 나뉩니다.

TYPE-2 하이퍼바이저 (Hosted)

호스트 또는 monolithic 하이퍼바이저라고도 불리는 Type-2 하이퍼바이저는 기존의 운영 체제에서 소프트웨어 레이어 또는 애플리케이션으로서 구동됩니다. 호스트 OS에서 게스트 OS를 추상화하는 방식으로 작동하여 설치 및 구성이 편리합니다. VM 리소스는 호스트 OS에 따라 예약된 후 하드웨어에 대해 실행되기에 오버헤드가 발생할 수 있습니다. 이러한 Type-2 하이퍼바이저는 개인 컴퓨터에서 여러 개의 운영 체제를 구동하려는 개인 사용자에게 이상적입니다. 

• e.g. VMware Workstation, MS Virtual Server, Oracle VirtualBox

1.1.3 가상화 기술의 특징 및 장점

위와 같이 가상화 기술은 자원을 처리하는 풀을 생성하여 가상화된 CPU, 메모리, 스토리지, 네트워크 인터페이스 등의 할당된 자원을 각 가상 머신에 제공하고, 실제 자원에 대한 VM 자원의 일정을 관리합니다. 호스트 시스템의 하드웨어는 요청을 받아서 실행 작업을 수행하는데, 하이퍼바이저가 VM 의 작업 일정을 관리하면서 VM 의 작업을 요청하면 CPU 가 VM 의 요청을 받아서 CPU 명령을 실행합니다.

하이퍼바이저를 사용하여 가상 머신을 실행시키면 여러개의 다른 OS 를 독립적으로 하나의 호스트 OS 에서 실행할 수 있고, 같은 가상화 하드웨어 자원과 하이퍼바이저를 공유하여 사용할 수 있습니다. 이 것이 가상화의 가장 큰 장점입니다.

1.1.4 가상화의 단점

하지만 이렇게 많은 이점을 가진 '가상화' 기술도 단점이 있습니다.

• 프로세스 단위로 격리하고 싶은 경우, OS level조차도 가상화해야 할 파트가 너무 많아 cost가 크다고 느껴질 때가 많습니다. 
• 또한 VM 마다 고유한 OS(게스트 OS)가 필요하기 때문에, 각각 CPU, RAM 및 기타 리소스 등 별도의 자원를 소비하며 보다 많은 시간과 자원을 낭비하게 됩니다.
• 위와 연장선으로 완전한 운영체제가 올라가기 때문에, 실행 자체만으로도 대량의 메모리가 필요합니다. 프로세스의 경우 전환이 매우 빠르고 애플리케이션들이 대부분의 시간을 sleep상태로 있기에, 여러 개의 VM들이 CPU를 경쟁해도 크게 문제가 되지 않습니다. 하지만 메모리는 CPU 만큼 빠르게 전환(자원 회수) 할 수가 없기에 대량의 메모리를 가지고 있어야 합니다. 가상화를 할 때, 적정 메모리를 산정하는 것은 상당히 까다로운 문제입니다.
• 추가로, 특정 OS는 라이센스가 필요한 경우도 있습니다. 

이 경우에는 Host OS 위에서 프로세스 단위로 격리하는 컨테이너 기술을 이용할 수 있으며, 하단에서 자세히 설명하도록 하겠습니다.

1.2 컨테이너 기술: Container

컨테이너와 VM 모두 다른 시스템과 격리되어 실행되기에 하이레벨에서는 유사합니다. 하지만 로우레벨에서는 게스트 OS 의 존재 유무로 인해 확장성과 이식성, 자원 효율성 등에 차이가 있어 장단점이 있습니다.

1.2.1 컨테이너 기술의 특징 및 장점

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

컨테이너 모델에서 컨테이너는 VM과 유사합니다. 주요 차이점은 컨테이너에 자체적인 하나의 완전한 OSfull-blown OS 가 필요하지 않다는 점입니다. 실제로 컨테이너 모델에서는 단일 호스트의 모든 컨테이너는 호스트의 OS를 공유합니다. 이것은 CPU, RAM 및 스토리지와 같은 막대한 양의 시스템 리소스가 확보된다는 의미를 가집니다. 또한 라이센스 비용을 절감할 수 있고 OS 패치 및 유지보수의 오버헤드를 줄여주며 VM의 문제를 해결할 수 있습니다. 이로 인해 VM에서 컨테이너를 사용한 후 시간이나 리소스 및 네트워크를 절감할 수 있습니다.

추가로 가상 머신의 경우 부팅 준비하는 것만 해도 상당한 시간이 걸리지만, 컨테이너는 애플리케이션 구동을 위한 패키지(이미지)만 있으면 구동할 수 있습니다. 이로 인하여 컨테이너 워크로드를 노트북에서 클라우드로, 혹은 베어메탈 서버로 쉽게 이동할 수 있습니다. 또한 컨테이너 구동 자체도 일반 프로세스를 실행하는 것과 차이가 없으며, ms 단위로 보다 가볍고 빠르게 실행할 수 있습니다. 

마지막으로 가장 눈에 띄는 컨테이너의 장점은 실행시 디스크 공간 점유도입니다. 가상머신은 완전한 운영체제를 포함하기에 우분투 서버리눅스의 경우 설치만으로도 1G가 넘는 디스크 공간을 사용합니다. 컨테이너는 이미지로 부터 Copy on Write(CoW) 방식으로 만들어지기에, 그 자체로 디스크 공간을 점유하지 않습니다. 

1.2.2 컨테이너 기술의 단점

이렇게 많은 이점을 가진 '컨테이너' 기술도 단점이 있습니다.

• 자원의 격리와 제한이 어렵다. cgroup와 namespace와 같은 기술들이 발전 하고 있기는 하지만, 가상머신에 비해서는 부족한 점이 있다.
• 컨테이너는 시스템과 격리된 하나 이상의 프로세스 들의 집합입니다. 컨테이너는 프로세스들에 대해 이미 지정된 자원들에 대해서만 요청을 허용하는데, 이러한 자원 제한으로 해당 컨테이너가 충분한 용량을 가진 노드에서 실행 가능하다는 것을 보장합니다.
• 컨테이너는 하나의 운영 체제만 구동할 수 있습니다(리눅스 서버를 구동 중인 컨테이너는 리눅스 운영체제만 구동할 수 있습니다).
• 스토리지 성능이 좋지 않다. 가상머신은 블럭 디바이스 위에 ext3, ext4를 이용해서 스토리지를 사용한다. 컨테이너는 AUFS, Device mapper, Overlay Filesystem등과 같은 유니온 파일 시스템(Union filesystem)을 사용하는데, ext4와 같은 파일 시스템 위에 올라가는 데다가 변경된 내용을 기록하고, 기록된 내용으로 부터 원본 데이터를 복원해야 하기 때문에 느릴 수 밖에 없다. 데이터의 읽기와 쓰기를 일반 파일 시스템으로 분리하거나 Btrfs나 ZFS 같은 COW파일 시스템을 이용하는 등으로 문제를 해결 할 수 있기는 하지만, 가상머신에 비해서 신경써야 할게 많다.
• 네트워크 구성이 어렵다. 가상머신은 물리적인 컴퓨터 시스템과 차이가 없어서 네트워크 구성이 특별히 어렵지 않다. 그냥 가상머신 마다 IP 주소 붙여서 연결하면 된다. 하지만 컨테이너는 그렇게 하기 힘들다. 그런 방식을 그냥 사용하면 프로세스에 IP를 주는 것이 되며, 게다가 컨테이너는 대량으로 만들 수 있기 때문에 IP 주소를 붙이는 것 자체가 낭비다. 호스트 운영체제 레벨에서 네트워크를 한번 더 추상화 해야 해서 가상머신 보다 네트워크 구성에 신경을 써야 할게 많다.

그렇기 때문에 단일 OS 커널에서 여러 애플리케이션을 실행하려는 경우에는 컨테이너가 유리하고, 서로 다른 OS 환경에서 애플리케이션을 실행해야 하는 경우에는 VM 이 필요합니다. 이렇게 컨테이너 기술을 구현한 것 중 가장 널리 쓰는 오픈소스는 '도커'이며, 이 기술의 토대가 되었던 Linux Container와 비교하여 설명하도록 하겠습니다.

2. 컨테이너 기초: 컨테이너와 도커

Quelle: https://robinsystems.com/blog/containers-deep-dive-lxc-vs-docker-comparison/

2.1 Linux Container(이하 LXC)

2.1.1 LXC의 특성

LXC는 단일 컨트롤 호스트 상에서 여러개의 고립된 리눅스 시스템(컨테이너)들을 실행하기 위한 운영 시스템 레벨 가상화 방법입니다. 이러한 컨테이너는 daemon에게 Linux kernel에 존재하는 컨테이너의 기본 building block에 대한 namespaces나 cgroups(control groups)와 같은 접근을 제공했습니다.

• namespace는 간단히 말하자면, 운영 시스템을 쪼개서 각각 고립된 상태로 운영이 되는 개념을 의미해요. 
• cgroups는 간단히 말하자면, namespaces으로 고립된 환경에서 사용할 자원을 제한하는 역할 등을 하는 개념입니다.

이 부분은 Building Block을 이해한 후 다시 보면 이해하는데 도움이 되실거에요.

어쨌든, 분리된 후 고립된 각각의 환경들이 만들어진다는 것을 확인할 수 있는데요. container의 개념을 알고 있다면, 바로 이 기술이 container 기술의 근간이라는 것을 예상할 수 있습니다.

VM처럼 OS level에서 격리하는 것이 아닌 프로세스 단위로 격리합니다. 이러한 컨테이너는 리눅스 커널 기술을 기반으로 구성되었습니다. 이에 대해 간단하게 말하자면 namespace을 통해 가상의 독립된 환경을 만들고 cgroups를 이용하여 각 프로세스와 쓰레드를 그룹으로 나누어 통제함으로써 이전보다 higher level에서 isolation을 하였습니다. 정리하자면 각 namespace가 그에 속한 process들은 하나의 machine처럼 작동합니다. 이 기술을 접목한 LXC (linux containers) 가 나타났으며, 초기 버전의 도커는 LXC를 그대로 사용했습니다.

2.1.2 LXC의 문제점

LXC는 리눅스에 특화되어 있는데, Docker가 Multi-Platform을 목표로 하는데 큰 리스크였습니다. 또한 시스템을 구성하는 핵심적인 요소가 외부 시스템에 의존한다는 문제도 있었습니다. 때문에 Docker사는 LXC를 대체하기 위해 libcontainer라는 독자적인 툴을 개발했으며, go 언어로 작성되어 platform-agnostic(불특정 플랫폼) 툴로 만들어주었습니다. 그래서 Docker 0.9부터 기본 실행 드라이버를 LXC에서 libcontainer로 대체했습니다.

2.1.3 Libcontainer

https://gngsn.tistory.com/128

Libcontainer는 현재의 Docker Engine에서 사용하고 있는 주요 컴포넌트입니다. Go 언어로 만들어져서 Container를 생성 시 namespaces, cgroups, capabilities 를 제공하고, filesystem의 접근을 제한할 수 있습니다. 컨테이너가 생성된 후 작업을 수행할 수 있도록 컨테이너의 수명 주기를 관리할 수 있습니다.

위 그림을 보면 알 수 있듯이, Libcontainer는 LXC와는 다르게 Docker 내부에서 실행되고 있는 것을 확인할 수 있습니다. Docker에서는 자체적으로 제작한 libcontainer의 CLI wrapper인 runc를 사용합니다.

자, 그럼 이제 본격적으로 컨테이너의 구조를 알아볼게요. 도커 내부를 알아가기 전에 도커 용어를 확실히 하고 넘어가야 할 것 같아요. 도커의 구조를 살피며 자주 사용할 단어들을 한번씩 짚고 가겠습니다.

2.2 Docker(이하 도커)

“도커는 리눅스 컨테이너 시스템인 runC를 이용해 하나의 운영체제 위에서 격리된 컴퓨팅 환경을 운영할 수 있도록 도와주는 애플리케이션 레벨 가상화 소프트웨어” ...였지만 위에서 설명했듯이 Windows 또한 NT Kernel 상에서 isolation을 통해 windows(Host) → windows(Base) 컨테이너를 생성하므로 위는 outdated된 정의입니다.

• 컨테이너 가상화는 게스트 운영체제 없이 호스트 운영체제 위에 격리된 환경에서 가상화를 구현함
• 게스트 운영체제가 따로 존재하지 않으니 호스트 운영체제의 요소를 공유하며 그만큼 중복되는 요소가 줄어 성능적 이점을 누릴 수 있음
• 컨테이너는 운영 체제의 동작을 완전히 재현하지는 못하기 때문에, 좀 더 엄밀한 운영 체제의 동작이 요구되는 가상 환경을 구축해야 한다면 VMWare나 VirtualBox가 나음

2.3 도커가 기존 Linux container(이하 LXC)에 비해 가진 장점

• 호스트 운영 체제의 영향을 받지 않는 실행 환경
  • Docker Engine을 이용한 실행 환경 표준화
  • LXC를 사용할 땐 LXC의 설정 차이로 LXC에서 만든 application이 다른 LXC에서 안 돌아가는 문제가 발생하곤 했음
• DSL(Domain Specific Language)를 이용한 Dockerfile
• 이미지 버전 관리
• 레이어 구조를 갖는 이미지 포맷(차분 빌드가 가능함)
• 도커 레지스트리(이미지 저장 서버 역할)

2.4 (현재)도커의 한계: Kernel 및 Architecture의 차이

• 호스트형 가상화 기술처럼 하드웨어를 연산으로 에뮬레이션하는 기술과 달리, 도커에서 사용되는 컨테이너형 가상화 기술은 호스트 운영 체제와 커널 리소스를 공유한다. 이는 사실상 도커 컨테이너를 실행하려면 호스트가 특정 CPU 아키텍처 혹은 운영 체제를 사용해야 한다는 의미. 라즈베리 파이와 같은 ARM 계열의 arm7I 아키텍처를 채용한 플랫폼에서는 인텔의 x86_64 아키텍처에서 빌드한 도커 컨테이너를 실행할 수 없다.
• microsoft의 windowsservercore 이미지는 리눅스나 macOS등의 플랫폼에서는 실행할 수 없다.

2.5 “Container Host”와 “Container OS”의 차이

2.5.1 Container Host (Host OS)

• Docker client와 Docker daemon이 실행되고 있는 곳의 OS
• linux와 non-Hyper-V container들은 Host OS가 Docker container에게 kernel을 나누어주지만, Hyper-V container는 각자의 Hyper-V kernel을 가진다.

2.5.2 Container OS (Base OS)

• Ubuntu, CentOS, windowsservercore와 같이 컨테이너의 OS
• Base OS를 담은 이미지 위로 쌓이는 이미지는 Base OS를 utilize함.

쭉 설명했듯이 도커는 기본적으로 Linux kernel을 이용하여 개발되었다. Docker for Windows/Mac이 linux container를 만들 때는 LinuxKit(linux vm)을 이용한다. → Linux containers are running on Linux, and Windows containers are running on Windows. → 그랬는데 이게 또 windows에선 LCOW가 기본이 되면서 바뀌었다.

• The setup for running Linux containers with LCOW is a lot simpler than the previous architecture where a Hyper-V Linux VM runs a Linux Docker daemon, along with all your containers. With LCOW, the Docker daemon runs as a Windows process (same as when running Docker Windows containers), and every time you start a Linux container Docker launches a minimal Hyper-V hypervisor running a VM with a Linux kernel, runc and the container processes running on top.
• 이렇게하면 Docker Daemon이 windows(Host OS) 위에서 돌아도 Linux Container를 만들 수 있어서 Windows와 Linux 컨테이너를 동시에 실행해줄 수 있다.
• windows container가 windows에서 생성되는 과정이나, docker 자체 기술이나, 현재 진행형으로 새로 개발되는 것들이 있는 것 같다.

3. 컨테이너 기술 심화: 도커 동작원리 및 도커 엔진

3.1 도커 동작원리

도커 컨테이너는 호스트 OS 의 커널을 공유한다. 각 컨테이너에 리눅스 커널을 할당하여 프로세스를 실행시키고 각 컨테이너 간의 격리를 구현한다. 이때 리눅스 커널의 Cgroup 과 네임스페이스 기능을 이용하여 독립된 공간을 구현하도록 한다. 이를 통해서 서로 다른 프로세스, 컨테이너 사이에 벽을 만든다.

호스트 시스템과 컨테이너가 하나의 커널을 공유하기 떄문에 호스트 시스템에서 컨테이너 내부의 프로세스를 볼 수 있다. 컨테이너 내부에서 프로세스를 실행하고 호스트 시스템에서 ps 명령어를 통해 실행중인 프로세스를 조회하면 컨테이너 내부에서 실행 중인 프로세스를 확인할 수 있다.

도커는 도커 엔진을 통해서 실행되고 관리된다. 도커는 리눅스 커널을 사용하기 때문에 호스트 시스템이 리눅스거나 리눅스 커널을 사용할 수 있는 OS 여야 한다. 도커 엔진은 또 하나의 VM 으로 리눅스를 게스트 OS 로 가지고 있다. 이 게스트 OS 인 리눅스의 커널을 컨테이너에 할당하여서 컨테이너가 실행되고, 이 커널을 통해서 각 컨테이너들이 격리된다. 그렇기 떄문에 호스트 OS 가 리눅스가 아니어도 도커를 사용할 수 있다.

3.2 도커 엔진(Docker Engine)

이제 도커 컨테이너를 구축하고 실행하는 핵심 SW인 도커 엔진에 대해 이해해보도록 하겠습니다.

https://gngsn.tistory.com/128

Docker Engine은 Docker Daemon, REST API, API를 통해 도커 데몬과 통신하는 CLI로 모듈식으로 구성되어 있습니다. 개발자들이 Docker라고 할 때, 주로 Docker engine을 의미합니다.

위 그림을 통해 구조를 살펴봅시다. 컨테이너를 빌드, 실행, 배포하는 등의 무거운 작업은 Docker Daemon이 하며, Docker Client는 이러한 로컬 혹은 원격의 Docker Daemon과 통신합니다. 통신을 할 때에는 UNIX socket(/var/run/docker.sock) 또는 네트워크 인터페이스를 통한 REST API를 사용합니다.

3.2.1 docker client (= Docker CLI): docker cli 명령을 dockerd에 요청

docker cli 등에 입력한 명령어(e.g. docker run)를 적절한 REST API payload로 변환해서 dockerd에 post 요청(e.g. POST /containers/create HTTP/1.1)하게 됩니다. 또한 Docker Client는 다수의 데몬과 통신할 수도 있습니다.

이 때 /var/run/docker.sock에 있는 유닉스 소켓을 통해 도커 데몬의 API를 호출하게 되는데, 이 도커 데몬과 통신하기 위한 소켓에 연결할 수 없을 경우 'Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?'과 같은 에러가 발생하곤 합니다.

• Linux에서 socket은 /var/run/docker.sock 이고, Windows에서는 \pipe\docker_engine 입니다.

3.2.2 dockerd (docker deamon): 도커 서비스 관리

도커 데몬은 Docker API 요청을 수신하고, 다른 데몬과 통신하여 도커 서비스를 관리할 수도 있습니다. dockerd의 역할로는 도커 이미지의 관리, 이미지 빌드, REST API, 인증, 보안, 코어 네트워킹, 오케스트레이션 등 다양한 작업을 수행합니다. 

또한 logging drivers, volume 및 volume drivers, network를 설정하는 등 컨테이너에 필요한 대부분의 설정을 지정합니다.

추가로 도커 프로젝트가 커지면서 이 dockerd는 더이상 직접 컨테이너를 실행시키지 않으며, 컨테이너의 실행과 런타임 코드를 모듈화하여 분리(containerd)하였습니다. 대신에 만약 dockerd가 client로부터 ‘새로운 container를 생성하라’는 명령을 수신하면 containerd를 호출합니다. 이때, dockerd는 CRUD 스타일 API를 통해 gRPC로 containerd와 통신합니다.

3.2.3 containerd

현재는 docker에서 분리되어 오픈소스로 운영되고 있는 컨테이너 런타임 코드입니다. containerd는 실제로 containers를 생성하지 못하고 runc를 통해 생성하지만, Docker 이미지를 가져와서 컨테이너 구성을 적용하여 runc가 실행할 수 있는 OCI 번들로 변환합니다. containerd가 실질적으로 컨테이너를 관장하게 되는데, 쿠버네티스에서 만든 Container Runtime Interface(CRI)를 구현합니다. 여기서 컨테이너의 생명 주기를 관장하는데, 이 때 runC를 사용합니다.

원래 containerd는 작고 가벼운 Container lifecycle operations으로 설계되었는데, 시간이 지나면서 image pulls, volumes and networks와 같은 기능들이 확장되었습니다.

• [github] containerd: https://github.com/containerd

# High-Level Runtime

containerd는 High-Level Runtime이며, High-Level Runtime은 보통 이미지 관리, gRPC/Web API와 같이 컨테이너를 관리하는 것 이상의 높은 수준의 기능을 지원하는 런타임을 의미합니다. "high-level container tools", "high-level container runtimes" 으로 부르거나, 가끔은 그냥 "container runtimes”이라고도 부릅니다. 대조적으로, Low-Level Runtime에는 다음으로 볼 runC가 있습니다. 

Docker Client로부터 Container 관련 요청은 dockerd를 거쳐 gRPC 통신을 통해 containerd 로 전달됩니다. 그리고 나서, containerd는 컨테이너의 관리를 위해 runc를 사용하는데요. 그럼, runc가 무엇인지 알아볼게요. 

3.2.4 runC: Container 생성

runC는 *libcontainer용 CLI Wrapper로, 독립된 container runtime입니다. Docker에서 runc는 목적은 단 하나인데요, 바로 Container 생성입니다.
* libcontainer : Docker사가 multi-platform 서비스를 만들기 위해 go 언어로 작성된 패키지.

docker에서 컨테이너 기술을 개발하게 되면서 리눅스의 namespace, control group들과 같은 기술들을 많이 사용하게 되었는데, OS 커널에 접속해서 컨테이너를 만드는 데 필요한 구성 요소(네임스페이스, cgroup 등)을 하나의 low-level component로 묶고 runC라고 이름붙였다고 합니다. 따라서 이는 실제로 컨테이너를 만드는 기술들의 집합으로 runc로 새로운 container를 생성합니다.

현재는 오픈소스로 기부되어 하나의 standalone 프로젝트로서 플랫폼에 관계 없이 container를 구현하는 기술들을 가지고 있습니다.

• [github] opencontainers/runC: https://github.com/opencontainers/runc

# OCI(Open Container Initiative)

runC는 OCI container-runtime-spec의 구현체입니다. OCI는 kernel의 container 관련 기술을 다루는 interface를 표준화시킨 기준입니다. 그래서 runc가 동작하는 계층을 OCI Layer라고 부르기도 합니다.

# Low-Level Runtimes

Low-Level Runtimes는 보통 컨테이너를 운영하는 것에 초점을 맞춘 실제 컨테이너 런타임을 의미합니다.

runC는 독립된 컨테이너 런타임이기 때문에 바이너리로 다운받고 빌드할 수 있습니다. runC(OCI) container를 빌드하고 실행시키는데 모든 것을 갖출 수 있다는 의미입니다.

하지만 이것은 골격(bare bones)일 뿐이며 매우 낮은 레벨(low-level)입니다.즉, 완전한 Docker 엔진의 특성(full-blown)을 가질 수는 없습니다. 

3.2.5 containerd-shim: 생성된 컨테이너의 생명주기 관여

컨테이너 프로세스는 runc의 하위 프로세스로 시작되는데(생성되는 모든 container 당 runc의 새로운 인스턴스를 fork ), 컨테이너 프로세스가 실행하자마자 runc가 종료(exit)됩니다. 이 시점부터 containered-shim이 컨테이너의 새로운 부모 프로세스가 되어 생성된 컨테이너의 생명주기에 관여하게 됩니다. 이는 containerd에게 컨테이너의 *file descriptor(e.g. stdin/out)와 종료 상태를 관리하는 데 필요한 최소한의 코드를 메모리에 남깁니다.

* file descriptor

• 프로세스에서 열린 파일의 목록을 관리하는 파일 테이블의 인덱스입니다. 프로그램이 프로세스로 메모리에서 실행될 때, 기본적으로 할당되는 파일디스크립터는 표준입력(Standard Input), 표준 출력(Standard Output), 표준에러(Standard Error)이며 이들에게 각각 0, 1, 2라는 정수(file table의 인덱스)가 할당됩니다.
• daemon이 재시작될 때, 파이프가 닫히는 등의 이유 때문에 container가 종료되지 않도록 STDIN과 STDOUT 스트림을 열린 상태로 유지합니다.

3.3 오픈소스로서의 도커

여기까지 살펴보고 나니 우리가 현재 크게 docker라고 부르고 있지만 실제로 컨테이너 자체를 구현하는 기술은 Docker, Inc 빠져나와 대부분 오픈소스화 되었다는 것을 알 수 있네요. 현재의 도커 주식회사는 이런 오픈소스들을 더 편하게 쓸 수 있는 Interface를 제공하는 것을 업무로 하고 있다고 볼 수 있겠습니다.

 

참고

• [Redhat] What is a hypervisor: https://www.redhat.com/ko/topics/virtualization/what-is-a-hypervisor
• [Blog] Docker의 컨셉, 내부 구조, 활용 세미나 정리: https://gayuna.github.io/docker/docker/
• [Blog] 도커 정리: https://rokrokss.com/post/2019/10/17/%EB%8F%84%EC%BB%A4-Docker-%EC%A0%95%EB%A6%AC.html