1. 云图网首页
  2. 技术专区
  3. linux专区

Docker 核心原理

• linux专区

Docker 核心原理

lxkaka

· · 134 次点击 ·
·
开始浏览    

这是一个创建于 的文章，其中的信息可能已经有所发展或是发生改变。

对 Docker 的使用大部分都比较熟悉，但是说到 docker 的实现原理很多人还是一知半解。我把在团队内部做的一次 Docker 核心原理分享总结到文章里，以供参考。

Docker 的优势

Build once, Run anywhere 上面这句话很精辟的总结了 docker 的优点。我从下面几点具体描述 docker 带给开发者的能力

  • 应用标准化 无论什么语言开发的应用，我们都能用 dockerfile 和构建脚本方便的进行应用构建打包，代码库 + 构建 + registry 统一了 CI/CD 流程，也提升了效率。
  • 环境一致 由于应用和依赖全部构建成镜像，做到了一次构建多次交付，无论是开发，测试还是上线环境都是一致的。大大提高了开发效率
  • 应用隔离 由于通过 docker 部署的应用，容器之间相互隔离，并且能按需分配资源。大大提高了运维效率和资源利用率

架构

Docker使用了 C/S 体系架构，Docker 客户端与 Docker 守护进程通信，Docker 守护进程负责构建，运行和分发 Docker 容器。Docker 客户端和守护进程可以在同一个系统上运行，也可以将Docker客户端连接到远程Docker守护进程。 我们日常在命令行的操作 docker build, docker push, docker pull, docke build 等等操作都是客户端通过 rest api 请求与 Docker 守护进程交互。

docker-cs

实现原理

下面我们就介绍一下 Docker 在实现隔离，资源控制，文件系统等关键部分所采用的的技术

Namespace

Linux manaul page 很好的介绍了 namespace 的作用。 namespace提供了一种内核级别隔离系统资源的方法，通过将系统的全局资源放在不同的 namespace 中，来实现资源隔离的目的。不同 namespace 的进程拥有相互隔离的系统资源。 这里指的资源隔离包含以下这些：

  • Mount: 隔离文件系统挂载点
  • UTS: 隔离主机名和域名信息
  • IPC: 隔离进程间通信
  • PID: 隔离进程的 ID
  • Network: 隔离网络资源
  • User: 隔离用户和用户组
    通过下面的 clone 系统调用可以创建新的进程，参数 flags 控制创建的进程所属的 namespace, 多个 flags 可以同时创建多个 namespace。
int clone(int (*child_func)(void *), void *child_stack, int flags, void *arg);

我们知道容器本质上就是隔离的进程，Docker 在创建容器的时候就是使用 namespace 来实现了容器与容器，容器与宿主机的隔离。 每个进程都有一个 /proc/[pid]/ns 的目录，里面保存了该进程所在对应 namespace 的链接, 我们来查看某个容器也就是某一个进程对应的 namespace 文件描述 

root@lxkaka-server:~# ls -l /proc/23204/ns
total 0
lrwxrwxrwx 1 root root 0 Jan  9 13:51 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jan 20 12:11 ipc -> 'ipc:[4026532341]'
lrwxrwxrwx 1 root root 0 Jan 20 12:11 mnt -> 'mnt:[4026532339]'
lrwxrwxrwx 1 root root 0 Jul  9  2020 net -> 'net:[4026532344]'
lrwxrwxrwx 1 root root 0 Jan 20 12:11 pid -> 'pid:[4026532342]'
lrwxrwxrwx 1 root root 0 Jan  9 13:51 pid_for_children -> 'pid:[4026532342]'
lrwxrwxrwx 1 root root 0 Jan  9 13:51 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jan 20 12:11 uts -> 'uts:[4026532340]'

每个文件都是对应 namespace 的文件描述符，方括号里面的值是 namespace 的 inode，如果两个进程所在的 namespace 一样，那么它们列出来的 inode 是一样的。 我们对比一下另外一个宿主机上的进程 0 

root@lxkaka-server:~# ls -l /proc/20/ns
total 0
lrwxrwxrwx 1 root root 0 Jan 20 12:19 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 ipc -> 'ipc:[4026531839]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 mnt -> 'mnt:[4026531840]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 net -> 'net:[4026531993]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 pid -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 pid_for_children -> 'pid:[4026531836]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Jan 20 12:19 uts -> 'uts:[4026531838]'

可以看到进程，文件系统，网络，进程通信，主机名都是不同的 namespace。

网络模式

Docker 虽然可以通过命名空间创建一个隔离的网络环境，但是如果我们的应用需要对外提供服务，不能与外界进行通信是没有意义的。Docker 提供了多种网络模式来实现容器和外部的通信。 我们重点介绍一下 docker 默认的网络模式 bridge

docker-bridge

守护进程会创建一对对等虚拟设备接口 veth pair，将其中一个接口设置为容器的 eth0 接口（容器的网卡），另一个接口放置在宿主机的命名空间中，以类似 vethxxx 这样的名字命名，从而将宿主机上的所有容器都连接到这个内部网络上。虚拟网桥的工作方式和物理交换机类似，这样主机上的所有容器就通过交换机连在了一个二层网络中。

  • 容器访问外部网络
    请求通过 veth pair 到达 docker0 处，docker0 网桥开启了IP forwarding功能，将请求发送至宿主机eth0； 宿主机处理请求时，使用 SNAT 规则，将源地址替换成了宿主机 ip，然后把报文转发出去
  • 外部访问容器 docker run -p 时，docker 实际是在 iptables 做了DNAT规则，实现端口转发功能。 
# iptables -t nat -L
Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere
DNAT       tcp  --  anywhere             anywhere             tcp dpt:8888 to:172.17.0.4:8888

外部请求访问访问地址为 宿主机ip:8888，网络包到达 eth0; 命中 iptables dnat 规则，把宿主机ip:8888 替换成 容器ip:8888; 宿主机把报文通过 veth pair 传递到容器 eth0

其他网络模式

  • Host 模式 和宿主机共用一个 Network Namespace。容器将不会虚拟出自己的网卡，配置自己的 IP 等，而是使用宿主机的 IP 和端口。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的
  • Contanier 模式 这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等
  • None 模式 使用none模式，Docker 容器拥有自己的 Network Namespace，但是，并不为Docker 容器进行任何网络配置。也就是说，这个 Docker 容器没有网卡、IP、路由等信息。需要我们自己为 Docker 容器添加网卡、配置 IP 等

Cgroups

通过 Linux Namespace 为新创建的进程隔离了文件系统、网络并与宿主机器之间的进程相互隔离，但是 Namespace 并不能够为我们提供物理资源上的隔离，比如 CPU 或者内存。所以 Docker 还借助了 Linux Cgroups 来达到上述目的。 CGroup 全称 Linux Control Group， 是 Linux 内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等) 一组按照某种标准划分的进程，其表示了某进程组，Cgroups 中的资源控制都是以控制组为单位实现，一个进程可以加入到某个控制组。而资源的限制是定义在这个组上，简单点说，cgroup 的呈现就是一个目录带一系列的可配置文件。 理解 cgroups 的几个关键字

  • cgroup 进程组 进程按照某种标准组织成一个控制组，资源的控制定义在这个组上，新加入的进程就继承该组的配置。比如 docker 启动的容器都加入 docker 这个进程组
  • subsystem 子系统 cgroups 为每种可以控制的资源定义了一个子系统(即资源控制器) 
root@lxkaka-server:~# lssubsys
cpuset # 分配单独的 cpu 节点或者内存节点
cpu,cpuacct # 限制进程的 cpu 使用率;cpu 使用统计
blkio # 限制进程的块设备 io
memory # 限制进程的 memory 使用量
devices # 控制进程能够访问某些设备
freezer # 挂起或者恢复 cgroups 中的进程。
net_cls,net_prio # 可以标记 cgroups 中进程的网络数据包，对数据包进行控制
  • hierarch 层级关系 由一系列控制组以一个树状结构排列而成，hierarch 通过绑定对应的子系统进行资源调度。hierarch 中的 cgroup 节点可以包含零或多个子节点，子节点继承父节点的属性。整个系统可以有多个hierarchy。

配置示例
docker run -d --cpus=0.1 --memory=100MB busybox 

root@lxkaka-server:/sys/fs/cgroup/cpu/docker/ee43bb16af9947ed9e8498ad42c859318e001365043e4cda410f68b4a0d79378# cat cpu.cfs_quota_us
10000

root@lxkaka-server:/sys/fs/cgroup/memory/docker/ee43bb16af9947ed9e8498ad42c859318e001365043e4cda410f68b4a0d79378# cat memory.limit_in_bytes
104857600

文件驱动

Docker 中的每一个镜像都是由一系列只读的层组成的，Dockerfile 中的每一个命令都会在已有的只读层上创建一个新的层。当镜像被 docker run 命令创建时就会在镜像的最上层添加一个可写的层，也就是容器层，所有对于运行时容器的修改其实都是对这个容器读写层的修改。容器和镜像的区别就在于，所有的镜像都是只读的，而每一个容器其实等于镜像加上一个可读写的层，也就是同一个镜像可以对应多个容器。

docker-image

这种分层的逻辑是什么呢？ 这就是docker 里文件驱动的职责，负责镜像和容器的文件系统组织。
目前 docker 默认的文件驱动是 overlay2, 它是基于 Linux OverlayFS 的，下面这张图映射了 docker 容器的文件层级结构和 OverlayFS 的对应关系。

overlay2

OverlayFS 是一种堆叠文件系统，它依赖并建立在其它的文件系统之上，不直接参与磁盘空间结构的划分，仅将原来文件系统中不同目录和文件进行 merge。用户看到就是这个 merged 目录。这些被处理的每个目录都被称为层，视图统一的过程则称为联合挂载。多个目录进行层叠，肯定具有上下层关系，OverlayFS 将下层的目录称为lowerdir，上层的目录称为upperdir，被暴露的统一视图目录称为 merged。

容器文件系统层级示例 

root@lxkaka-server:~# docker inspect a2b1e73dda7f
...
"GraphDriver": {
    "Data": {
        "LowerDir": "/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3-init/diff:/var/lib/docker/overlay2/2c24c0bcddaf45a0442e2aa1f061e5a10ac0bb327519c4c7ddc11ecb85878bb1/diff:/var/lib/docker/overlay2/4c689dd9bd8baaff479edf0549e7888b754bf9a635d354e4a7f1531bf946f936/diff:/var/lib/docker/overlay2/84b84a32ceb721075356a9f9d4e8f8c3272a3a440f732a639993293a221236cd/diff:/var/lib/docker/overlay2/fd803c843f13047fd21fda7270a8bec065a4ba62310f95aa5524ec3156755e25/diff:/var/lib/docker/overlay2/fe43a13d9aa35f8b6038d26db6fa83bbd9a108fa59e9599e520505e9b028105d/diff:/var/lib/docker/overlay2/ec929233dc85f54a5b13e906dc1ebd20328fefdebfe2a411a06b6551c501928c/diff",
        "MergedDir": "/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3/merged",
        "UpperDir": "/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3/diff",
        "WorkDir": "/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3/work"
    },
    "Name": "overlay2"
},
...

我们可以看到 lowerdir 包含了多层，每个镜像层目录中包含了一个文件 link，文件内容则是当前层对应的短标识符；lower 文件指向了其所有的父层，其文件内容则是父层id的短标识符；镜像层的内容则存放在 diff 目录 lowerdir 某层示例 

root@lxkaka-server:/var/lib/docker/overlay2/2c24c0bcddaf45a0442e2aa1f061e5a10ac0bb327519c4c7ddc11ecb85878bb1# ls
diff  link  lower  work
root@lxkaka-server:/var/lib/docker/overlay2/2c24c0bcddaf45a0442e2aa1f061e5a10ac0bb327519c4c7ddc11ecb85878bb1# ls
diff  link  lower  work
root@lxkaka-server:/var/lib/docker/overlay2/2c24c0bcddaf45a0442e2aa1f061e5a10ac0bb327519c4c7ddc11ecb85878bb1# cat link
5NC3EXCFR4DKUVKSTJQNDVB3SWroot@lxkaka-server:/var/lib/docker/overlay2/2c24c0bcddaf45a0442e2aa1f061e5a10ac0bb327519c4c7ddc11ecb85878bb1# cat lower
l/XJFQUCXRFOKWIS2NCRBGZOQ573:l/AOHICFFE7WZQDQIZIGXPZSUVPN:l/4DLC3KZMRJUW4GUIU3PIACENJB:l/55TW2N2I52PI5IQD7U5PCZ5H4O:l/5R5RBP6MZNORLVMAOJHVTWMWRN

查看容器层 

root@lxkaka-server:/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3# ls diff
root
root@lxkaka-server:/var/lib/docker/overlay2/77a2b28678d5406b8184e213a725bac51e4bb0132cb2c2c7928c9805bbeb57e3# ls merged/
bin  boot  data  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

# 进入到对应的容器
root@a2b1e73dda7f:/# ls
bin  boot  data  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

我们可以看到容器的目录结构和 merged 是一致的。

多阶段构建

在文章的最后我们介绍比较实用的优化构建的方法，多阶段构建 下面的 dockerfile 是一个简单的 golang 应用构建过程 

FROM golang:1.15.6-alpine3.12

RUN mkdir -p /src
WORKDIR /src
COPY src/ .
RUN go build -o app .
EXPOSE 8000
ENTRYPOINT ["./app"]

对于这个例子来说我们其实只需要构建后的二进制包，其他文件包括 golang 我们都是不需要的。 我们可以把上述构建成两个阶段，可以大大减小构建后的镜像大小 

FROM golang:1.15.6-alpine3.12 as builder

RUN mkdir -p /src
WORKDIR /src
COPY src/ .
RUN go build -o app .

FROM alpine:3.12

COPY --from=builder /src/ .
EXPOSE 8000
ENTRYPOINT ["./app"]



$ docker image ls
REPOSITORY                                        TAG                 IMAGE ID            CREATED             SIZE
app-test                                          v2                  0fde852a1af1        4 seconds ago       13MB
app-test                                          v1                  9d528c34a9f9        15 seconds ago      306MB

v2 是多阶段构建出来的可以看到相比 v1 体积减小了20多倍。

134 次点击  ∙  1 赞  
加入收藏

下一篇：Golang Context 探究

回复

暂无回复

原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/33317.html

赞 (0)
0
上一篇 2021年7月25日
下一篇 2021年7月25日

相关推荐

发表回复

登录后才能评论