引言

当你想安装一个vim编辑文本，在不同环境里得执行不同的命令。

在ubuntu，你需要执行 apt-get install vim ,

在centos，你需要执行 yum install vim 。

装个小软件尚且如此，要是你想将自己写的代码部署到各个不同操作系统的服务器上，那依赖的软件和配置就更多了，需要针对每个环境单独写一套部署脚本。

（想鼠，太想鼠了）

那么，有没有更好的解决方案？

当然，没有什么是加一层中间层不能解决的，如果有，那就再加一层。

我们这次加的中间层是Docker

更准确的来说是Docker容器

Docker 是什么？

“这个程序在我这边是能跑的，怎么到你这边就不行了？”（a~ng~a~ng~a~ng~a~ng~a~ng~学长鬼叫）

上面的话我们经常听到，那一般是程序和环境的问题。

程序是跑在操作系统上的，而操作系统上又装了各种不同版本的依赖库和配置，这些被程序所依赖的信息，我们统称为环境

程序和环境

程序依赖环境，环境不同，程序就有可能跑不起来。

但是如果我们能将环境和程序一起打包，给对方运行，那问题不就解决了吗。

Docker就是这样一款可以将 程序和环境打包并运行 的工具软件。

它是怎么做的？

要了解这个问题那就...........了解一下吧

基础镜像

上面我们说环境不同，会导致程序运行结果不同，那么我们最重要的就是统一环境

而环境中最重要的就是操作系统，像centeros或者ubuntu，我们得选一个，让所有程序都跑在同一个操作系统上。并且我们知道操作系统分为用户空间和用户空间，应用程序运行在用户空间。

因此，我们可以阉割操作系统

只需要利用操作系统的用户空间部分，就可以构建出程序应用所需的环境，

其次就是统一程序语言依赖，

比如要跑一个python应用，你需要一个python解释器；要跑Java程序，你得装一个JVM

选择好一个操作系统和语言后，我们将它们对应的文件系统，依赖库，配置等放一起打包成一个类似压缩包的文件，这就是我们所谓的基础镜像

Dockerfile

又了基础镜像之后还不够，我们经常还需要安装一些依赖，比如 yum install sqh 甚至要创建一些文件夹，最后才是运行我们的目标应用程序

我们知道 linux 中，所有工作都可以通过命令行完成，所以我们可以将要做的事情以命令行的形式一行行列出来。
就像一份 todo list。
意思是要求在基础镜像的基础上按着 todo list 挨个执行命令。
这份 todo list 长下面这样。

# 指定基础镜像
FROM python:3.9
<h1 id="设置工作目录">设置工作目录</h1>
<p>WORKDIR /app</p>
<h1 id="复制依赖文件到容器中">复制依赖文件到容器中</h1>
<p>COPY requirements.txt .</p>
<p>RUN yum install gcc</p>
<h1 id="安装依赖">安装依赖</h1>
<p>RUN pip install --no-cache-dir -r requirements.txt</p>
<h1 id="将当前目录下的所有文件复制到容器的 /app 目录下">将当前目录下的所有文件复制到容器的 /app 目录下</h1>
<p>COPY . /app</p>
<h1 id="设置容器启动时执行的命令">设置容器启动时执行的命令</h1>
<p>CMD ["python", "app.py"]</p>
<p>

像这样一份列清楚了，从操作系统到应用服务启动，需要做那些事情的清单文件，就是Dockerfile

容器镜像

注意，Dockerfile只是描述了要做哪些事情，并没有真正开始做。

当我们用命令行执行 docker build 的时候，Docker 软件就会按着 Dockerfile 的说明，一行行构建环境+应用程序。最终将这个环境+程序，打包成一个类似"压缩包"的东西，我们叫它容器镜像(container image)。

只要将容器镜像传到任意一台服务器上，对这个压缩包进行解压缩，我们就能同时运行环境和程序。（真不错！）

但是现在还有一个问题，怎么将容器镜像传到那么多服务器上呢？

registry

服务器那么多，挨个将容器镜像传过去也不是不行，就是将压力全给到发送方的网络带宽了。有没有更好的解决方案？
有。可以参考 github 代码仓库 的做法，我们通常会使用 git push 将代码传到 github，有需要的人自己通过 git pull 的方式将代码从 github 拉到自己的机器上。

那 Docker 也一样，弄一个镜像仓库，通过 docker push 将镜像推到仓库，有需要的时候再通过 docker pull 将镜像拉到机器上。这个负责管理镜像仓库推拉能力的服务，就叫 Docker Registry。基于 Docker Registry 的能力，我们可以搭建各种官方或私人镜像仓库，比如官方的叫 DockerHub，非官方的有清华大学的 Tuna 等等，一般公司内部也会有自己的镜像仓库。

容器

现在，我们解决了服务器间传输容器镜像的问题。
我们可以跑到目的服务器上，执行 docker pull 拿到容器镜像。
然后执行 docker run 命令，将这个类似"压缩包"的容器镜像给"解压缩"，获得一个独立的环境和应用程序并运行起来。这样一个独立的环境和应用程序，就是所谓的容器(container)。我们可以在一个操作系统上同时跑多个容器。且这些容器之间都是互相独立，互相隔离的。

与虚拟机关系

眼熟不，这个容器是不是很像我们用 vmware 或 kvm 整出来的传统虚拟机？
但不同的是，传统虚拟机自带一个完整操作系统，而容器本身不带完整操作系统，容器的基础镜像实际上只包含了操作系统的核心依赖库和配置文件等必要组件。
它利用一个叫 Namespace 的能力让它看起来就像是一个独立操作系统一样。再利用一个叫 Cgroup 的能力限制它能使用的计算资源。

所以说，容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。

架构

现在，我们回到日常使用场景中，聊聊 Docker 的架构原理。它是经典的 Client/Server 架构。Client 对应 Docker-cli， Server 对应 Docker daemon。
我们在命令行里敲 Docker 命令，使用的就是 Docker-cli.

Docker-cli 会解析我们输入的 cmd 命令，然后调用 Docker daemon 守护进程提供的 RESTful API，守护进程收到命令后，会根据指令创建和管理各个容器。
再具体点，Docker Daemon 内部分为 Docker Server、Engine 两层。Docker Server 本质上就是个 HTTP 服务，负责对外提供操作容器和镜像的 api 接口，接收到 API 请求后，会分发任务给 Engine 层，Engine 层负责创建 Job，由 Job 实际执行各种工作。

不同的 Docker 命令会执行不同类型的 Job 任务。

docker build

如果你执行的是 docker build 命令，Job 则会根据 Dockerfile 指令，像包洋葱皮似的一层层构建容器镜像文件。

docker pull/push

如果你执行的是 docker pull 或 push 之类的镜像推拉操作，Job 则会跟外部的 Docker Registry 交互，将镜像上传或下载。

docker run

如果你执行的是 docker run 命令，Job 就会基于镜像文件调用 containerd 组件，驱使 runC 组件创建和运行容器。

Docker到底是什么

现在我们再回过头来看这句话，Docker 本质上就是一个将程序和环境打包并运行的工具软件。具体点来说就是，它通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。

好了，到这里，我们就了解了 Docker 的架构和基本运行原理了。
接下来，我们再来聊聊跟 Docker 相关的几个周边。（写的相似）

Docker Compose 是什么？

我们现在知道了 Docker 容器 本身只是一个特殊进程，但如果我想要部署多个容器，且对这些容器的顺序有一定要求呢？比如一个博客系统，当然是先启动数据库，再启动身份验证服务，最后才能启动博客 web 服务。
按理说挨个执行 docker run 命令当然是没问题的，但有没有更优雅的解决方案？
有。我们可以通过一个 YAML 文件写清楚要部署的容器有哪些，部署顺序是怎么样的，以及这些容器占用的 cpu 和内存等信息。

version: "3.8"</p>
<p>services:
A:
image: "some-image-for-a"
deploy:
resources:
limits:
cpus: "0.50" # 限制 CPU 使用率为 50%
memory: 256M # 限制内存使用量为 256MB</p>
<p>B:
image: "some-image-for-b"
depends_on:
- A</p>
<p>C:
image: "some-image-for-c"
depends_on:
- B

然后，通过一行Docker-compose up命令，开始解析 YAML 文件，将容器们一键按顺序部署，就完成一整套服务的部署。
这其实就是 Docker Compose 干的事情。

Docker Swarm 是什么？

Docker 解决的是一个容器的部署。
Docker Compose 解决的是多个容器组成的一整套服务的部署。
那 Docker Swarm 就更高维度了，它解决的其实是这一整套服务在多台服务器上的集群部署问题。
比如在 A 服务器坏了，就将服务在 B 服务器上重新部署一套，实现迁移，还能根据需要对服务做扩缩容。

总结

• Docker 本质上就是一个将程序和环境打包并运行的工具软件，而 Docker 容器本质上只是个自带独立运行环境的特殊进程，底层用的其实是宿主机的操作系统内核。

• Docker 软件 通过 Dockerfile 描述环境和应用程序的依赖关系， docker build 构建镜像， docker pull/push 跟 Docker Registry 交互实现存储和分发镜像，docker run 命令基于镜像启动容器，基于容器技术运行程序和它对应的环境，从而解决环境依赖导致的各种问题。

• Docker 解决的是一个容器的部署问题，Docker Compose 解决的是多个容器组成的一套服务的部署问题，Docker Swarm 解决的是多个容器组成的一套服务在多台服务器上的部署问题，k8s 则是 Docker Swarm 的竞品，在更高维度上兼容了 Docker 容器，实现了容器编排调度。