Docker Engine, 제대로 이해하기 (1)

📌  Docker Series

> Docker Engine, 제대로 이해하기 (1) - docker engine deep dive

Docker Engine, 제대로 이해하기 (2) - namespace, cgroup

Docker Network, 제대로 이해하기 (1) - libnetwork

Docker Network, 제대로 이해하기 (2) - bridge, host, none drivers

Docker, 제대로 사용하기 - Commands

안녕하세요. 오늘은 Docker Engine에 대해 깊게 다루려고 합니다.

 

이 포스팅의 목적은 dockerEngine의 내부 구조와 동작원리 등을 최대한 자세히 다루는데 있습니다.

이 글을 읽는 독자가 Docker image, container 등 기본적인 개념을 이해한다는 가정하에 작성합니다.

 

 

참고 사항으로, 포스팅은 " 대주제(이모지+파란글자) > ✔️ 소주제 > # 문단 키워드 " 로 분리해서 정리했습니다.

 

해당 포스팅의 모든 그림은 직접 그린 것으로, 사용시 출처 표시 부탁드립니다 🙏🏻.

 

-----------------    INDEX     -----------------

 

[ 1부 ]

History

Background

초기 Docker engine

docker daemon

LXC

Docker Engine

big picture

docker client

dockerd

containerd

runc

shim

 

[ 2부 ]

Namespace

cgroups

 

[ Docker Network ]

(1) deep dive

----------------------------------------------

 

 

⛱  History

 

Docker는 컨테이너 기술을 사용하여 애플리케이션에 필요한 환경을 신속하게 구축하고 테스트 및 배포를 할 수 있게 해주는 플랫폼입니다. Docker는 왜 생겼을까요? 아주 짧게 그 탄생 과정에 대해 알아볼게요.

 

✔️  Background

# VMware

아-주 예전에는 하나의 서버 당 하나의 애플리케이션이 동작됐습니다.

동일한 서버에서 여러 개의 애플리케이션을 운영 면에서나 보안면에서나 안전하게 실행시키는 기술이 없었죠.

 

그래서 새로운 애플리케이션이 필요할 때마다 서버를 구매해야했고,

무조건 성능과 규모가 좋은 것을 구매하느라 낭비가 심했습니다.

 

그러다가 '가상 머신 VM'이라는 개념이 세상에 나오게 되었고,

하나의 운영체제 위의 여러 OS를 실행시켜 낭비를 크게 줄게 해주었습니다.

 

하지만, 가상머신도 결함을 갖고 있는데요.

하나의 VM 마다 고유한 OS가 필요하기 때문에,

각각 CPU, RAM 및 기타 리소스를 소비하며 보다 많은 시간과 자원을 낭비하게 됩니다.

또한 특정 OS는 라이센스가 필요한 경우도 있습니다. 

 

 

# Container

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

 

컨테이너 모델에서 컨테이너는 VM과 유사합니다.

주요 차이점은 컨테이너에 자체적인 하나의 완전한 OSfull-blown OS 가 필요하지 않다는 점입니다.

 

실제로 컨테이너 모델에서는 단일 호스트의 모든 컨테이너는 호스트의 OS를 공유합니다.

이 것은 CPU, RAM 및 스토리지와 같은 막대한 양의 시스템 리소스가 확보된다는 의미를 가집니다.

또한 , 라이센스 비용을 절감할 수 있고 OS 패치 및 유지보수의 오버헤드를 줄여주며 VM의 문제를 해결할 수 있습니다.

 

결과적으로, VM에서 컨테이너를 사용한 후 시간이나 리소스 및 네트워크를 절감할 수 있는데요.

컨테이너는 또한 시동도 빠르고 매우 휴대성이 뛰어납니다ultra-portable.

컨테이너 워크로드를 노트북에서 클라우드로, 혹은 베어메탈 서버로 쉽게 이동할 수 있습니다.

 

 

 

 

 

✔️  초기 Docker Engine

초기 Docker는 현재 모델과는 다르게 Docker Daemon, LXC 라는 두 개의 주요 구성을 가지고 있었습니다.

 

 

초기 Docker Engine model

 

✔️  docker daemon

이 때 Dokcer Daemon은 현재의 Docker Daemon과는 달랐는데요.

The Docker daemon는 모놀리 바이너리monolithic binary이었습니다. (모듈화가 되어있지 않음)

Docker Daemon에 Docker client, the Docker API, container runtime, image builds 등을 비롯한 많은 코드들을 담고 있었습니다.

 

 

✔️  LXC

 

LXC Architecture

 

 

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

 

namespace는 간단히 말하자면,  운영 시스템을 쪼개서 각각 고립된 상태로 운영이 되는 개념을 의미해요. 

cgroups는 간단히 말하자면,  namespaces으로 고립된 환경에서 사용할 자원을 제한하는 역할 등을 하는 개념입니다.

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

 

어쨌든, 분리된 후 고립된 각각의 환경들이 만들어진다는 것을 확인할 수 있는데요.

container의 개념을 알고 있다면, 바로 이 기술이 container 기술의 근간이라는 것을 예상할 수 있습니다.

 

 

 

# LXC의 문제점

LXC는 리눅스에 특화되어 있는데, Docker가 Multi-Platform을 목표로 하는데 큰 리스크였습니다.

또한, 시스템을 구성하는 핵심적인 요소가 외부 시스템에 의존한다는 문제도 있었습니다.

 

때문에 Docker사는 LXC를 대체하기 위해 libcontainer라는 독자적인 툴을 개발했으며,

go 언어로 작성되어 platform-agnostic(불특정 플랫폼) 툴로 만들어주었습니다.

 

그래서 Docker 0.9부터 기본 실행 드라이버를 LXC에서 libcontainer로 대체했습니다.

 

 

# Libcontainer

Libcontainer는 현재의 Docker Engine에서 사용하고 있는 주요 컴포넌트입니다.

Go 언어로 만들어져서 Container를 생성 시 namespaces, cgroups, capabilities 를 제공하고, filesystem의 접근을 제한할 수 있습니다.

컨테이너가 생성된 후 작업을 수행할 수 있도록 컨테이너의 수명 주기를 관리할 수 있습니다.

 

 

docker architecture

 

 

위 그림을 보면 알 수 있듯이, Libcontainer는Docker와 분리된 LXC와는 다르게,

Docker 내부에서 실행되고 있는 것을 확인할 수 있습니다. 

 

Docker에서는 자체적으로 제작한 libcontainer의 CLI wrapper인 runc를 사용합니다.

 

 

자, 그럼 이제 본격적으로 컨테이너의 구조를 알아볼게요.

도커 내부를 알아가기 전에 도커 용어를 확실히 하고 넘어가야 할 것 같아요.

도커의 구조를 살피며 자주 사용할 단어들을 한번씩 짚고 가겠습니다.

 

 

 

 

⚙️  Docker Engine

Docker는 Client-Server 모델을 구현한 애플리케이션입니다.

Docker Engine은 Docker Components와 서비스를 제공하는 컨테이너를 구축하고 실행하는 기본 핵심 소프트웨어입니다.

 
Docker Engine은 Docker Daemon, REST API, API를 통해 도커 데몬과 통신하는 CLI로 모듈식으로 구성되어있습니다.

개발자들이 Docker라고 할 때, 주로 Docker engine을 의미합니다.

 

Docker Engine은 자동차의 엔진과 비교할 수 있습니다.

 

 

자동차 엔진과 도커 엔진은 비유를 하자면, 둘 다 모듈식이고 많은 전용 부품들에 의해 연결되어 제작됩니다.

Car Engine — intake manifolds, throttle body, cylinders, spark plugs, exhaust manifolds etc.
Docker Engine — APIs, execution driver, runtimes, shims etc.

 

 

아래의 그림으로 구조를 쉽게 파악할 수 있습니다.

 

Docker Engine

 

 

컨테이너를 빌드, 실행, 배포하는 등의 무거운 작업은 Docker Daemon이 하며,

Docker Client는 이러한 로컬 혹은 원격의 Docker Daemon과 통신합니다.

통신을 할 때에는 UNIX socket(/var/run/docker.sock) 또는 네트워크 인터페이스를 통한 REST API를 사용합니다.

 

주로 사람들이 "docker"라는 단어를 말할 때는 다양한 의미를 가질 수 있는데요.

"docker"는 Docker Engine 뿐만 아니라 Docker Client, 혹은 Docker Inc.(도커 개발사)를 의미할 수도 있습니다.

 

 

✔️  big picture

Docker Engine이 동작되는 큰 그림을 먼저 볼게요.

아래의 기능들을 먼저 익힌다음 읽어도 좋습니다.

 

 

1) docker client

 

 

가장 먼저, 유저가 Docker CLI를 통해 아래와 같은 명령어를 입력합니다. 

 (e.g. $ docker container run --name ctr1 -it alpine:latest sh )

 

Docker CLI에 입력하면 Docker client는 적절한 API Payload로 변환해서

Docker Daemon(이하 dockerd)에게 REST API로 POST 요청을 합니다.

(e.g. POST /containers/create HTTP/1.1 )

 

 

2) dockerd

 

 

API는 Unix Socket을 통해 dockerd에게 전달됩니다.

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

 

새 컨테이너를 시작할 때, dockerd는 로컬 이미지가 있는지 확인하고

없다면 registry repository에서 해당하는 이름의 이미지를 가져옵니다.

 

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

 

dockerd가 '새로운 container를 생성하라'는 명령을 수신하면, containerd를 호출합니다.

이때, dockerd는 CRUD 스타일 API를 통해 gRPC로 containerd와 통신합니다.

(e.g. client.NewContainer(context, ...) )

 

 

3) containerd

 

 

containerd는 실제로 containers를 생성하지 못하고, runc를 통해 생성합니다.

Docker 이미지를 가져와서 컨테이너 구성을 적용하여 runc가 실행할 수 있는 OCI 번들로 변환합니다.

 

 

4) runc

 

 

 

runc(내부의 libcontainer 사용)는 OS 커널에 접속해서 

컨테이너를 만드는 데 필요한 모든 구성 요소(네임스페이스, cgroup 등)를 하나로 묶습니다.

runc는 새로운 container를 생성합니다.

 

 

5) shim

 

그 다음 컨테이너를 시작하기 위해 docker-containerd-shim과 같은 shim을 실행합니다.

 

컨테이너 프로세스는 runc의 하위 프로세스로 시작되는데, 컨테이너 프로세스가 실행하자마자 runc가 종료exit됩니다.

이 때, docker-containerd-shim이 새로운 상위 프로세스가 되어 컨테이너의 생명주기를 관리합니다. 

 

 

 

자, 이제 위에서 언급된 모든 기술을 알아보도록 하겠습니다.

 

 

 

✔️  docker client

= docker

흔히 docker라고 부르는 것 중 하나가 바로 Docker Client입니다.

단순히 Docker CLI라고 이해하면 편할텐데요.

 

Docker Client는 개발자들이 Docker를 사용하는 Docker CLI나 Docker Compose로, 

$ docker run 과 같은 명령어를 dockerd에게 REST API 형태로 전달합니다.

 

이 글을 쓰는 시점에서는 Docker 1.41 이 가장 최신이며, 링크를 확인하시면 API 명세를 확인할 수 있습니다.

또한, Docker Client는 다수의 데몬과 통신할 수도 있습니다.

 

글을 정리하며 통신 과정 이해에 참고한 통신 테스트 영상(Docker remote REST API)을 보면 이해에 도움이 될 듯합니다.

 

 

✔️  dockerd

= Docker Daemon (Server)

도커 데몬(dockerd)은 Docker API 요청을 수신하고,

도커 데몬은 다른 데몬과 통신하여 도커 서비스를 관리할 수도 있습니다.

 

dockerd의 역할로는 이미지 관리, 이미지 빌드, REST API, 인증, 보안, 코어 네트워킹, 오케스트레이션 등이 있습니다.

과거의 docker daemon과는 다르게 컨테이너의 실행과 컨테이너 런타임 코드가 모듈화로 분리되어 위의 기능들만 남았습니다.

 

 

 

 

✔️  containerd

containerd는 Container의 생명주기를 관리합니다 (= container lifecycle operations).

containerd는 원래 작고, 가벼운 Container lifecycle operations으로 설계되었는데,

시간이 지나면서 image pulls, volumes and networks와 같은 기능들이 확장되었습니다.

 

기능들이 추가된 이유 중 하나는 다른 프로젝트에서 더 쉽게 사용할 수 있도록 하기 위해서인데요.

예를 들어, Kubernetes같은 프로젝트에서는 containerd를 통해 이미지를 push하고 pull하는 것과 같은 추가적인 작업이 유용하다는 점이 있습니다.

 

모든 추가적인 기능들은 옵션이기 때문에 원하는 것들을 선택하여 반영할 수 있습니다.

 

 

# 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가 무엇인지 알아볼게요.

 

 

✔️  runc

runc는 *libcontainer용 CLI Wrapper로, 독립된 container runtime입니다.

docker가 container 관련된 기능들을 쉽게 사용할 수 있도록 해주는 가볍고 이식가능한 툴입니다.

다시 말해, container 동작 환경이 갖추어진 가볍고 이식 가능한 툴입니다.

Docker에서 runc는 목적은 단 하나인데요, 바로 Container 생성입니다.

 

 

* libcontainer : Docker사가 multi-platform 서비스를 만들기 위해 go 언어로 작성된 패키지. (History - LXC 참고)

 

 

# OCI

runc는 OCI container-runtime-spec의 구현체입니다.

OCI(Open Container Initiative)는 kernel의 container 관련 기술을 다루는 interface를 표준화시킨 기준입니다.

그래서 runc가 동작하는 계층을 OCI Layer라고 부르기도 합니다.

 

 

# Low-Level Runtimes

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

 

runc는 독립된 컨테이너 런타임이기 때문에 바이너리로 다운받고 빌드할 수 있습니다.

runc (OCI) container를 빌드하고 실행시키는데 모든 것을 갖출 수 있다는 의미입니다.

 

하지만 이것은 골격bare bones일뿐이며 매우 낮은 레벨low-level입니다.

즉, 완전한 Docker 엔진의 특성full-blown Docker engine을 가질 수는 없습니다.

 

 

✔️  shim

앞에서 containerd가 새로운 컨테이너를 만들기 위해 runc를 사용한다고 했는데요.

 

생성되는 모든 container 당 runc의 새로운 인스턴스를 fork 합니다.

그러나 각 컨테이너가 생성되면, 상위 runc 프로세스가 종료됩니다.

수백 개의 runc 인스턴스를 실행하지 않고도 수백 개의 container를 실행할 수 있습니다.

 

컨테이너의 할당된 부모 runc 프로세스가 종료되면, 연결된 containerd-shim 프로세스가 컨테이너의 부모프로세스가 됩니다.

이는 containerd에게 컨테이너의 file descriptor(e.g. stdin/out)와 종료 상태를 관리하는 데 필요한 최소한의 코드를 메모리에 남깁니다.

 

* file descriptor

프로세스에서 열린 파일의 목록을 관리하는 파일 테이블의 인덱스입니다. 프로그램이 프로세스로 메모리에서 실행될 때, 기본적으로 할당되는 파일디스크립터는 표준입력(Standard Input), 표준 출력(Standard Output), 표준에러(Standard Error)이며 이들에게 각각 0, 1, 2라는 정수(file table의 인덱스)가 할당됩니다.

 

shim이 컨테이너의 상위 프로세서로서 수행하는 주요 책임은 아래와 같습니다.

 

👉🏻 daemon이 재시작될 때, 파이프가 닫히는 등의 이유 때문에 container가 종료되지 않도록 STDIN과 STDOUT 스트림을 열린 상태로 유지합니다.

👉🏻 daemon에게 container의 종료 상태를 보고합니다.

 

 

 

 

 

이렇게 Docker Engine을 다루는 첫 번째 포스팅을 마치겠습니다.

피드백 내용이 있다면 댓글로 남겨주시면 감사하겠습니다.

 

다음 포스팅은 namespace, cgroup 을 통해 컨테이너 가상화가 실현될 수 있었던 내용을 다루겠습니다.

 

 

 

참고 자료

- O'Reilly - "Docker Deep Dive, The Docker Engine"

- O'Reilly - "Docker: Up & Running, 2nd Edition"

- Docker Engine 공식 문서