0x00 概述
在掌握 Docker 的一些背景知识后，我们还不得不花费一节的篇幅来简单介绍有关 Docker 核心的一些知识。当然，大家不要觉得有“核心”这类的词，我们就要在这一节中深入 Docker 底层去讲解原理性的东西，更确切的说这一节更像一张词汇表，在掌握这些与 Docker 紧密相关的词汇后，大家可以更好的理解之后小节中的内容。
0x01 四大组成对象
在之前的小节里，我们提到了 Docker 实现容器引擎的一些技术，但那些都是一些相对底层的原理实现，在 Docker 将它们封装后，我们并不会直接操作它们。在 Docker 中，另外提供出了一些软件层面的概念，这才是我们操作 Docker 所针对的对象。
在 Docker 体系里，有四个对象 ( Object ) 是我们不得不进行介绍的，因为几乎所有 Docker 以及周边生态的功能，都是围绕着它们所展开的。它们分别是：镜像 ( Image )、容器 ( Container )、网络 ( Network )、数据卷 ( Volume )。
1.1 镜像
镜像 ( Image ) 这个概念相信大家不会陌生，因为它是其他虚拟化技术 ( 特别是虚拟机 ) 中常常被使用的一个概念。所谓镜像，可以理解为一个只读的文件包，其中包含了虚拟环境运行最原始文件系统的内容。
当然，Docker 的镜像与虚拟机中的镜像还是有一定区别的。首先，之前我们谈到了 Docker 中的一个创新是利用了 AUFS 作为底层文件系统实现，通过这种方式，Docker 实现了一种增量式的镜像结构。
每次对镜像内容的修改，Docker 都会将这些修改铸造成一个镜像层，而一个镜像其实就是由其下层所有的镜像层所组成的。当然，每一个镜像层单独拿出来，与它之下的镜像层都可以组成一个镜像。
另外，由于这种结构，Docker 的镜像实质上是无法被修改的，因为所有对镜像的修改只会产生新的镜像，而不是更新原有的镜像。
1.2 容器
容器 ( Container ) 就更好理解了，在容器技术中，容器就是用来隔离虚拟环境的基础设施，而在 Docker 里，它也被引申为隔离出来的虚拟环境。
如果把镜像理解为编程中的类，那么容器就可以理解为类的实例。镜像内存放的是不可变化的东西，当以它们为基础的容器启动后，容器内也就成为了一个“活”的空间。
用更官方的定义，Docker 的容器应该有三项内容组成：
- 一个 Docker 镜像
- 一个程序运行环境
- 一个指令集合
关于镜像与容器的更多细节知识，我们在后面的小节中还会单独进行讲解。
1.3 网络
对于大部分程序来说，它们的运行都不会是孤立的，而是要与外界或者更准确的说是与其他程序进行交互的，这里的交互绝大多数情况下指的就是数据信息的交换。网络通讯是目前最常用的一种程序间的数据交换方式了。
由于计算机网络领域拥有相对统一且独立的协议等约定，其跨平台性非常优秀，所有的应用都可以通过网络在不同的硬件平台或操作系统平台上进行数据交互。特别是在分布式云计算的时代，应用或服务间的通讯更是充分依赖于网络传输，所以自然拥有一套完善的网络体系支撑，是承载应用运行所必须的基础设施。
在 Docker 中，实现了强大的网络功能，我们不但能够十分轻松的对每个容器的网络进行配置，还能在容器间建立虚拟网络，将数个容器包裹其中，同时与其他网络环境隔离。
另外，利用一些技术，Docker 能够在容器中营造独立的域名解析环境，这使得我们可以在不修改代码和配置的前提下直接迁移容器，Docker 会为我们完成新环境的网络适配。对于这个功能，我们甚至能够在不同的物理服务器间实现，让处在两台物理机上的两个 Docker 所提供的容器，加入到同一个虚拟网络中，形成完全屏蔽硬件的效果。
正是因为拥有强大的网络功能，才能让我们制造健壮的 Docker 应用体系。
1.4 数据卷
除了网络之外，文件也是重要的进行数据交互的资源。在以往的虚拟机中，我们通常直接采用虚拟机的文件系统作为应用数据等文件的存储位置。然而这种方式其实并非完全安全的，当虚拟机或者容器出现问题导致文件系统无法使用时，虽然我们可以很快的通过镜像重置文件系统使得应用快速恢复运行，但是之前存放的数据也就消失了。
为了保证数据的独立性，我们通常会单独挂载一个文件系统来存放数据。这种操作在虚拟机中是繁琐的，因为我们不但要搞定挂载在不同宿主机中实现的方法，还要考虑挂载文件系统兼容性，虚拟操作系统配置等问题。值得庆幸的是，这些在 Docker 里都已经为我们轻松的实现了，我们只需要简单的一两个命令或参数，就能完成文件系统目录的挂载。
能够这么简单的实现挂载，主要还是得益于 Docker 底层的 Union File System 技术。在 UnionFS 的加持下，除了能够从宿主操作系统中挂载目录外，还能够建立独立的目录持久存放数据，或者在容器间共享。
在 Docker 中，通过这几种方式进行数据共享或持久化的文件或目录，我们都称为数据卷 ( Volume )。
0x02 Docker Engine
时至今日，Docker 生态已经远比它诞生之初要庞大许多，虽然我们仍然习惯使用 Docker 这个名字去指代实现容器技术支持的软件，但显然更加容易与其他的概念产生混淆。这里我们很有必要对这个 Docker 中最核心的软件进行介绍，不仅因为它在 Docker 生态中扮演着中心的地位，也因为它是我们在开发中实实在在接触最多的东西。
目前这款实现容器化的工具是由 Docker 官方进行维护的，Docker 官方将其命名为 Docker Engine，同时定义其为工业级的容器引擎 ( Industry-standard Container Engine )。在 Docker Engine 中，实现了 Docker 技术中最核心的部分，也就是容器引擎这一部分。
2.1 docker daemon 和 docker CLI
虽然我们说 Docker Engine 是一款软件，但实实在在去深究的话，它其实算是由多个独立软件所组成的软件包。在这些程序中，最核心的就是 docker daemon 和 docker CLI 这俩了。
所有我们通常认为的 Docker 所能提供的容器管理、应用编排、镜像分发等功能，都集中在了 docker daemon 中，而我们之前所提到的镜像模块、容器模块、数据卷模块和网络模块也都实现在其中。在操作系统里，docker daemon 通常以服务的形式运行以便静默的提供这些功能，所以我们也通常称之为 Docker 服务。
在 docker daemon 管理容器等相关资源的同时，它也向外暴露了一套 RESTful API，我们能够通过这套接口对 docker daemon 进行操作。或者更确切的说，是通过这套 RESTful API 对 docker daemon 中运行的容器和其他资源进行管理。
通常来说，我们是采用在控制台或者命令行输入命令来控制 docker daemon 的，因为这样很酷也更容易适应那些有或者没有图形界面的操作系统。
那么问题来了，如果我们在控制台中编写一个 HTTP 请求以借助 docker daemon 提供的 RESTful API 来操控它，那显然是个费脑、费手又费时间的活儿。所以在 Docker Engine 里还直接附带了 docker CLI 这个控制台程序。
熟悉程序结构的朋友们比较容易看出来，docker daemon 和 docker CLI 所组成的，正是一个标准 C/S ( Client-Server ) 结构的应用程序。衔接这两者的，正是 docker daemon 所提供的这套 RESTful API。