docker架构原理

docker发展史

LXC （Linux Containers）是一种操作系统级别的虚拟化技术，允许使用单个 Linux 内核在宿主机上运行多个独立的系统。

LXC的实现是基于Linux内核的namespaces（uts、mount、pid、ipc、network、user）和cgroups功能。

2013 年， 基于 LXC 技术的 Docker正式发布，它把 LXC 复杂的容器创建与使用方式简化为 Docker 自己的一套命令体系。

从版本 0.9 开始， LXC 被 libcontainer 取代。 docker将namespace和cgroups底层实现都抽象化到 Libcontainer 的接口。这就意味着，底层容器的实现方式变成了一种可变的方案，无论是使用 namespace、cgroups 技术抑或是使用 systemd 等其他方案，只要实现了 Libcontainer 定义的一组接口，Docker 都可以运行。这也为 Docker 实现全面的跨平台带来了可能。

2015 年，docker 发布了 runC，一个轻量级的跨平台的容器运行时。 这基本上就是一个命令行小工具，可以直接利用 libcontainer 运行容器，而无需通过 docker engine。runC 的目标是使标准容器在任何地方都可用。

2015 年，建立OCI规范。包括容器运行时规范和镜像规范。OCI 的目的是围绕容器行业制定标准，比如使用 docker 创建的容器可以在任何其他容器引擎上运行。runc就是OCI标准的一种实现。

2016年，Docker 分拆了 containerd，并将其捐赠给了社区。将这个组件分解为一个单独的项目，使得 docker 将容器的管理功能移出 docker 的核心引擎并移入一个单独的守护进程(即 containerd)。

启动docker后，查看进程

版本为： Docker version 19.03.7
如图，可以看到有两个进程：
/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock 和 /usr/bin/containerd

再查看下安装了哪些命令

创建一个容器后，查看进程

如图：有一个containerd-shim开头的进程

再查看下进程之间的关系

那么问题来了

dockerd, containerd,containerd-shim, runc之间是什么关系？

• docker，没什么说的，面向用户，管理员用来操作的命令行工具，如docker run
• dockerd是docker engine守护进程，dockerd启动时会启动containerd子进程。
• containerd通过shim操作runc，runc真正控制容器生命周期
• containerd-shim，启动一个容器就会启动一个shim进程，shim直接调用runc的包函数,shim与containerd之前通过rpc通信
• runc，真正用户想启动的进程由runc的init进程启动，即runc init [args …]
• CRI 标准

关系图

来源： https://xuanwo.io/2019/08/06/oci-intro/

docker start命令背后发生了什么？

• docker（client）发送启动容器命令给dockerd

• dockerd收到请求后，准备好容器映像rootfs，以及一些其它的配置文件， 然后通过grpc的方式通知containerd启动容器

• containerd根据收到的请求以及配置文件位置，创建容器运行时需要的bundle，然后启动shim进程，让它来启动容器

• shim进程启动后，做一些准备工作，然后调用runc启动容器

• containerd-shim 允许运行时(本例中为 runC)在启动容器后退出

• 该模型带来的最大好处是在升级 docker 引擎时不会中断容器的运行。

参考

https://segmentfault.com/a/1190000010057763