Docker笔记(3)-Docker引擎

Docker引擎

图片来自 Nigel Poulton的深入浅出Docker

引擎结构

Docker引擎由如下的组件构成

1. Docker客户端 Docker Client
2. Docker守护进程 Docker Deamon
3. containerd
4. runc

总体逻辑如图

Docker 引擎详解

Docker首次发布时,Docker引擎由两个核心组件构成LXC和Docker Deamon.

Docker Deamon是单一的二进制文件,包含诸如Docker客户端,Docker API,容器运行时,镜像构建等.

LXC提供了对诸如命名空间和控制组等基础工具的操作能力,它们是基于Linux内核的容器虚拟化技术.

摆脱LXC

LXC是基于Linux的,这对于跨平台的项目来说是个问题.

其次核心的组件依赖于外部工具,Docker公司开发了名为Libcontainer的自研工具,用于替代LXC,它的目的是成为平台无关的工具,可基于不同的Docker内核为上层提供必要的容器交互功能.在Docker 0.9 版本中,Libcontainer取代LXC成为默认的执行驱动.

摒弃大而全的Docker deamon

拆解将大而全的Docker deamon进程并将其模块化,即尽可能地拆解出其中的功能特性,并用小而专的工具来实现它.

目前的Docker引擎架构示意图如图

开放容器计划(OCI)

Docker公司进行Docker deamon进程的拆解和重构的时候,OCI也正在着手定义两个容器相关的规范

• 镜像规范
• 容器运行时规范

例如Docker deamon不再包含任何容器运行时的代码,所有的容器运行代码在一个单独的OCI兼容层中实现,默认情况下,Docker使用runc来实现这一点.此外,Docker引擎中的containerd组件确保了Docker镜像能够以正确的OCI Bundle的格式传递给runc.

runc

runc实质上是一个轻量级的,针对libcontainer进行了包装的命令交互工具,有时候将runc所在的那一层称为OCI层

containerd

Docker deamon的功能进行拆解后,所有的容器执行逻辑被重构到containerd中,它的主要任务是容器的生命周期管理 start|stop|pause|rm ...

shim

containerd用来指挥runc创建新容器,每次创建容器时,它都会fork一个新的runc实例,一旦容器创建完毕,对应的runc进程就会退出,因此即时运行上百个容器,也无需保持上百个运行中的runc实例.

一旦容器进程的父进程runc退出,相关联的containerd-shim进程就会成为容器的父进程.

shim进程的部分职责如下:

1. 保持所有STDIN和STDOUT流都是开启状态,从而当deamon重启的时候,容器不会因为管道(pipe)的关闭而终止
2. 将容器的退出状态反馈给deamon

各组件流程