从零开始掌握Docker容器技术：基本概念全面讲解

想要真正理解Docker是什么，不妨从它的名字入手。Docker的英文原意是“码头工人”，也就是搬运工——它的工作就是把一个个集装箱（Container）搬来搬去，只不过这些集装箱里装的不是货物，而是各种应用程序。Docker利用Linux容器技术，将应用封装成标准化、可移植、自管理的组件。这意味着你在笔记本上开发、调试、运行完成的程序，几乎可以原封不动、顺畅地迁移到生产环境，彻底告别“在我这能跑啊”的尴尬局面。

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

首先，Docker提供了一套可移植的配置标准化机制，让你能在不同机器上一致地运行同一个容器；而LXC本身由于机器配置差异，移植起来往往很麻烦。其次，Docker以应用为中心，针对部署做了大量优化；LXC的帮助脚本则更关注如何让机器启动更快、内存占用更少。此外，Docker为应用提供了自动化的构建机制（Dockerfile），连打包、基础设施依赖、安装等环节都一并管理。还有，Docker实现了类似Git的容器版本管理机制，你创建过的容器可以像代码一样打标签、回滚，甚至从别人那里下载容器（镜像）来扩展，或像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为集群大规模部署而生，自带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容器来编译、部署和维护上层应用程序。