4.3 Docker
Docker是使用最广泛的容器运行时管理工具，其基本思想是隔离运行应用程序的单个进程，并监督容器的生命周期及其所使用的资源。不同于其他容器技术，Docker创新性地解决了应用打包和分发技术难题，并且通过其友好的设计和封装，大大降低了容器技术的使用门槛。
4.3.1 容器运行时
容器运行时主要包括libcontainer、runC和containerd几个部分，下面具体介绍。
1.libcontainer
Docker最初使用LXC来创建容器，后来开发了属于自己的libcontainer库，可与Linux内核（Linux Kernel）功能（如namespace、cgroup）进行交互，用于容器生命周期管理，包括创建和管理隔离的容器环境，如图4-1所示。
图 4-1
2.runC
随着 Docker 内部架构的日渐复杂，Docker 把底层容器管理部分单独剥离出来作为一个底层容器运行时，称作runC。runC中包含了原先的libcontainer库，可以独立于Docker引擎，其目标是使标准容器随处可用。runC专注于容器实现，功能涉及环境隔离、资源限制、容器安全等，后来它被捐赠给了OCI。
3.containerd
在将runC项目捐赠给OCI的同时，Docker在2016年开始使用containerd作为其上层容器运行时。为了使容器生态系统保持标准化，底层的runC容器运行时只允许运行容器，它更轻巧、快速，并且不会与其他更高层级的容器管理发生冲突。而像 containerd 这类的上层容器运行时负责容器生命周期的管理，如镜像传输和存储、容器运行和监控、底层存储、网络附件管理等。
containerd 向上为 Docker 守护进程提供了 gRPC 接口，屏蔽了底层细节，向下通过containerd-shim操控runC，使得上层Docker守护进程和底层容器运行时相互独立。
容器运行时的整体工作流程如图4-2所示。
图 4-2
① Docker引擎创建容器并将其传递给containerd。
② containerd调用containerd-shim。
③ containerd-shim使用runC来运行容器——即使容器死亡，containerd-shim也会保证文件描述符为打开状态。
④ 容器运行时（此处为runC）在容器启动后退出。
4.3.2 镜像
应用打包、部署的最大问题是必须为每种语言、每个框架，甚至每个版本的应用都维护一个打好的包。这个打包过程没有任何通用规则可言，在一个环境中运行得很好的应用，要在另一个环境中运行起来，需要做很多修改和配置工作。而Docker镜像正好解决了打包所存在的根本性问题。所谓Docker镜像，其实就是一个压缩包，这个压缩包直接由一个完整的操作系统的所有文件和目录构成，即包含了这个应用运行所需的所有依赖，所以这个压缩包里的内容与本地开发和测试环境中的操作系统是完全一致的。Docker镜像应用运行方式和环境标准化，其包含完整的运行环境，保证了环境的一致性。
Docker通过容器镜像，直接将一个应用运行所需的完整环境，即整个操作系统的文件系统也打包进去。这种思路解决了困扰PaaS用户已久的一致性问题，制作一个“一次发布、随处运行”的Docker镜像，比制作一个连开发和测试环境都无法统一的Buildpack有意义。Docker大大降低了容器技术的使用门槛，轻量化、可移植、虚拟化、与语言无关，将程序做成镜像可以随处部署和运行，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。Docker允许开发人员将各种应用及其依赖打包到一个可移植的Docker容器镜像中，以Docker容器为运行时资源分割和调度的基本单位，封装整个软件的运行时环境，然后发布到Linux机器上。
4.3.3 Docker总结
按照Docker的设计理念，应用的交付过程就如同海上运输，操作系统如同货轮，在操作系统基础上开发的每一个软件如同集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员（开发人员或系统管理员）定制。如此一来，交付一个应用就相当于交付一系列标准化组件的集合。
通过Docker，我们可以先使用镜像在本地进行开发和测试，然后上传到云端运行。在这个过程中，不需要进行任何修改和配置，因为Docker镜像提供了本地环境和云端环境的高度一致性。大部分镜像都使用相同的操作系统，而且许多文件的内容都一致，因此Docker镜像中的分层机制可以重复利用这些基础文件，从而解决磁盘和内存的开销问题。所以，虽然我们往往把Docker容器归并到PaaS，但其实Docker并不是PaaS，而是为PaaS提供自动化部署功能的工具。