什么是Docker容器

1.软件开发面临的那些****问题

程序员根据需求和架构设计翻译出业务逻辑之后，为保证正常转测，打包代码并编写转测说明书。

选定合适的服务器和操作系统，并通过SSH连接服务器，进行手动升级：安装Web容器或数据库、部署软件APP以及配置环境。开发内部测试，如果发现新问题需要进行修复，则再次连接服务器，升级相应的版本和配置环境的变更点。如未发现问题，则通过后转交测试人员。

测试重复开发类似的部署动作，测试通过，版本发布；运维人员拿到版本发布包后，重复测试的部署动作。

这种重复的工作就像双11杂乱的快递不断分拣的过程：

如果有集装箱的话，只要开发集中装箱一次，测试、运维就可以直接用了。

2.Docker是什么？

要将安装好的开发环境打成包，能够切换到测试环境、生产环境，实现“一次打包，到处运行”的目标，就需要实现：

（1）将开发环境原汁原味地打包。

（2）让应用程序认为自己拥有“整个天下”。

针对第一个实现目标：将开发环境原汁原味地打包。

回顾开发环境的安装过程：先安装操作系统、再安装JDK环境、再装Web Server、再部署应用程序。整个安装过程是在操作系统上一层一层安装起来，到最后整个环境是各层安装之后的累加结果。

《初识Docker镜像》一文中介绍了Linux操作系统、UnionFS联合文件系统，UnionFS可实现将多个文件系统的目录或者文件合并成一个“统一的文件系统”，挂载到某个目录（挂载点）下。

针对第二个实现目标：让应用程序认为自己拥有“整个天下”。

进一步解释，让应用程序认为自己拥有独立的计算、存储、网络。这里需要使用命名空间NameSpace技术。Linux命名空间是Linux内核中实现的虚拟化机制，可以将系统资源划分成多个独立的空间，每个空间中的进程逻辑上互相隔离，彼此不影响。

如何让应用程序认为拥有整个文件系统？使用chroot技术。chroot 是一种修改当前进程及其子进程的可见根目录的操作。修改后，进程将不能访问该根目录树以外的任何文件和命令，这种修改后的环境叫作chroot jail（直译为chroot监狱）。

如何保证应用程序使用有限的资源，从而不挤爆整个宿主机？使用cgroup技术。

cgroup也是Linux内核实现的，可以对进程的CPU 时间、系统内存、网络带宽等资源进行分配。

2008年，Linux Container（简称LXC），整合了cgroups和Namespace技术，并合入到Linux内核v2.6.27中。

2013年，Docker公司基于Linux Container开发，并借助于UnionFS，实现了Docker容器技术。

3.Docker是如何运转的？

有了上面可用的技术，还需要做一些约定：

（1）将运行环境所对应的文件系统打成的包，称为镜像（Image）；

（2）将应用程序运行起来的进程，称为容器（Container）；

（3）将存放镜像的地方，称为Repository（仓库）。

有了这些约定，就可以构建一个容器的管理程序，用来：

（1）将环境打包成镜像；

（2）上传、下载镜像到仓库；

（3）运行容器，容器也可以提交为镜像；

容器的管理程序采用C/S架构，服务端称为docker daemon，后端关联仓库。客户端是命令行工具。

4. Docker Daemon是如何演进****的?

上文中展示的Docker Daemon服务端，从Docker v1.11版本开始，便进行拆分重构，如图所示。

包含如下组件：

（1）runc： 负责容器的创建、删除等生命周期管理。后面详细介绍。

（2）Containerd-shim： 是一个守护进程，与Containerd一一对应，并向其提供管理容器生命周期的API，也可以向Containerd 报告容器的退出状态。向下，在runc运行容器之后并退出，containerd-shim作为容器的父进程。这样可以重启Containerd，而不会对运行中的容器产生影响。

（3）Containerd:

containerd是一个守护进程，负责监听传入的请求以进行容器的生命周期管理（启动、停止或报告容器的状态），同时，也负责镜像的管理（上传、下载到仓库，本地保存镜像等功能），以及跨容器的网络管理。

（4）dockerd： 也就是docker daemon，是一个守护进程。提供docker pull、docker push、docker run等命令接口，并将接口转换为containerd API以调用containerd。同时，提供容器编排功能。

下面详细分析runC和containerd两个组件。

首先来看runC。 Docker的底层技术是Namespace和Cgroup，LXC组合了这两种技术，为运行应用程序提供了“隔离”的环境，这些都已经合入到Linux内核。

最初Docker基于LXC进行开发，因存在强绑定问题，而重新开发了libcontainer。

后来因Docker成为事实标准，且不开放，影响到生态建设（影响了Google、微软的发展）。在Linux基金会的参与下，Docker发起OCI组织，起草了OCI标准：

（1）容器运行时标准（runtime spec）：定义了如何根据相应的配置构建容器运行时，也就是指定了容器的配置、执行环境和生命周期。

（2）容器镜像标准（image spec）：定义了容器运行时所使用的镜像打包规范，也就是指定了文件系统标准包bundle的格式。

总的来说，OCI标准指定了容器运行所需要的bundle和配置信息。

Docker公司根据OCI容器运行时标准，将libcontainer进行了二次封装形成新的项目，改为RunC，作为参考实现捐给社区。需要说明的是RunC项目实现了从定义的容器标准包运行容器，而没有实现下载镜像并将解析成标准包。

再来看containerd。

2016年12月，Docker公司将其拆分为独立组件（守护进程），并于2017年3月捐赠给CNCF。

其架构如下图所示。

containerd分为三个大块：Storage、Metadata和Runtimes。其中，Storage 负责镜像的存储、管理和拉取；Metadata用来管理容器及镜像的元数据，Runtimes用来对接runc。

containerd捐给社区后，形成一个庞大的生态：

参考资料

1. 容器运行时规范：https://github.com/opencontainers/runtime-spec2. 容器镜像规范：https://github.com/opencontainers/image-spec3. https://containerd.io/4.https://github.com/containerd/containerd/blob/main/docs/getting-started.md5.https://mp.weixin.qq.com/s/yIuGm92sshYOZAcIpmu9Ag6.https://www.zhangjiee.com/blog/2021/container-runtime.html