Docker容器技术基本概念详解

搞懂 Docker 到底是什么，不妨从名字说起。Docker 的英文原意是“码头工人”，也就是搬运工。干的活就是把一个个集装箱（Container）搬来搬去——不过集装箱里装的不是货物，而是各种应用程序。Docker 利用 Linux 容器技术，将应用包装成标准化、可移植、自管理的组件。这意味着你在笔记本上开发、调试、运行完的内容，可以几乎原封不动、顺利地在生产环境中运行，不再出现“在我这能跑啊”的尴尬。

Docker 的底层核心技术是 LXC（Linux Container），但 Docker 在 LXC 基础上增加了一层薄薄的封装，集成了许多实用功能。Stack Overflow 上有一篇高赞回答清晰说明了 Docker 与 LXC 的区别，核心要点如下：

首先，Docker 提供了一种可移植的配置标准化机制，让你能在不同机器上一致地运行同一个容器；而 LXC 本身因机器配置差异，移植起来比较麻烦。其次，Docker 以应用为中心，为部署做了大量优化；LXC 的帮助脚本更关注如何让机器启动更快、内存更少。另外，Docker 为应用提供了一套自动化的构建机制（Dockerfile），连打包、基础设施依赖、安装等事项都一并处理。还有，Docker 实现了类似 Git 的容器版本管理机制，创建过的容器可以像代码一样打标签、回滚，甚至从别人那里下载容器（称为 Image）来扩展，或者像 Git 那样合并。容器本身是可重用、可共享的，Docker 拥有自己的索引仓库（类似 GitHub），你可以注册账号，上传和下载镜像。最后，Docker 提供了丰富的工具链，形成一个完整的生态系统，目标就是自动化、个性化和集成化，连 PaaS 平台都能支持。

那么，Docker 到底有什么用？对运维人员来说，它提供了一种可移植的标准化部署流程，规模化、自动化、异构化的部署从“难搞”变成“轻松搞定”。对开发者来说，它管理开发环境的方法——镜像、构建、共享——让环境一致性问题彻底成为历史。

Docker vs. 虚拟机

从架构上看，虚拟机是一个运行在宿主机上的完整操作系统，会占用大量 CPU、内存和硬盘资源。而 Docker 只包含应用及其依赖库，基于 libcontainer 直接运行在宿主机上，通过轻量隔离实现环境独立。这种设计让 Docker 特别轻量高效，启动一个容器只需几秒钟。正因资源占用少，它特别适合构建标准化的应用。不过 Docker 目前还不完美：隔离性不如虚拟机，毕竟共享的是宿主机操作系统的基础库；网络配置也比较简单，主要以桥接方式为主；查看日志也不如虚拟机那么方便灵活。

IBM 曾发表一篇论文，专门对比虚拟机和 Linux 容器的性能。他们在 CPU、内存、存储 I/O 和网络负载下实测，结果显示 Docker 容器本身几乎没什么开销，但如果使用 AUFS 文件系统，会带来一定性能损耗——此时不如用 Docker Volume。另外，Docker 的 NAT 在网络数据传输量较大时会引入额外工作负载，带来额外开销。不过总体来看，容器的性能与原生相差不大，各方面一般等于或优于虚拟机。两者在 I/O 密集型应用中都需要调优，才能更好地支持读写操作，建议谨慎使用。

Docker 组件

Docker 是经典的 C/S 架构，主要由三部分组成：

• Docker daemon：运行在宿主机上的守护进程，负责管理容器、镜像等。用户通过 Docker client（命令行工具）与 daemon 通信。
• Docker client：命令行工具，用户操作 Docker 的主要方式。它不仅可以直接与本地 daemon 通信，也可以通过 socket 或 RESTful API 远程访问其他机器上的 daemon。
• Docker hub/registry：用于共享和管理 Docker 镜像的仓库。官方地址是 registry.hub.docker.com，你也可以搭建自己的私有 registry。

搞清楚了组件，再说两个核心概念：

Docker image：镜像是只读的，里面包含了运行应用所需的全部文件。一个镜像可以启动多个容器。镜像可以通过 Dockerfile 创建，也可以从仓库下载。

Docker container：容器是 Docker 的运行单元，启动一个镜像就是一个容器。容器之间相互隔离，保证程序运行在相对安全的环境中。

Docker 网络

Docker 的网络功能相对简洁，默认使用 bridge 桥接方式与容器通信。启动 Docker 后，宿主机上会生成一个名为 docker0 的虚拟网络接口——它其实是一个虚拟以太网桥，可以为绑定在上面的接口自动转发数据包，让容器和宿主机之间互通。每次创建一个容器，都会产生一对虚拟接口，在宿主机的 ifconfig 里会多出一个类似 veth**** 的接口，它自动绑定到 docker0 上。由于所有容器都绑在同一桥上，容器之间自然也能互相通信。

在宿主机上执行 ifconfig，会看到 docker0 这个接口。启动一个容器后再看，会多出一个 veth**** 的接口。容器内的默认路由就是宿主机的 docker0 IP 地址——在容器中运行 netstat -r，结果与下图一致：

容器里的默认网关和 docker0 的地址完全一致：

当容器退出后，对应的 veth* 虚拟接口也会被自动销毁。

除了 bridge 模式，Docker 还支持 host、container、none 三种网络通信方式。使用时只需在启动容器时指定 --net 参数，例如：

docker run -i -t --net=host ubuntu /bin/bash

host 方式让容器直接使用宿主机的网络接口，不创建自己的网络协议栈，数据传输效率更高，避免了 bridge 方式带来的额外开销。但这种方式也意味着容器可以访问宿主机的 D-bus 等服务，可能带来意想不到的安全问题，需要谨慎使用。container 方式让容器共享一个已存在容器的网络配置。none 方式则完全不配置网络，留给你自己定制。

Docker 生态

Docker 火起来之后，围绕它形成的生态圈发展非常迅猛。从专门用来部署和运行容器的 CoreOS，到形形色色的管理工具和 PaaS 软件，这股势头一直没停过。下面挑几个有代表性的说说。

先提 CoreOS。这个系统极大推动了 Docker 的普及。CoreOS 是专为大规模服务部署设计的 Linux 发行版，通过运行轻量级容器来方便扩展和维护大规模服务。它的特点很明确：

• 容器即服务：以容器视角管理服务，代码和依赖都打包进容器，直接在 CoreOS 上运行管理，彻底解耦了服务与系统环境。多个容器运行在各自独立的环境中，互不影响。
• 面向集群：CoreOS 为 cluster 大规模部署而生，自带 Etcd 做服务发现，Fleet 管理容器以保证服务可用。
• 更精简：RAM 使用量比普通 Linux 低约 40%。
• 双分区模式（Dual-Partition）：主分区负责系统运行，被动分区负责系统更新，更新时直接下载整个 CoreOS 系统。

Etcd 是一种类似 ZooKeeper 的分布式 key/value 存储服务，提供服务发现和配置管理。Fleet 是容器管理工具，保证服务可用性，当某台机器服务挂了，Fleet 会自动把服务迁移到其他机器上运行。

生态里还有一个重量级容器管理工具——Kubernetes。Google 开源的这个项目，专门用来在集群环境中管理、维护、自动扩展容器。现在 IBM、Microsoft、RedHat 等大公司都在支持它。

Kubernetes 里，Pod 是基本单元，一个 Pod 可以包含提供相同功能的多个容器，这些容器会被部署在同一个 minion 上。Replication Controller 定义了需要运行的 Pod 或容器数量，如果当前集群中的数量不够，它会调度容器到多个 minion 上运行，保证 Pod 数量达标。Service 则定义真正对外提供的服务，一个 Service 对应后端的多个容器。整个架构由一个 Master 和多个 Minion 组成：Master 通过 API 提供服务，接受 kubectl 请求来调度集群；Minion 是运行 Kubelet 的机器，听从 Master 指令创建 Pod 或容器。

最后说说基于 Docker 的 PaaS 软件，其中最知名的当属 Deis 和 Flynn。Deis 基于 Docker 和 CoreOS，是一个轻量级 PaaS，受 Heroku 启发，遵循“十二要素”构建应用。它以应用为中心，分为 build、release、run 三个阶段：用户执行 git push 后，Deis 用 Docker 容器编译并将结果保存为 Docker 镜像；发布阶段，一次 build 加配置文件生成一个带数字标识的发布镜像，存到 Docker registry 里；运行阶段，应用镜像被调度到主机上运行，并更新路由。Flynn 的思路类似，也以应用为中心。它有两层：layer0 负责底层资源抽象，做资源调度和服务发现；layer1 处理具体应用，通过 Docker 容器来编译、部署和维护上层应用程序。