docker篇——引擎
作者:互联网
Docker 引擎(engine)
(一)概述
1.简述
docker引擎是用来运行和管理容器的核心软件。代称Docekr或者Docker平台
类比于VMware,将Docker引擎理解为ESXi的角色
2.OCI标准
基于开放容器计划,Docker引擎采用了模块化的设计原则,组件是可替换的。
-
构成
(1) Docker客户端(Docker Client)
(2) Docker守护进程(Docker daemon)
(3) containerd
(4) runc
-
发展
Docker首次发布时,采用的构成如下:
LXC:提供了对命名空间(Namespace)和控制组(CGroup)等基础工具的操作能力,基于Linux内核的容器虚拟化技术。
Docker daemon是单一的二进制文件,包含Docker客户端、Docker API、容器运行时、镜像构建等
摆脱LXC
LXC是基于linux的,对于一个跨平台的项目来说是一个问题。
并且,核心的组件需要依赖于外部的凭条,这会给项目带来风险。
Docker公司发明了Libcontainer的自研工具,用于替代LXC
Libcontainer的目标是成为与平台无关的工具,可基于不同内核为Docker上提供必须的容器交互工能。
docker0.9版本后,Libcontainer取代了LXC成为默认的执行驱动。
模块化daemon
Docker daemon整体涵盖的东西过多,导致了难以变更,运行越来越慢。Docker意识到这个问题之后,开始将大而全的Docker daemon进行拆解,并将其模块化。
runc
- 定义:runc是一个轻量级的、针对libcontainer进行包装的命令行交互工具。
- 作用:创建容器。(CLI包装器,实质上是一个独立的容器运行时工具)
- 拓:runc所在的那一层,也称之为OCI层。
containerd
- 功能:所有容器执行逻辑,主要任务是容器的生命周期管理(strat|stop|pause|rm…)
- 位于daemon和runc所在的OCI层之间,从1.11版本之后Docker开始在linux上使用。
启动一个新容器
$ docker container run --name ctr1 -it alpine:latest sh
当使用Docekr命令行工具执行上诉命令时,Docker客户端会将其转换成为合适的API格式,并将其发送到正确的API端点。
(API实在daemon中实现的,这套功能丰富、基于版本的REST API成为Docker的标志)
一旦daemon接收到创建容器的命令,它就会向container发出调用。
(daemon使用一种CRUD风格API,通过gRPC与container进行通信)
container将Docker镜像转换成OCI bundle,并让runc基于此创建一个新的容器。
runc与操作系统内核接口进行通信,基于所有必要工具(Namespace、CGroup等)来创建容器。容器进程作为runc的子进程启动,启动完毕后,runc将会退出。
shim
shim是实现无daemon的容器(用于将运行中的容器与daemon解耦,以便进行daemon升级等操作)不可或缺的工具。
每次创建容器,都会fork一个新的runc实例。创建容器完毕后,对应的runc进程就会退出。因此,即使运行上百个容器,也无需保持runc实例。
当然,一旦容器进程runc退出,相关联的containerd-shim进程就会成为容器的父进程。作为容器的父进程,shim的职责:
- 保持所有STDIN和STDOUT流是开启状态,从而当daemon重启的时候,容器不会因为管道(pipe)的关闭而终止。
- 将容器的退出状态反馈给daemon。
daemon的作用
将所有用于启动、管理容器的逻辑和代码从daemon中移除,意味着容器运行时与Docker daemon是解耦的,有时称之为无守护进程的容器(daemonless container)
那么剩余的功能还有什么:
- 镜像管理
- 镜像构建
- REST API
- 身份验证
- 安全
- 核心网络
- 编排
个人学习使用
文章总结出处
标签:API,容器,daemon,runc,引擎,LXC,docker,Docker 来源: https://blog.csdn.net/u014112521/article/details/121971157