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

📌  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, 제대로 이해하기 (1) 에 이어서,

Container 기술이 가능한 이유인 리눅스 커널의 namespaces, cgroups에 대해 다루려고 합니다.

 

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

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

 

 

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

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

 

[ 1부 ]

History

Docker Engine

 

[ 2부 ]

Namespace

cgroups

 

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

 

 

 

지난 포스팅에서 LXC를 사용하던 예전의 Docker에서 Linux 의존성을 해결하기 위해 libcontainer를 제작했다고 했습니다.

이로 인해 Docker가 LXC나 외부 패키지에 의존하지 않고,

libcontainer를 통해 커널의 container API들을 직접 사용할 수 있게 되었습니다.

 

즉, libcontainer가  이제부터 알아볼 커널 서비스를 사용하여시스템의 리소스를 namespaces, control groups, capabilities, apparmor profiles, network interfaces, firewalling rules 등 을 조작할 수 있게 된 것입니다.

 

결론적으로, 아래와 같은 구조를 보입니다.

 

container - namespaces + cgroups

 

아래에서 개념을 확인해본 후 그림을 다시 보면 쉽게 이해되실거에요.

그럼 자세히 알아보도록 하겠습니다.

 

 

 

🗄  namespaces

Docker를 사용하면서 Process나 Network 등이 어떻게 각 컨테이너마다 따로 관리되는지 궁금하지 않으셨나요?

VM에서는 각 게스트 머신별로 독립적인 공간을 제공하고 서로가 충돌하지 않도록 하는 기능을 갖고 있습니다. Docker에서는 namespaces를 통해 이러한 독립된 공간을 제공합니다.

 

namespaces은 nested process tree를 만들 수 있게 해주며,

이 말은 각 프로세스가 시스템 리소스(process IDs, hostnames, user IDs, network access, interprocess communication, filesystem 등)와 함께 고유하게 분리된 프로세스 트리를 가질 수 있음을 의미합니다.

분리된 process tree는 다른 process tree에서 확인inspect하거나 삭제kill 할 수 없습니다.

 

PID namespace를 알아보며 이해를 더해보겠습니다.

 

 

PID namespace

 

 

모든 시스템은 부팅 시 PID 1 프로세스가 시작되고 그 아래에 모든 프로세스들이 시작됩니다.

프로세스 트리 구조

 

이때, PID namespace로 격리를 하게 되면

하위 namespace의 프로세스가 상위 프로세스의 존재를 알 수 없게 됩니다. 

하지만 상위 namespace의 프로세스는 다른 프로세스인 것처럼 하위 namespace의 프로세스를 전체적으로 볼 수 있습니다.

 

그림에서 보이듯이, PID namespace 격리를 통해

새로 생성된 하위 프로세스는 하나의 시스템인 것처럼 pid를 1로 가정하여 사용됩니다.

 

 

코드를 통해 namespaces를 통한 격리를 어떻게 하고,

어떤 namespaces가 지원되는지 확인해보도록 하겠습니다.

 

 

✔️ namespace isolation

System call - clone() 에 정의된 flags를 지정하여 다양한 namespace를 갖는 하위 프로세스를 생성할 수 있습니다.

 

#define _GNU_SOURCE             /* See feature_test_macros(7) */
#include <sched.h>

int clone(int (*fn)(void *), void *child_stack,
          int flags, void *arg, ...
          /* pid_t *ptid, struct user_desc *tls, pid_t *ctid */ );

 

세 번째 인자로 flags를 지정할 수 있는데요. 

어떤 flags가 있고, 어떤 의미를 가지는지 확인해보도록 하겠습니다.

 

pid_t = pid = clone(cb, *stack, 
                CLONE_NEWPID |    // create new PID namespace
                CLONE_NEWNET |    // create new network namespace
                CLONE_NEWNS |     // create new mount namespace
                CLONE_NEWUTS |    // create new UTS namespace
                CLONE_NEWIPC |    // create new IPC namespace
                SIGCLD, 
              ...);

 

flags들에 지정되는 옵션은 아래와 같은 의미를 갖습니다.

 

PID namespace

for process isolation.

PID (Process ID)를 분할합니다.

 

NET namespace 

for managing network interfaces.

Network interface, iptables 등 network 리소스와 관련된 정보를 분할합니다.

 

IPC namespace 

for managing access to IPC resources.

Inter-process communication - 프로세스간 통신을 격리합니다.

 

MNT namespace 

for managing filesystem mount points.

file system의 mount 지점을 분할하여 격리합니다.

 

UTS namespace

for isolating kernel and version identifiers. 

hostname, domainname 을 변경하고 분할합니다.

자세히 말하자면, Linux system call 중 하나인 uname에서 utsname 라는 struct에 정의된 식별자 중 nodename을 isolate합니다.

 

 

namespace로 시스템에서 컨테이너를 분리하여 서비스를 제공할 수 있음을 알아보았는데요,

또 하나 궁금증이 생깁니다.

 

분리된 환경을 어떻게 신뢰성있게 사용하고, 분리된 자원 관리를 효율적으로 할 수 있었을지 궁금하지 않으신가요 ? 

호기심 강요 중인가요..?

반강제적인 이 질문에 대한 답변은, cgroups을 통해 해결할 수 있습니다 ~

 

 

 

🥁  cgroups

cgroups은 control group을 의미합니다.

기본적으로 프로세스 그룹별로 시스템의 물리적인 리소스(hardware resources)를 제한이나 제약 조건을 적용할 수 있습니다.

제한할 수 있는 리소스에는 아래와 같은 것들이 있습니다.

 

• CPU
• Memory
• Desk I/O
• Network
• Device

 

Kernel에서 cgroup을 제어할 때, 따로 system call을 제공하지 않고

cgroupfs라고 불리는 유사 파일 시스템pseudo-filesystem을 통해 제공됩니다.

 

파일을 통해서 제한을 한다는 게 무슨말일까요?

systemd는 /sys/fs/cgroup 아래에 cgroupfs들을 마운트합니다.

그래서 mount 명령어를 사용하면 마운트되어 있는 cgroupfs들을 확인할 수 있습니다.

 

# mount 
...
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
...

 

 

위에 mount된 파일들을 확인해보면 알 수 있듯이, cgroup은 제어하는 리소스를 타입별로 관리합니다.

각각의 타입에 맞춰 따로 mount해서 관리하는 것이죠.

 

이렇게 특수한 형태의 파일시스템으로 관리되어지기 때문에, 

cgroupfs으로 cgroup을 제어할때는 mkdir, rmdir, echo와 같은 명령어들을 사용할 수 있습니다.

 

예를 들어, cgroup을 생성하는 방법은 cgroupfs에 디렉터리를 생성하면 됩니다.

cgroupfs 내 디렉터리는 하나의 cgroup이며, cgroup은 디렉터리 구조처럼 Tree 형태를 갖습니다.

 

 

 

 

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

컨테이너 기술은 이렇게 namespace, cgroup 를 통해 독립적으로 격리될 수 있었습니다.

궁금증이 풀리면서 뭔가 갈증이 해결된 것 같아요 👊🏻

다음 포스팅은 network, volume에 대한 깊은 내용을 다루겠습니다.

 

부족한 내용이나, 첨언, 피드백 내용이 있다면 댓글로 남겨주시면 정말정말 감사하겠습니다.

 

 

 

참고 자료

docking a docker container part 2

LXC vs Libcontainer

UTS namespace

kakao - cgroup driver