Docker引擎(engine)学习总结

        今日要准备容器培训,学习了docker engine相关的知识,总结记录下。

1、Docker 引擎

        Docker 引擎是用来运行和管理容器的核心软件,采用模块化的设计原则,在许多专用部件的协同工作下实现创建和运行容器,之所以介绍这个是因为它和原理息息相关。

2、早期Docker引擎架构

        Docker 首次发布时,Docker 引擎由两个核心组件构成:LXC 和 Docker daemon。
        Docker daemon 是单一的二进制文件,包含诸如 Docker 客户端、Docker API、容器运行时、镜像构建等。
        LXC 提供了对诸如命名空间(Namespace)和控制组(CGroup)等基础工具的操作能力,它们是基于 Linux 内核的容器虚拟化技术。
        下图阐释了在 Docker 旧版本中,Docker daemon、LXC 和操作系统之间的交互关系。

        早期架构存在以下问题:

        1、对 LXC 的依赖。LXC 是基于 Linux 的。这对于一个立志于跨平台的项目来说是个问题。
如此核心的组件依赖于外部工具,这会给项目带来巨大风险,甚至影响其发展。因此,Docker 公司开发了名为 Libcontainer 的自研工具,用于替代 LXC。Libcontainer 的目标是成为与平台无关的工具,可基于不同内核为 Docker 上层提供必要的容器交互功能。 

        2、Docker daemon太过臃肿。随着时间的推移,Docker daemon 的整体性带来了越来越多的问题。难于变更、运行越来越慢。Docker 公司意识到了这些问题,开始努力着手拆解这个大而全的 Docker daemon 进程,并将其模块化。

3、目前Docker引擎架构

        该模型的显著优势:

        将所有的用于启动、管理容器的逻辑和代码从 daemon 中移除,意味着容器运行时与 Docker daemon 是解耦的,有时称之为“无守护进程的容器(daemonless container)”,如此,对 Docker daemon 的维护和升级工作不会影响到运行中的容器。在旧模型中,所有容器运行时的逻辑都在 daemon 中实现,启动和停止 daemon 会导致宿主机上所有运行中的容器被杀掉。这在生产环境中是一个大问题——想一想新版 Docker 的发布频次吧!每次 daemon 的升级都会杀掉宿主机上所有的容器,这太糟了!幸运的是,这已经不再是个问题。

4、各组件功能描述

组件描述
/usr/bin/dockerdocker客户端,直接面向操作用户;docker与dockerd通过/var/run/docker.sock通讯
/usr/bin/dockerd dockerd即Docker Daemon,是Docker的守护进程;dockerd本身实属是对容器相关操作的api的最上层封装,daemon的主要功能包括镜像管理、镜像构建、RESTAPI、身份验证、安全、核心网络以及编排;dockerd与containerd通信socket文件为/run/containerd/containerd.sock
/usr/bin/containerddockerd实际真实调用的还是containerd的api接口,containerd是dockerd和runc之间的一个中间交流组件;containerd组件确保了Docker镜像能够以正确的OCI Bundle的格式传递给runc。
/usr/bin/containerd-shimcontainerd-shim是一个运行的容器的真实垫片载体,每启动一个容器都会起一个新的docker-shim进程。
他直接通过指定的三个参数:容器id,boundle目录(containerd的对应某个容器生成的目录,一般位于:/var/run/docker/libcontainerd/containerID),运行二进制(默认为runc)来调用runc的api创建一个容器(比如创建容器:最后拼装的命令如下:runc create );他主要有以下三个作用:
1.允许runc在创建&运行容器之后退出
Go编译出来的二进制文件,默认是静态链接,因此,如果一个机器上起N个容器,那么就会占用M*N的内存,其中M是一个runc所消耗的内存。但是出于上面描述的原因又不想直接让containerd来做容器的父进程,因此,就需要一个比runc占内存更小的东西来作父进程,也就是shim。
2.用shim作为容器的父进程,而不是直接用containerd作为容器的父进程,是为了防止这种情况:当containerd挂掉的时候,shim还在,因此可以保证容器打开的文件描述符不会被关掉
shim的主要作用,就是将containerd和真实的容器(里的进程)解耦
3.依靠shim来收集&报告容器的退出状态,这样就不需要containerd来wait子进程
/usr/bin/containerd-shim-runcRunC是运行容器的运行时,根据oci(开放容器组织)的标准来创建和运行容器,它负责利用符合标准的文件等资源运行容器,但是它不包含docker那样的镜像管理功能。所以要用runC运行容器,我们先得准备好容器的文件系统。所谓的OCI bundle就是指容器的文件系统和一个config.json文件。有了容器的文件系统后我们可以通过runc spec命令来生成config.json文件。
Runc实质上是一个轻量级的、针对Libcontainer进行了包装的命令行交互工具
/usr/bin/docker-init我们都知道UNIX系统中,1号进程是init进程,也是所有孤儿进程的父进程。
而使用docker时,如果不加 --init 参数,容器中的1号进程就是所给的ENTRYPOINT,而加上 --init 之后,1号进程就会是 tini。
/usr/bin/docker-proxy用来做容器和宿主机之间的端口映射,其底层是使用iptables来完成的。
Docker run -d -p 10010:10010 busybox sleep10000,ps aux|grep docker命令可以查看规则。
OCI标准容器运行时,Container runtime是指管理和运行容器的工具,当前的容器工具很多,比如docker,rkt等,但是如果每个容器工具都使用
自己的运行时,那么就不利于容器领域的发展,因此,一些容器厂商就一起制定了容器镜像格式和容器运行时的标准,
即OpenContainerInitiative(OCI)。Docker公司参与了OCI着手定义的两个容器相关的规范:镜像规范和容器运行时规范。
OCIbundleOCI Bundle是指满足OCI标准的一系列文件,这些文件包含了运行容器所需要的所有数据,它们存放在一个共同的目录,该目录包含以下两项:1、config.json:包含容器运行的配置数据;2、容器的文件系统
镜像--OCI Bundle--runc--容器

5、参考

https://jiajunhuang.com/articles/2018_12_24-docker_components_part2.md.html

http://c.biancheng.net/view/3137.html

http://events.jianshu.io/p/d08fb1f5de9d

https://www.jianshu.com/p/2e0e33dac632

https://zhuanlan.zhihu.com/p/59796137

### DockerDocker Desktop 和 Docker Engine 的区别与功能对比 #### 1. **Docker** Docker 是一个开源平台,旨在让开发者能够更轻松地构建、共享和运行应用程序。其核心理念是通过容器化技术将应用及其依赖项打包成独立单元,在任何支持 Docker 的环境中都能一致运行[^5]。 - 主要作用:提供一种标准化的方式,用于封装应用程序及其依赖环境。 - 关键特点: - 使用轻量级的容器替代传统虚拟机。 - 支持跨多种操作系统的一致性部署。 - 提供丰富的社区资源和支持。 #### 2. **Docker Engine** Docker EngineDocker 平台的核心组件,负责实际创建和管理容器的技术实现。它是服务端-客户端架构的一部分,其中 `dockerd` 是服务器端守护进程,而 `docker` 命令行工具则是客户端接口[^2]。 - 主要作用:作为底层引擎驱动整个容器生命周期的操作。 - 功能模块: - API 接口:允许外部程序调用以执行各种操作(如启动/停止容器)[^3]。 - 守护进程 (`dockerd`):持续监听并响应来自客户端或其他系统的请求。 - 镜像管理:处理镜像下载、上传以及版本控制等功能。 - 网络与存储插件:定义如何配置容器间的通信及数据持久化方案。 #### 3. **Docker Desktop** 针对 Windows 和 macOS 用户设计的一款综合性开发工具包——Docker Desktop 不仅仅是简单的 GUI 封装那么简单;它集成了多个高级特性和简化版 Kubernetes 单节点集群模拟器于一体。 - 主要用途:为非 Linux 平台上希望体验原生 Docker 流程的人群降低门槛。 - 特殊能力包括但不限于以下几个方面: - 自动化安装好必要的 Hyper-V 或 Hypervisor.framework 技术栈用来承载内部嵌入式的 Linux VM 实例; 这样一来即使宿主机本身不具备直接运行 ELF 可执行文件的能力也无所谓了因为所有工作都会在这个隔离出来的子系统里面完成[^1]。 - 内建集成式 K8S 控制平面方便学习微服务体系结构原理的同时还能快速验证想法原型而不必担心复杂的手工搭建过程. ```bash # 切换上下文示例 docker context use default # 默认指向本地引擎实例 docker context create remote-engine --docker "host=ssh://user@remote-server" docker context use remote-engine ``` 以上脚本展示了如何利用 Docker Contexts 来动态调整当前会话所关联的目标计算资源位置[^4]. --- ### 总结表格 | 属性 | Docker | Docker Engine | Docker Desktop | |-------------------|----------------------------------|------------------------------------|-----------------------------------| | 类型 | 开源项目 | 核心组件 | 桌面应用 | | 工作范围 | 整体生态系统 | 创建和管理容器 | 易于使用的界面 | | 是否需要图形界面 | 否 | 否 | 是 | | 跨平台兼容 | 所有主流OS | 所有主流OS | Win/Mac专有 | | 额外特性 | N/A | API, CLI, 插件体系 | GUI, Kubernetes内置 | ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

情绪零碎碎

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值