引言

在解释docker是什么之前，我们首先应该先了解的是容器化的概念。

什么是容器？就是一个沙箱，在这个沙箱中涵盖了特定应用运行的一切依赖的内容。但他不是一个操作系统，且和底层的操作系统是隔离的。

什么是容器化？容器化就是将软件和应用所需要的所有依赖打包到一个独立的容器中，使得软件能够在不同的计算环境中，高效的、按照预期运行的技术。

先有容器化的概念还是先有的docker？先有的容器化概念，容器化最早提出是在1979年，贝尔实验室发明了chroot，用于将一个进程的文件系统隔离起来，通常认为这是容器技术的开端。

和虚拟化技术有什么联系？有关联也有区别，参考下文“虚化技术”。

Docker 优势

一项技术的优势，通常是在说他解决了传统技术的哪一项痛点，这也是技术持续迭代的一个动力。

传统部署痛点

传统的部署方式通常是在虚拟机上直接部署，如果你有部署过虚拟机服务，你会经历过如下痛点：

1. 环境不一致

主要是设备、系统、工具等方面的差异，举个例子：一般我们在服务器上都是使用Linux的相关版本，所以如果开发使用的是Linux系统，一些脚本等配置都可以无缝迁移，但如果使用windows，我们可能会经历在本地能跑，但是部署到服务器却因为缺少一些信息，无法启动或调用失败的问题。

2. 部署复杂

传统的虚拟机手工部署，在首次部署时，需要安装很多工具包，如果某个步骤出错，就可能会需要我们从头开始排查，耗费比较多的人力成本。后续的部署过程中，以war包为例，如果war包有问题，我们又需要赶紧重新部署旧的服务，否则服务挂了对用户来说太痛了，这个时期的部署一般都选择夜间用户谷期进行。

当然，后来也演化除了一键部署等运维手段，但是依旧有跨环境部署的问题，因为生产环境限制永远要比我们开发测试的环境更高。

3. 资源占用率很高

传统虚拟化技术是模拟完整的操作系统实现相关的隔离，需要提前进行资源的“预分配”，所以这里的资源浪费是比较严重的，一台服务器，可能部署3台虚拟机就到顶了。

4. 扩容效率低

虚拟机部署方式下，我们如果遭遇到突发的大流量，比如某位名人空降微博热搜，这种情况下，大概率是会宕机的（不是DDoS，胜似DDoS），等虚拟机的再扩容启动（虚拟机启动相对耗时较长），这波流量可能就过去了，吃不到。

Docker 的解决方法

对于以上的痛点，Docker 采取了“镜像+容器”的方案来解决，实现了“一次构建，随处运行”。

1. 镜像的本质就是：应用运行时所需要的完整环境快照（包含程序、库、资源、配置文件等），他不包含动态的数据，一旦构建完成，就不会再变了。

由于环境的固化，我们得以实现版本和配置差异的打平，解决了环境不一致的问题。同时由于镜像分层存储的架构设计，使得不同镜像可以复用底层相同的层，从而避免“资源冗余”。

2. 容器的本质则是：一个具有Namespace的进程，它具有自己的文件系统、网络和进程空间。

容器是一个轻量、隔离的执行环境，专门用于运行我们的镜像而不需要考虑能否运行其他应用，同时由于共享操作系统内核，所以他没有内核的开销，不需要安装完整的操作系统，再加上它本身也具有被创建、启动、暂停、停止、删除的能力，所以为什么不能说他是一个轻量化的虚拟机呢？

这些特点使得容器资源占用变低，启动速度更快，从而也使得扩缩容的效率变高。

这里提供一下容器化和虚拟化技术的对比：

Docker 引擎

上文说到容器的本质是一个进程，那么也就是说可以通过操作系统来直接 kill 掉对应的 docker 实例，也可以通过操作系统来启停容器。

理论上来说是这样，但是我们在创建一个 docker 容器的同时，需要需要一个工具帮我们去处理创建该进程所需要准备的东西，以及在创建完成后，可以帮助我们快速的去维护这些容器实例，所以，这样一个工具，就是 Docker 引擎，他能做到的自然是不止我们现在说的这些内容。

从使用层面来说，Docker 引擎是 Docker 的核心组件，但是也不必过于害怕，这也就是一个普通的应用工具，和其他Linux命令一样，只是他的能力聚焦于管理 Docker 核心资源：

镜像（Image）、容器（Container）、网络（Network）、存储卷（Volume）。

Docker 引擎的工作主要是负责管理和运行容器，包含以下几个部分：

• Docker 守护进程：Docker 引擎的后台服务，负责持续运行并处理容器相关的请求，守护进程管理着整个容器的生命周期。
• Docker REST API：提供 HTTP 的 API 接口，通过 HTTP 请求和 Docker 引擎进行交互。
• Docker 命令行工具：cli 工具，可以在命令行直接输入 Docker 命令与 Docker 引擎进行交互。
• 容器与镜像管理：镜像的创建和存储、容器的生命周期管理、容器网络管理。

但整体看下来，不难发现，Docker 引擎所处理的主要就是我们前文所说的两件事情：资源管理和容器的生命周期管理。

在这里的“资源”所指代的范围是比较大的，网络也被认为是一种资源。

在目前的网络上搜索 Docker ，大多数的文章基本是在进行 Docker 的命令行的使用及解释，了解一下就行了，实际使用的时候翻阅也没什么问题：

docker pull
docker run image
docker stop
docker ps
...

Docker 的轻量级

那么 Docker 的轻量级因何而来，为什么他就比虚拟机要轻量？

要理解这个问题，其实也就是一两句话的事情：传统的虚拟机是在一个硬件层之上运行的一个完整的操作系统，而 Docker 则是运行在应用层之上的。不妨想一下，启动电脑快还是启动应用快？

传统虚拟机是通过虚拟化技术将底层的硬件虚拟化为硬件资源池，提供给上层的每个 VM （Virtual Machine，虚拟机）使用，让每个 VM 都认为自己是独立运行在物理机上的。

其后，每个 VM 又是运行的完整的操作系统，仅仅是操作系统+基础服务就需要占用较多的资源，而且这些资源是被 VM 独占的，不可被其他虚拟机复用。

虚拟机启动时，会锁定配置好的资源分配，如VM需要2c4g的基础资源，则会预先锁定，不让其他 VM 使用该资源

这种虚拟化架构实际就是寄居虚拟化，主要分三层：宿主操作系统（Host OS） -> 虚拟机监控程序（Hypervisor） -> 虚拟机（Guest OS），下面是对应的架构图，一个典型的应用就是我们熟知的 VMWare Workstation：

这就是传统虚拟机重的由来。

Docker 的轻量级也并不是因为他解决了这些问题，而是因为他另辟蹊径，不再去模拟一个完整的操作系统，而是基于 Linux 内核的 Namespace、Cgroups以及UnionFS技术，实现从系统级别的隔离转换到了进程级别的隔离，从架构层面抹除了硬件模拟和虚拟机操作系统的开销。

• Namespace 提供资源隔离机制：将 PID、Network、Mount、User 等资源进行命名空间层级的划分，不同的 Namespace 的进程无法互相访问到。
• Cgroups 进行配额限制：避免某一个进程组无限制的消耗资源，同时可以让空闲资源被释放。
• UnionFS 实现镜像分层复用：不同的镜像可复用底层镜像，减少存储的冗余。

这样一来，Docker 虚拟化的架构就变成了：

没有了 Hypervisor 和 Guest OS，同时由于 Docker 是基于 Linux 内核技术的，所以宿主操作系统也只能是 Linux。

Docker 与云原生

云原生本质是一种构建和运行应用程序的方法，是以 k8s 为代表的一套技术体系和方法论[3]。这套技术体系是由 “容器化技术、编排调度、服务治理、可观测性” 等技术组成，而其中的容器化技术是云原生的 “基础载体”。而 Docker 则是容器化技术的 “开创者与早期绝对主导者”，也是云原生的核心应用，他通过解决传统部署的痛点问题，使得以容器为基础去构建分布式应用成为可能，从而推动了云原生的普及落地，可以说，如果没有 Docker，那云原生可能发展的不会如此迅速，还需要等待另一个“Docker”技术来推动其发展。

此外，Docker 定义的容器镜像标准，也成为了云原生应用的一个交付载体标准。目前的云原生应用的 CI/CD 标准流程是：代码提交→自动构建 Docker 镜像→镜像推送到仓库→编排工具拉取镜像部署，可以看到，在这个过程中，镜像就是代码到运行时的中间载体，也是我们交付的一个产物标准。

目前 k8s （1.20 以后的版本）已经弃用了对 Docker 的直接支持，转为原生支持 CRI 标准的容器运行时，但是这并不代表着 Docker 已经过时，只是 k8s 从以 Docker 主导转变为了基于 Docker 标准，多工具的生态协同。

总结

Docker 不仅是一项技术创新，更重塑了软件产业的协作模式。Docker 将 Linux 内核的 Namespace、Cgroups、UnionFS 等技术封装成简单易用的工具链条，通过“镜像-容器 ”架构解决了传统部署的行业痛点问题，标准化了应用交付格式，为 k8s 等编排平台提供了基础载体，重塑了软件开发流程，实现“一次构建，到处运行”的理想态，推动了云原生的迅速发展。

未来，随着云原生技术持续演进，Docker 可能也不再是容器领域的唯一焦点，但其倡导的 "标准化、轻量化、可移植" 理念已深刻影响整个行业。无论是作为开发者日常工具，还是云原生基础设施的重要组成部分，Docker 仍会在上云浪潮中扮演关键角色。