【Docker】1.容器技术发展史

文章目录1. Jail 时代 - 容器技术的鼻祖1.1 chroot 与进程隔离的萌芽 (1979)1.1.1 为什么要“改变根目录”1.1.2 进程隔离的萌芽1.1.3 致命的缺陷“越狱” (Escape)1.2 Jail 模式的演进FreeBSD 与 Solaris (2000-2004)1.2.1 从“锁住的房间”到“独立公寓”1.2.2 FreeBSD Jail 的三大增强1.2.3 为什么网络隔离是巨大的飞跃1.2.4 2004Solaris Containers 与“资源控制”的跃迁1.2.5 为什么说 Solaris 是“现代容器的前哨”1.2.6 历史的接力棒2. 云时代 - 技术的彻底引爆2.1 Google 的贡献cgroups 与 LXC 的诞生 (2006-2008)2.1.1 现代 Linux 容器的双剑合璧Namespaces 与 cgroups2.1.2 LXC 的诞生2.1.3 LXC容器技术的“第一次握手”2.2 Docker 的崛起从内部项目到行业标准 (2013)2.2.1 从“管理机器”到“打包应用”2.2.2 解决“在我的机器上能跑”的魔咒2.2.3 镜像仓库容器界的“应用商店”3. 云原生时代 - 竞争与标准的确立3.1 编排之战Kubernetes vs Swarm (2014-2015)3.1.1 容器编排3.1.2 两大阵营的对垒3.1.3 命令式 vs. 声明式3.1.4 K8s 的胜利3.1.5 战争的侧影CoreOS 与 rkt 的挑战3.2 标准化之路OCI、CNCF 与 CRI 接口 (2015-2017)3.2.1 为什么要标准化3.2.2 云原生的“宪法”与“联合国”3.3.3 繁荣的生态CNCF Landscape3.3.4 告别“特权”从 Docker Shim 到 CRI3.3.5 接口的统一CRI 的出现4. 总结4.1 从一家独大到生态繁荣4.1.1 为什么某些技术会“过时”4.2 总结4.3 思维导图1. Jail 时代 - 容器技术的鼻祖1.1 chroot 与进程隔离的萌芽 (1979)chroot (Change Root): 这是一个起源于Unix V7(1979年) 的系统调用和命令。它的核心作用是更改当前运行进程及其子进程的显式根目录/。一旦执行该进程就无法访问其新根目录之外的文件仿佛被关进了一个“监狱”Chroot Jail。想象你正在搬进一间合租房但你希望确保新来的房客无法窥探你房间以外的任何地方。在Linux操作系统的世界里这个“房间”的边界就是由chrootchange root命令划定的。1.1.1 为什么要“改变根目录”在默认情况下系统上的任何进程都可以看到完整的目录树包括敏感的系统配置文件。chroot的诞生最初是为了测试和系统构建但它无意中开启了**隔离Isolation**的大门。形象的比喻默认状态进程像是一个在整栋大楼里自由移动的人可以进入厨房、卧室、地下室。chroot后进程像是一个被限制在二楼的小房间里的人。对他来说二楼的房门就是他世界的终点新的“/”他甚至不知道地下室的存在。这种让程序“认为”某个特定文件夹就是整个世界的能力是现代Docker容器技术最基础的逻辑。1.1.2 进程隔离的萌芽虽然chroot并不提供网络或进程 ID 的完全隔离熟练的黑客仍可能通过特定手段“越狱”但它第一次在文件系统层面实现了“眼不见为净”。它是容器技术长征的第一步环境封装。诞生1979年Unix V7。核心重新定义进程的/路径。局限仅限文件系统隔离不具备现代容器的资源限制功能。为什么它只是“萌芽”chroot解决了容器化的第一个核心问题文件系统依赖的打包与隔离。但它缺少了现代容器的另外两根支柱资源限制它不能限制进程使用多少内存或CPU。完全隔离它的PID进程ID、网络栈和用户ID仍然是全局共享的。1.1.3 致命的缺陷“越狱” (Escape)对于拥有特权root 权限的用户或进程来说逃离chroot监狱其实并不复杂。这也就是为什么我们说chroot并不等同于现代的安全隔离。关于chroot的常见误解错误认为chroot是一个安全沙箱可以运行任何恶意程序。现实chroot仅隔离了路径名解析。如果监狱内的进程拥有root权限它可以通过再次调用chroot到一个子目录然后利用..(父目录) 相对路径不断向上跳转最终回到真正的系统根目录。此外chroot无法限制网络通信、进程间通信 (IPC) 或系统时间。一个在“监狱”里的进程仍然可以关闭整个系统的网络或者杀死监狱外的进程。1.2 Jail 模式的演进FreeBSD 与 Solaris (2000-2004)如果说1979年的chroot只是给进程关上了一扇门那么2000年发布的FreeBSD Jail则真正开始为进程建造一套“精装公寓”。1.2.1 从“锁住的房间”到“独立公寓”在chroot时代进程虽然被限制了目录但它还和房东共享同一个宽带网络栈、同一个户口本进程空间。FreeBSD Jail的出现改变了这一切。进化的比喻chroot (1979) 就像是把你锁在合租房的一个房间里。虽然你出不去但你依然能听到客厅里房东说话看到系统进程甚至能顺着共享的网线黑掉房东的电脑共享网络。FreeBSD Jail (2000) 就像是把你搬进了一套独立的公寓。你有自己的入户门文件系统隔离、自己的水表电表资源隔离雏形最重要的是你有自己独立的电话线和信箱独立的IP地址。这种从“合租房单间”到“独立套房”的跨越标志着操作系统级虚拟化(OS-level Virtualization) 正式走向实用。1.2.2 FreeBSD Jail 的三大增强FreeBSD Jail在chroot的基础上引入了四个关键的隔离维度文件系统隔离继承自chroot但更加稳固。网络隔离每个Jail可以分配一个特定的IP地址。进程隔离Jail内部的进程看不到外部的进程甚至看不到其他Jail里的进程。权限隔离即便是Jail里的root用户其权限也被大幅削减无法执行装载内核模块等危险操作。1.2.3 为什么网络隔离是巨大的飞跃在FreeBSD Jail之前如果你想在一台物理服务器上运行两个Web服务器比如两个Apache它们必须监听不同的端口例如80和8080否则会冲突。有了Jail之后由于每个“监狱”都有自己的独立虚拟IP你可以在同一台机器上启动10个Jail每个Jail里都跑一个监听80端口的服务器它们彼此互不干扰。这在托管服务Web Hosting早期是一项革命性的技术。核心价值FreeBSD Jail第一次实现了让多个相互不信任的用户安全地共享同一台物理服务器的内核。这直接启发了后来Solaris Containers的诞生也为现代云主机的概念铺平了道路。问题那么为什么在那个带宽昂贵、服务器性能有限的年代“给每个隔离环境分配一个独立IP地址”为什么对早期的互联网服务商ISP来说是极具吸引力的在那个年代如果要在同一台物理服务器上为不同客户提供Web托管没有独立IP意味着所有客户必须共享同一个IP和端口或者被迫使用复杂的虚拟主机Virtual Hosting配置。有了FreeBSD Jail带来的网络隔离ISP可以像租公寓一样给每个客户分配一个“独立门户”的IP既方便计费管理又让客户觉得安全可靠。1.2.4 2004Solaris Containers 与“资源控制”的跃迁如果说FreeBSD Jail解决了“住得独立”的问题那么2004年发布的Solaris Containers (Solaris Zones)则解决了“用得公平”的问题。这是容器进化史上又一个里程碑。1.2.5 为什么说 Solaris 是“现代容器的前哨”Solaris Zones它是Sun Microsystems在Solaris 10中引入的一项技术。它不仅实现了像Jail那样的命名空间隔离还首次大规模引入了**资源管理Resource Management**概念。在此之前如果一个隔离环境里的进程“发疯”疯狂占用CPU或内存其他隔离环境会跟着倒霉。Solaris引入了两个划时代的改进Zones区域将系统划分为多个虚拟实例。Resource Pools资源池你可以明确规定Zone A最多只能使用2颗CPU和4GB内存。实际应用场景在Solaris时代企业可以将数据库、Web服务器和邮件系统分别跑在不同的Zones里。如果Web服务器遭受DDoS攻击导致流量激增Solaris的资源控制会确保它不会抢走数据库运行所需的CPU资源。这种**“既隔离视图又限制食量”**的做法正是现代Docker使用的Cgroups技术的灵感来源。1.2.6 历史的接力棒到2004年为止容器技术的基本形态已经具备了文件系统隔离 进程/网络隔离 资源限制。然而这些技术当时都局限在Unix系统FreeBSD,Solaris中而大洋彼岸的Linux社区正处于“大乱斗”阶段试图将这些思想移植到Linux内核中。FreeBSD Jail (2000):实现了OS级虚拟化引入了IP和进程空间隔离。Solaris Containers (2004):引入了Zones和资源池实现了细粒度的CPU/内存控制。重要意义它们证明了不需要昂贵的硬件虚拟化Hypervisor也能实现高效的服务器切分。2. 云时代 - 技术的彻底引爆2.1 Google 的贡献cgroups 与 LXC 的诞生 (2006-2008)在2000年代中期当大家还在讨论如何虚拟化整台机器时Google内部已经面临一个巨大的挑战他们拥有成千上万台服务器需要运行无数的搜索请求、爬虫和数据处理任务。Google并不想为每个小任务都启动一个沉重的虚拟机他们需要一种极轻量的方法来管理资源。这就是Google内部著名的Borg系统而为了让Borg更好地工作Google的工程师们开始向Linux内核贡献核心代码。cgroups (Control Groups):最初由Google工程师在2006年提出当时叫Process Containers其核心作用是限制、记录和隔离进程组所使用的物理资源如CPU、内存、磁盘I/O等。2.1.1 现代 Linux 容器的双剑合璧Namespaces 与 cgroups要理解现代容器如Docker的工作原理只需要记住这两个核心组件。我们可以用一个形象的比喻来区分它们“望远镜”与“仪表盘”Namespaces(命名空间) —— 系统的“望远镜”它决定了进程能看到什么。当你戴上特定的“望远镜”你只能看到被允许看到的进程PID、网络接口和文件系统。这解决了“隔离”的问题。cgroups—— 系统的“仪表盘/调节阀”它决定了进程能使用多少资源。它像水表的读数器和限流阀限制你最多只能用10%的CPU。这解决了“分配”的问题。有了这两者的结合Linux才真正具备了构建“容器”的能力。这种通过组合内核原生功能来实现虚拟化的方式比传统的硬件仿真要高效得多。2.1.2 LXC 的诞生2008年LXC (Linux Containers)项目应运而生。它是第一个通过组合Namespaces和cgroups提供的完整容器方案。在Docker出现之前LXC是Linux世界上最成熟的容器技术它让普通用户也能像使用FreeBSD Jail一样在Linux上轻松创建隔离环境。核心逻辑Namespaces负责变魔术让进程以为自己拥有整台计算机。cgroups负责当管家确保进程不会因为贪婪而拖垮整台计算机。2.1.3 LXC容器技术的“第一次握手”在Google贡献了cgroups之后Linux内核终于凑齐了构建容器的两大积木Namespaces cgroups。2008年诞生的LXC (Linux Containers)就像是把这些积木拼成房子的第一个施工队。首次合体LXC是第一个将内核零散的隔离功能封装成用户友好界面的工具。系统级容器LXC的初衷是提供“轻量级的虚拟机”。它的管理方式非常像传统虚拟机你需要SSH登录进去、安装软件、配置服务。LXC的“机器思维” vs. 现代容器的“应用思维”如果你用LXC部署一个网站你的感觉是租了一台很小的、启动很快的电脑。你得在里面手动配置Apache和数据库。这种模式虽然比虚拟机高效但依然没有解决“在我的机器上能跑在你的机器上跑不起来”的经典部署难题。思考虽然LXC已经很强大了但它在当时并没有像现在的Docker这样火遍全球。原因很简单它还是太像一台“小电脑”了。你认为如果要把LXC这种“轻量级虚拟机”变成某种能让全世界开发者疯狂、点一下就能在任何地方运行的神器还需要解决什么关键问题答案要让技术真正爆发必须解决“标准化”和“分发”的问题。2013年Docker的出现彻底改变了游戏规则。2.2 Docker 的崛起从内部项目到行业标准 (2013)在Docker出现之前LXC就像是给你提供了一个空的集装箱但里面的货物怎么摆放、怎么固定、到了目的地怎么卸货全得靠你手写复杂的脚本。2.2.1 从“管理机器”到“打包应用”Docker的核心突破在于它完成了一个思维转弯不再试图模拟一台“轻量级电脑”Machine-centric而是专注于如何打包和运行一个“应用”App-centric。Docker镜像 (Docker Image)这是Docker最伟大的发明。它不仅包含你的代码还包含了运行代码所需的所有环境库、配置、环境变量、甚至是操作系统底层的根文件系统。“标准化集装箱”比喻在没有标准化集装箱之前码头工人需要处理散装的木桶、布袋和板条箱效率极低。Docker就好比发明了标准的集装箱统一规格无论里面装的是钢琴还是煤炭外面看起来都一样。环境自洽集装箱内部已经布置好了支架依赖库货物在里面很安全。随处运行只要码头有吊车Docker Engine这个箱子在上海港和伦敦港都能以同样的方式卸载和运行。从散装部署到标准化集装箱2.2.2 解决“在我的机器上能跑”的魔咒在Docker之前开发环境和生产环境的差异是程序员的噩梦。LXC虽然提供了隔离但它没有定义如何“搬运”这个隔离环境。思考作为一名有经验的开发者你一定遇到过这种窘境“代码在我电脑上明明是好的为什么部署到服务器上就报缺少库文件或者版本不对”结合刚才提到的“集装箱”概念你觉得Docker镜像是如何通过技术手段彻底终结“在我机器上能跑It works on my machine”这个问题的正所谓“环境即代码”。Docker镜像的核心价值就是将原本松散的软件、库依赖、系统配置全部封装进一个不可变的二进制文件中。这种一致性带来了一场工程革命。在Docker之前部署一个应用可能需要一份长达20页的“部署文档”而现在只需要一个镜像ID。环境一致性镜像包含了从底层操作系统库到顶层应用的完整文件系统。这意味着开发、测试和生产环境使用的其实是同一个文件。配置解耦镜像虽然是不可变的但Docker通过环境变量和挂载卷让应用在保持代码版本一致的同时能够灵活适配不同的运行环境。版本控制镜像可以像代码一样打标签Tag。你可以轻松回滚到v1.0或切换到v2.0而不用担心系统里残留了旧版本的依赖污染。Docker Image的三板斧分层存储 (Layered FS)镜像是由一层层只读层叠加的。如果你有10个Python应用它们可以共享同一个Python基础镜像层极大地节省了空间。不可变性镜像一旦构建完成就是只读的这保证了你在开发机上测试的每一个字节到了生产服务器上都一模一样。REST APIDocker提供了一套极其简单的命令行工具和API让原本复杂的内核操作变成了简单的docker run。2.2.3 镜像仓库容器界的“应用商店”如果只有镜像而没有分享Docker顶多是个好用的本地工具。Docker成功的另一半功劳属于Docker Hub (Registry)。全球化的分发网络正如程序员习惯于从GitHub获取代码Docker Hub让开发者可以像下载App一样下载官方维护的数据库MySQL、中间件Redis或运行环境Node.js。这种“开箱即用”的能力极大地缩短了从想法到上线的时间。3. 云原生时代 - 竞争与标准的确立3.1 编排之战Kubernetes vs Swarm (2014-2015)如果说Docker发明了完美的“集装箱”让单个应用的打包变得极其简单那么接下来开发者们立刻撞上了一堵墙规模化Scale。3.1.1 容器编排在开发环境里你只需要docker run启动一两个容器。但在真实的生产环境中情况会变得异常复杂。舰队指挥官类比想象你现在不仅有一艘装载货物的货船Docker容器你拥有一支由100艘货船组成的庞大舰队调度问题哪艘船还有空位可以装新货哪台服务器CPU还没满自愈问题如果一艘船在海上沉了谁来立刻补上一艘一模一样的船扩容问题突然货物暴增如何快速增加50艘船通信问题船与船之间怎么在公海上高效喊话而不至于互相撞上这种管理“集装箱舰队”的技术在计算机领域被称为容器编排Container Orchestration。3.1.2 两大阵营的对垒2014年前后市场上出现了两种截然不同的编排思路Kubernetes (K8s)由Google开源源自其内部运行了十多年的集群管理系统Borg。它天生就是为了大规模、复杂的生产环境设计的。Docker SwarmDocker公司推出的原生编排工具。它的设计哲学是“极致简单”让你像使用Docker一样使用集群。Kubernetes的“降维打击”Google意识到单纯靠“简单”是解决不了大规模系统问题的。因此K8s引入了许多超前的概念声明式API你不需要下令“去启动一个容器”而是告诉K8s“我需要一直保持有3个Web服务在运行”剩下的脏活累活全由 K8s 自动完成。PodK8s不直接管理容器而是管理Pod容器组这解决了多个紧密关联容器如应用和日志插件的共享资源问题。思考试想一下如果你现在负责一个像淘宝双11那样的系统后端有1000多个微服务容器分布在50台甚至更多服务器上。如果其中3台服务器突然断电宕机了靠人工手动手动ssh登录、手动docker run、手动配置IP去恢复业务你觉得最大的挑战会是什么答案“时间”在生产环境中就是生命线。手动恢复不仅慢而且在那种压力巨大的环境下极易出错这就是为什么我们需要从“命令式”转向“声明式”的原因。3.1.3 命令式 vs. 声明式手动操作甚至包括早期的脚本编程通常是命令式 (Imperative)的而Kubernetes成功的秘诀在于彻底贯彻了声明式 (Declarative)哲学。命令式 (Imperative)像一份食谱。你告诉系统第一步做什么第二步做什么例如登录服务器 A下载镜像运行容器。如果中途某步失败整个流程就断了。声明式 (Declarative)像一份合同。你只需要描述最终状态例如我需要有3个Web容器在运行而不需要关心它是怎么实现的。Kubernetes的控制循环 (Control Loop)K8s会不断检查“当前状态”是否等于“期望状态”。一旦你提到的那3台服务器断电当前状态变成了0K8s会瞬间秒级做出反应在健康的服务器上重新拉起容器这比人工响应快了无数倍。Kubernetes声明式控制循环3.1.4 K8s 的胜利2014-2015年间Docker Swarm凭借“和Docker命令一模一样”的简单易用性曾占据先机。但最终Kubernetes赢得了这场战争。Google的背书K8s继承了Google管理百万级容器的经验Borg系统天生考虑了大规模下的复杂场景。生态系统K8s开放了各种接口CNI网络、CSI存储吸引了整个IT界的厂商为其开发插件。解决问题的深度Swarm解决了“让容器跑起来”的问题而K8s解决了“让复杂的分布式系统在无人值守的情况下健康运行”的问题。小测验为了巩固理解你觉得在K8s中如果你想把Web服务的数量从3个增加到10个你最应该做的是什么A. 编写一个循环脚本连续执行7次docker run命令。B. 修改YAML配置文件中的replicas数值为10然后提交给K8s。C. 登录到新的服务器上手动安装环境并启动容器。D. 等待K8s自动发现流量增加并自动扩容虽然K8s能做到但这不是最直接的操作方式。答案B3.1.5 战争的侧影CoreOS 与 rkt 的挑战虽然K8s赢得了编排之战但当时Docker公司在容器运行时Runtime领域的垄断地位也引起了不安。2014年底CoreOS公司发布了rkt (Rocket)容器引擎公开挑战Docker。他们认为Docker变得过于臃肿不再仅仅是一个轻量的工具而是变成了一个庞大的平台。这次“反叛”的意义打破垄断rkt的出现证明了Docker镜像格式不应该是某一家公司的私产。推动标准化这次竞争直接促成了后来的OCI (Open Container Initiative)标准的诞生确保了不同引擎之间的兼容性。3.2 标准化之路OCI、CNCF 与 CRI 接口 (2015-2017)随着Kubernetes的崛起和CoreOS的挑战整个行业意识到一个巨大的隐患如果容器的格式和运行方式只由Docker一家公司说了算那么整个云原生世界就如同建立在沙滩上的城堡。3.2.1 为什么要标准化在2015年之前Docker的镜像格式和运行时Runtime是高度绑定的。如果你想用其他的容器技术可能就无法运行Docker的镜像。标准轨距类比想象一下如果每个火车站云服务商都铺设不同宽度的铁轨容器标准那么火车应用每到一个站就得更换所有的轮子甚至车厢。这会极大地限制贸易往来。标准化就是为了制定一套“全球统一轨距”让任何公司生产的“集装箱”都能在任何公司的“起重机”上装卸。为了避免被单一厂商锁定Vendor Lock-in在Google、Red Hat等巨头的推动下两大关键组织应运而生。3.2.2 云原生的“宪法”与“联合国”OCI (Open Container Initiative)负责制定底层标准。它规定了镜像应该长什么样Image Spec以及容器该如何启动Runtime Spec。CNCF (Cloud Native Computing Foundation)它是开源世界的“联合国”。Google将Kubernetes捐赠给了CNCF使其不再属于某一家公司而属于全人类。解耦公式通过引入CRI (Container Runtime Interface)接口K8s不再直接调用Docker而是通过一个标准接口与任何符合规范的运行时通信。这标志着Docker从“唯一选择”变成了“可选插件之一”。K8s与运行时的解耦架构3.3.3 繁荣的生态CNCF Landscape标准化带来的最大红利是生态的爆发。既然接口是统一的那么任何开发者都可以针对网络CNI、存储CSI、安全、监控等领域开发自己的插件并无缝集成到K8s中。OCI确保了“集装箱”本身是通用的。CNCF保护了K8s的中立性让它成为了云原生时代的操作系统。解耦现在的K8s甚至可以完全不安装Docker而是直接使用更轻量、性能更高的containerd。3.3.4 告别“特权”从 Docker Shim 到 CRI在Kubernetes诞生初期它其实是为Docker“量身定制”的。当时为了让K8s能管理Docker容器K8s代码库里专门写了一段代码来适配Docker这段代码被称为DockershimDocker垫片。Dockershim可以把它理解为一个“翻译官”。由于当时的Docker并没有一个通用的接口给外部调用K8s只能自己写一个翻译插件Shim把K8s的指令翻译给Docker听。但随着容器技术的进步出现了一个尴尬的局面Docker变得越来越臃肿它包含了很多K8s不需要的功能而其他优秀的运行时如CRI-O却因为没有“翻译官”而无法被K8s直接使用。3.3.5 接口的统一CRI 的出现为了彻底解决这个问题K8s社区推出了CRI (Container Runtime Interface)标准。技术解耦K8s不再直接服务于Docker而是发布了一张“招聘启事”只要任何运行时符合CRI标准就可以直接接入K8s。现状ContainerdDocker公司将自己的核心组件剥离出来捐给了CNCF。现在的Docker内部其实也是调用containerd。Dockershim的退役在最近的K8s版本中官方已经正式移除了Dockershim。这意味着K8s终于不再对Docker给予“特殊优待”而是要求大家统一使用CRI接口。解耦接口CRI与实现Runtime分离让基础设施更灵活。中立CNCF确保了没有任何一家公司能垄断容器生态。效率跳过Docker的复杂外壳直接使用containerd等运行时不仅降低了资源消耗也提升了系统的稳定性。4. 总结4.1 从一家独大到生态繁荣回顾过去容器技术的架构演进可以概括为从“单体式Monolithic”到“模块化Modular”的转变。瑞士军刀vs专用工具组单体时代2013-2015早期Docker就像一把功能齐全的“瑞士军刀”。它不仅负责构建镜像、运行容器还要处理网络、存储甚至集群管理。虽然上手简单但对于复杂的工业级生产环境如Kubernetes这把刀显得太重、太杂了。模块化时代2017至今现在的容器生态更像是一套“专业工具箱”。每个部件只负责一件事containerd专注于管理生命周期。runc专注于创建容器。CRI-O专注于适配Kubernetes。4.1.1 为什么某些技术会“过时”在这个演进过程中你会发现一些技术名词如DockerClient的某些功能或Dockershim逐渐淡出了视野。这并不是因为它们“坏”而是因为它们不再符合工业生产的效率需求稳定性的需求在生产环境中我们不希望重启一个镜像管理功能Docker Daemon会导致所有正在运行的容器也跟着重启。安全性的需求减少“单体”软件的体积意味着减少了潜在的攻击面。性能的极致像CRI-O这样的运行时去掉了所有不必要的“业余功能”专门为 K8s 优化性能更极致。架构演进逻辑技术总是沿着“先有功能实现Docker再有标准规范OCI/CRI最后实现插件化/模块化containerd/CRI-O”的路径前进。这保证了底层技术可以像更换零件一样被替换而上层应用不受影响。这种“分而治之”的架构思维是云原生生态长盛不衰的核心原因。思考既然Docker的很多功能已经被拆解了你觉得在现在的开发流程中Docker是否依然是不可替代的或者说你认为它的角色发生了怎样的转变答案Docker的角色从曾经的“容器化代名词”转变为了一种强大的辅助性开发工具。4.2 总结萌芽期 (1979 - 2000s)从chroot的进程隔离到FreeBSD Jails的早期容器化尝试人类开始了对“隔离”的探索。奠基期 (2002 - 2008)Google贡献了cgroupsLinux合并了namespaces。容器技术的“两块基石”正式在 Linux 内核中合龙。爆发期 (2013 - 2015)Docker横空出世通过镜像机制解决了“我机器上能跑”的经典难题随后Kubernetes开启了编排战争定义了现代分布式系统的蓝图。成熟期 (2017- 至今)随着OCI和CRI标准的确立容器技术从一种“黑科技”变成了像电力一样随处可见、标准化且模块化的基础设施。容器技术的演进史其实就是一部**“如何让隔离更轻量、让部署更标准、让系统更解耦”**的斗争史。每一次技术的“过时”本质上都是为了追求在生产环境中极致的稳定性与性能。4.3 思维导图