深入理解Docker

Docker

PaaS是（Platform as a Service）的缩写，是指平台即服务。 把服务器平台作为一种服务提供的商业模式，通过网络进行程序提供的服务称之为SaaS(Software as a Service)，是云计算三种服务模式之一，而云计算时代相应的服务器平台或者开发环境作为服务进行提供就成为了PaaS(Platform as a Service)。

SaaS，是Software-as-a-Service的缩写名称，意思为软件即服务，即通过网络提供软件服务。

打包机制

像 Cloud Foundry 这样的 PaaS 项目，最核心的组件就是一套应用的打包和分 发机制。 Cloud Foundry 为每种主流编程语言都定义了一种打包格式，而“cf push”的 作用，基本上等同于用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上 Cloud Foundry 的存储中。接着，Cloud Foundry 会通过调度器选择一个可以运行这个应 用的虚拟机，然后通知这个机器上的 Agent 把应用压缩包下载下来启动。

事实上，Docker 项目确实与 Cloud Foundry 的容器在大部分功能和实现原理上都是一样 的，可偏偏就是这剩下的一小部分不一样的功能，成了 Docker 项目接下来“呼风唤雨”的 不二法宝。 这个功能，就是 Docker 镜像。

Docker 项目给 PaaS 世界带来的“降维打击”，其实是提供了一种非常便利的打包 机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环 境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。

容器编排

Swarm是Docker公司推出的用来管理docker集群的平台，几乎全部用GO语言来完成的开发的， 它是将一群Docker宿主机变成一个单一的虚拟主机，Swarm使用标准的Docker API接口作为其前端的访问入口。

Docker Swarm 和 Docker Compose （Fig 项目）一样，都是 Docker 官方容器编排项目，但不同的是，Docker Compose 是一个在单个服务器或主机上创建多个容器的工具，而 Docker Swarm 则可以在多个服务器或主机上创建容器集群服务，对于微服务的部署，显然 Docker Swarm 会更加适合。

容器，其实是一种特殊的进程而已

Cgroups 技术是用来制造约束的主要手段，而 Namespace 技术则是用来修改进程视图的主要方法

对 Docker 项目来说，它最核心的原理实际上就是为待创建的用户 进程：

1. 启用 Linux Namespace 配置； 2. 设置指定的 Cgroups 参数； 3. 切换进程的根目录（Change Root）。

Docker 在镜像的设计中，引入了层（layer）的概念。也就是说，用户制作 镜像的每一步操作，都会生成一个层，也就是一个增量 rootfs。

第一部分，只读层。 它是这个容器的 rootfs 最下面的五层，对应的正是 ubuntu:latest 镜像的五层。可以看 到，它们的挂载方式都是只读的。

第二部分，可读写层。 它是这个容器的 rootfs 最上面的一层（6e3be5d2ecccae7cc），它的挂载方式为：rw， 即 read write。在没有写入文件之前，这个目录是空的。而一旦在容器里做了写操作，你 修改产生的内容就会以增量的方式出现在这个层中。 如果我现在要做的，是删除只读层里的一个文件呢？ 为了实现这样的删除操作，AuFS 会在可读写层创建一个 whiteout 文件，把只读层里的文 件“遮挡”起来。 比如，你要删除只读层里一个名叫 foo 的文件，那么这个删除操作实际上是在可读写层创 建了一个名叫.wh.foo 的文件。这样，当这两个层被联合挂载之后，foo 文件就会 被.wh.foo 文件“遮挡”起来，“消失”了。这个功能，就是“ro+wh”的挂载方式，即只 读 +whiteout 的含义。我喜欢把 whiteout 形象地翻译为：“白障”。

第三部分，Init 层。 它是一个以“-init”结尾的层，夹在只读层和读写层之间。Init 层是 Docker 项目单独生成 的一个内部层，专门用来存放 /etc/hosts、/etc/resolv.conf 等信息。 需要这样一层的原因是，这些文件本来属于只读的 Ubuntu 镜像的一部分，但是用户往往 需要在启动容器时写入一些指定的值比如 hostname，所以就需要在可读写层对它们进行 修改。 可是，这些修改往往只对当前的容器有效，我们并不希望执行 docker commit 时，把这些 信息连同可读写层一起提交掉。 所以，Docker 做法是，在修改了这些文件之后，以一个单独的层挂载了出来。而用户执行 docker commit 只会提交可读写层，所以是不包含这些内容的。

Linux Namespace 的隔离能力、Linux Cgroups 的限制能力，以及基于 rootfs 的文件系统

从这个结构中我们不难看出，一个正在运行的 Linux 容器，其实可以被“一分为二”地看待：

1. 一组联合挂载在 /var/lib/docker/aufs/mnt 上的 rootfs，这一部分我们称为“容器镜 像”（Container Image），是容器的静态视图；

2. . 一个由 Namespace+Cgroups 构成的隔离环境，这一部分我们称为“容器运行 时”（Container Runtime），是容器的动态视图。