容器是怎么一步一步成为云原生的基石技术的

本文来自公众号：申屠鹏会的笔记

欢迎关注交流～

现今，已经很少有技术从业者没听说过容器了，但放在 10 年前，也就是 2014 年前后，那时候后端技术领域可太不一样。今天，我们来聊聊容器技术的“登神长阶”。

在 2014 年，云计算已经是一项成熟的技术，以 AWS 为代表的云厂商，通过实实在在的虚拟机和账单完成了对用户的概念教育和普及。在这个时期，云计算通过对资源的抽象和整合，形成了三个层次为用户提供服务：

• IaaS（Infrastructure-as-a- Service）：基础设施即服务，包含计算服务器、网络、存储等基础设施，即用户可按需获得基础计算资源。

• PaaS（Platform-as-a- Service）：平台即服务，包含计算资源、操作系统、中间件、运行时、框架等服务，用户可按需获取用于开发、运行、维护和管理应用的资源。

• SaaS（Software-as-a- Service）：软件即服务，包含基础设施、软件（如电子邮件、工作流、在线设计等）等，为用户提供在线使用

  
  

用户使用云计算提供的各类服务基本可以归类为上述三种，比如在 AWS 上租用虚拟机、购买带宽资源，用脚本或手工的方式在这些机器上部署应用；而 PaaS 平台提供的解决方案通常包含了满足 DevOps 工具链的所有要求，可以满足应用的打包和发布；至于 SaaS，那可选产品更多了。

在那个背景下，很明显部署过程会出现本地环境和云端环境不一致的问题，所以 PaaS 平台是云计算发展的重要舞台，各个技术厂商比拼的就是谁能提供更舒服的“上云”体验，谁能更好地模拟本地环境。因此以 OpenStack、Cloud Foundry 为代表的开源 PaaS 平台，通过完善的应用打包和分发机制，让用户一行命令就能把本地应用部署到云上，因此被认为是时代发展的方向。

回头看的话，如果不是 Docker 突然冒出来的话，现在可能还是 PaaS 的时代。

初出茅庐

Docker 公司彼时还叫 dotCLoud，是一家 PaaS 浪潮中微不足道、且快被拍死在岸边的一朵浪花，主打产品和主流的 Cloud Foundry 社区格格不入，时任创始人的 Solomon Hykes 为了解决其产品在 PaaS 业务的困境，不得已在 2013 年 3 月宣布：开源其容器项目 Docker。

需要说明的是，“容器”这个技术并不是 Docker 公司发明的，在当时也不是一个新鲜的东西。如日中天的 PaaS 项目 Cloud Foundry 核心能力也是容器，为什么后来落寞了呢？让我们回到十年前看看。

Cloud Foundry 典型使用方法是这样的，用户创建好云端的虚拟机部署好 Cloud Foundry 后，本地应用只需要一行命令就能进行推送和安装。

cf push hello-world

它为支持的编程语言定义了一种打包格式，push 则是将本地应用文件以及启动脚本压缩打包上传到云端服务器的 Cloud Foundry 存储库中，随后 Cloud Foundry 的调度组件选择合适的虚拟机下载该压缩包进行解压和启动。

在这个过程中，由于一个虚拟机会启动不同的应用，Cloud Foundry 会利用操作系统的 Cgroups 和 Namespace 机制为每个应用创建“沙盒”环境，相互隔离，这样起到了不同应用运行在同一个虚拟机的目的。

而当 Docker 发布的时候，大家无非觉得又是一个碰瓷 PaaS 的项目，甚至 Cloud Foundry 产品经理就分享过一篇“Docker vs. Cloud Foundry”的文章，从架构（Architecture）、抽象层（Abstraction Level）、应用移植性（Application Portability）、伸缩（caling）、配置管理（Configuration Management）、生态系统（Ecosystem）全方面进行了对比，得出结论：Docker 无非是又一个使用 Cgroups 和 Namespace 技术的沙盒项目，实现原理大部分都一样，而 Cloud Foundry 提供了更高的抽象级别和更全面的平台，遥遥领先！

崭露头角

相信看到这里，大家会有些困惑，既然 Docker 的实现原理大部分一样，那凭什么挑战在 PaaS 耕耘多年的 Cloud Foundry，成为了时代的宠儿？

那就要从那小部分不一样的实现说起，这一部分，叫做：镜像。

历史上有太多前辈、技术公司想要解决环境不一致的问题了，前有 Java “write once run everywhere”，后有 Cloud Foundry 的"cf-push"。PaaS 当时的火热，就在于提供了应用的打包和部署功能，但偏偏这个打包是最糟用户诟病的。为了这一键部署，用户需要为每种框架、语言甚至每个应用版本维护一个打好的包，需要管理云上服务器的各项配置，才能让“可执行文件+启动脚本”的 PaaS 软件包成功运行，乃至有些企业出现了专业的配置管理角色。

而 Docker 镜像，解决的就是这个打包的问题。虽然它也是压缩包，但相比 PaaS 压缩包简单的内容，它包含了完整的操作系统和应用所有文件、脚本。举个例子，如果你本地开发环境使用的是 CentOS8.0 的操作系统，那么只需要打包时把这个操作系统和其上开发的应用压缩到一块，那么到其它地方解压，自然可以得到和当时一样的环境。

镜像——带来了宝贵的环境一致性的能力，就像三体中的二向箔，给 Cloud Foundry 带来了降维打击。每个用过 Docker 的技术人员好评连连，并加入了社区进行反馈和改进。短短发布后几个月，Docker 成为了市场里的新星，特性与改进以小时为进度更新，社区 Stars 数量更是高达了 4 千。而 Deis、Flynn 等容器管理项目更是推出了 CssS（Container-as-a-Service），与传统 PaaS 划清了界限。

茁壮成长

由于对技术方向的误判，Cloud Foundry 错失了将“沙盒”替换为 Docker 解决自己打包问题的机会，迅速走下了技术的舞台。

作为一个开发者，Docker 开启了一个对开发者非常友好的时代。Cloud Foundry 等传统 PaaS 项目通常服务于大企业，对于他们来说，“老板”才是服务的对象，至于开发者的牢骚，那不是问题的关键。

而 Docker，不管是 Logo、slogan，亦或是姿态，都是把开发者放在最高的位置（至少当时是这样）。他们深谙开发者对 PaaS 打包的厌恶，把简单做到了极致。不仅解决了打包和发布这一技术难题，还通过友好的封装交到了最广大的开发者手里，大家可以自由分享有趣的“镜像”，各类论坛到处充满了诸如“一分钟部署 Wordpress”、“一分钟启动 Mysql”等教程，促进了技术的传播。

PaaS 当然还在，不过此时已经变成了一套以 Docker 容器、镜像为核心的“容器化”思路。

但是 Docker 总归是一个简单的技术，Docker 公司也不满足于此。

如果 Docker 只是一个创建和启动容器的工具，那最终只会变成某个 PaaS 项目的幕后英雄。Docker 想走到台前。

2014 年 12 月，Andrea Luzzardi 在 DockerCon 上宣布推出了：Docker Swarm。它解决了单宿主机的问题，使得 Docker 集群可以作为一个虚拟的整体暴露给用户，Swarm 最大的特点是完全使用了 Docker API 来管理集群，用户创建容器时，Swarm 拦截请求，通过调度算法找合适的 Docker Daemon 运行容器。这个操作简单明了，受到了一时追捧。

一直到 15 年，Docker 走出了一个非常繁荣的生态，在容器编排（Container Orchestration)中，通过收购 Fig 项目，推出了 Docker Compose，通过 Swarm 和 Machine，重新定义了 PaaS。

这段时间，在这个鲸鱼周围创业公司数不胜数，在容器网络、存储、监控、CI/CD、UI 纷纷涌现优秀项目。

而这一年还有一件大事，那就是 Google 公司突然发力，正式宣告了一个叫“Kubernetes”项目的诞生。

尾声

在那个繁荣的三年时间里，Docker 已经从开源产品逐渐变成一个商业项目，Docker 公司终于从屠龙的勇士成为了恶龙本身。众多初期的支持者纷纷决裂，包括 CoreOS、RedHat、微软、谷歌等。Docker 公司强硬的态度遭致了社区越来越多的不满，终于在 2015 年 6 月，Docker、Google、CoreOS 等公司共同宣布，成立 RunC 项目，交由中立的基金会管理。

之后各家以 RunC 为依据，制定了容器和镜像的标准和规范，也就是 OCI（Open Container Initiative）。

很显然，故事还没结束，今日的市场格局和 15 年远远不同，且听下回分解。

交流问题

大家是什么时候接触云原生技术的呢？

如果你是当时（2014 年）Docker 的决策者，你会如何平衡容器的开源和商业化进程？