浅谈Docker 引擎

Docker 引擎是用来运行和管理容器的核心软件。通常人们会简单地将其代指为 Docker 或 Docker 平台。

基于开放容器计划(OCI)相关标准的要求，Docker引擎采用了模块化的设计原则，其组件是可替换的。

Docker 引擎由如下主要的组件构成: Docker 客户端( Docker Client )、Docker 守护进程( Docker daemon )、containerd 以及runc。它们共同负责容器的创建和运行。

runc实质上是一个轻量级的、针对Libcontainer进行了包装的命令行交互工具( Libcontainer取代了早期Docker架构中的LXC )。

runc生来只有一个作用一创建容器，速度很快!不过它是一个CLI 包装器，实质上就是一个独立的容器运行时工具。因此直接下载它或基于源码编译二进制文件，即可拥有一个全功能的runc。但它只是一个基础工具，并不提供类似Docker引擎所拥有的丰富功能。有时也将runc所在的那一层称为“OCI 层”

在对Docker daemon的功能进行拆解后，所有的容器执行逻辑被重构到一个新的名为containerd (发音为container-dee) 的工具中。它的主要任务是容器的生命周期管理———— start | stop | pause | rm….

containerd在Linux和Windows中以daemon的方式运行

Docker引擎技术栈中，containerd位于daemon和runc所在的OCI层之间

随着时间的推移，它被赋予了更多的功能，如镜像管理

常用的启动容器的方法就是使用Docker命令行工具。下面的docker container run命令会基于alpine:latest镜像启动一个新容器。

$ docker container run --name ctrl -it alpine:latest sh

当使用Docker命令行工具执行如上命令时，Docker客户端会将其转换为合适的API格式，并发送到正确的API端点。

API是在daemon中实现的。这套功能丰富、基于版本的REST API已经成为Docker的标志。

一旦daemon接收到创建新容器的命令，它就会向containerd发出调用。daemon已经不再包含任何创建容器的代码了!

daemon使用一种CRUD风格的API,通过gRPC与containerd进行通信。虽然名叫containerd, 但是它并不负责创建容器，而是指挥runc去做。

containerd将Docker镜像转换为OCI bundle,并让runc基于此创建一个新的容器。

然后，runc与操作系统内核接口进行通信，基于所有必要的工具( Namespace、CGroup 等)来创建容器。容器进程作为runc的子进程启动，启动完毕后，runc 将会退出。

将所有的用于启动、管理容器的逻辑和代码从daemon中移除，意味着容器运行时与Docker daemon是解耦的，有时称之为“无守护进程的容器(daemonless container)”,如此，对Docker daemon的维护和升级工作不会影响到运行中的容器。

shim

shim是实现无daemon的容器(用于将运行中的容器与daemon解耦，以便进行daemon升级等操作)不可或缺的工具。

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

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

作为容器的父进程，shim 的部分职责如下。

daemon的作用

daemon的主要功能包括镜像管理、镜像构建、REST API、身份验证、安全、核心网络以及编排。

文章来源网络，作者：运维，如若转载，请注明出处：https://shuyeidc.com/wp/203918.html<