## [官方文档][1]  * 容器技术的兴起源于 PaaS 技术的普及； * Docker 公司发布的 Docker 项目具有里程碑式的意义； * Docker 项目通过“容器镜像”，解决了应用打包这个根本性难题。 > 容器本身没有价值，有价值的是“容器编排”。 容器技术生态才爆发了一场关于“容器编排”的“战争”。而这次战争，最终以` Kubernetes` 项目和 `CNCF` 社区的胜利而告终。 ## 进程 一旦“程序”被执行起来，它就从磁盘上的二进制文件，变成了计算机内存中的数据、 寄存器里的值、堆栈中的指令、被打开的文件，以及各种设备的状态信息的一个集合。像这样一 个程序运起来后的计算机执行环境的总和，即进程。 而容器技术的核心功能，就是通过约束和修改进程的动态表现，从而为其创造出一个“边界”。 对于 Docker 等大多数 Linux 容器来说，`Cgroups` 技术是用来制造约束的主要手段，而 `Namespace` 技术则是用来修改进程视图的主要方法。 ## Docker 镜像 操作系统分为**内核**和**用户空间**。对于 Linux 而言，内核启动后，会挂载 root 文件系统为其提供用户空间支持。而 Docker 镜像（Image），就相当于是一个 root 文件系统。 Docker 镜像是一个特殊的文件系统，除了提供容器运行时所需的程序、库、资源、配置等文件外，还包含了一些为运行时准备的一些配置参数（如匿名卷、环境变量、用户等） 。镜像**不包含任何动态数据**，其内容在构建之后也**不会被改变**。 ### 分层存储 因为镜像包含操作系统完整的 root 文件系统，其体积往往是庞大的，因此在Docker 设计时，就充分利用 **Union FS** 的技术，将其设计为分层存储的架构。 ## Docker 容器 镜像（Image） 和容器（Container） 的关系，就像是面向对象程序设计中的 **类** 和 **实例**一样，镜像是静态的定义，容器是镜像运行时的实体。容器可以被创建、启动、停止、删除、暂停等。 容器的实质是**进程**，但与直接在宿主执行的进程不同，容器进程运行于属于自己的独立的 **命名空间**。 ### 容器存储层 容器存储层的生存周期和容器一样，容器消亡时，容器存储层也随之消亡。因此，任何保存于容器存储层的信息都会随容器删除而丢失。 按照 Docker 最佳实践的要求，容器不应该向其存储层内写入任何数据，容器存储层要保持无状态化。所有的文件写入操作，都应该使用 数据卷（Volume） 、或者绑定宿主目录，在这些位置的读写会跳过容器存储层，直接对宿主(或网络存储)发生读写，其性能和稳定性更高。 ## Registry 仓库 一个 Docker Registry 中可以包含多个仓库（Repository） ；每个仓库可以包含多个标签（Tag） ；每个标签对应一个镜像。 ## 开源与商业版 开源的 Docker Registry 镜像只提供了 Docker Registry API 的服务端实现，足以支持 docker 命令，不影响使用。但不包含图形界面，以及镜像维护、用户管理、访问控制等高级功能。在官方的商业化版本 Docker Trusted Registry 中，提供了这些高级功能 [1]:https://docs.docker.com/