"01-标准化打包技术.md",

相比盛极一时的：

- AWS


- OpenStack


- 以Cloud Foundry为代表的PaaS项目，却成当时云计算技术清流：


Cloud Foundry项目已基本度过最艰难的概念普及和用户调教期，开启以开源PaaS为核心构建平台层服务能力的变革。只是后来 **`Docker`** 横空出世，当时还叫**dotCloud**的**Docker**公司，也是PaaS热潮一员：


相比Heroku、Pivotal、Red Hat等PaaS新宠，**dotCloud**微不足道，主打产品跟主流Cloud Foundry社区脱节，**dotCloud**公司突发：开源自己的容器项目 **`Docker`**！！！显然，这决定在当时根本无人在意。“容器”概念从不是新鲜事，也非Docker公司发明。即使在当时最热门PaaS项目Cloud Foundry，容器也只是其最底层、最无人关注部分。

PaaS项目被大家接纳的主要原因是提供

当时主流用户普遍用法，租一批AWS或OpenStack的虚拟机，像以前管理物理服务器，用脚本或手工在这些机器部署应用。自然地，部署过程就碰到云端虚拟机和本地环境不一致问题。当时云计算服务，就是比谁能更好模拟本地服务器环境，更好“上云”体验。而PaaS开源项目出现就是当时解决该问题最佳方案。

虚拟机创建后，运维只需在这些机器部署一个Cloud Foundry项目，然后开发者执行一条命令就能把本地应用部署到云：

cf push "My APP"

因此，Cloud Foundry这类PaaS项目，最核心组件就是应用的打包和分发机制。

Cloud Foundry为每种主流编程语言都定义一种打包格式，“cf push” = 用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上Cloud Foundry存储。

接着，Cloud Foundry会通过调度器选择一个可运行该应用的VM，然后通知这个机器上的Agent把应用压缩包下载下来启动。

由于需要在一个VM上启动多个来自不同用户的应用，Cloud Foundry会调用os的Cgroups和Namespace机制，为每个应用单独创建一个“沙盒”隔离环境，在“沙盒”中启动这些应用进程。就实现多个用户的应用互不干涉在VM里批量、自动运行。

**这就是PaaS项目最核心的能力**。这些Cloud Foundry用来运行应用的隔离环境或者说“沙盒”，就是所谓“容器”。

而Docker项目本质和Cloud Foundry容器没啥不同，所以发布不久，Cloud Foundry首席产品经理James Bayer就在社区做详细对比，告诉用户Docker只是一个同样使用Cgroups和Namespace实现的“沙盒”，无黑科技，无需特别关注。

但Docker项目迅速崛起，如此之快，以至于Cloud Foundry及所有PaaS社区还没来得及成为其竞争对手，就直接出局。Docker项目确实与Cloud Foundry容器在大部分功能和实现原理一致，可偏偏就是这剩下的一小部分不一样功能，成为Docker项目之后“呼风唤雨”的宝术。

PaaS能帮助用户大规模部署应用到集群里，是因其提供一套**应用打包**功能。打包功能恰好成了PaaS日后不断遭到用户诟病的“软肋”。

一旦用上PaaS，用户须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这打包过程，无章法可循。更麻烦的，明明在本地运行好，却要做很多修改和配置工作才能在PaaS运行。而这些修改和配置，并无经验可借鉴，基本靠试错，直到摸清楚本地应用和远端PaaS匹配的“脾气”。最后就是，“cf push”确实一键部署，但为实现这一键部署，用户为每个应用打包工作一波三折，费尽心力。

就是解决打包这根本问题。Docker镜像就是个压缩包，但这压缩包内容比PaaS的应用可执行文件+启停脚本的组合丰富多了。大多Docker镜像直接由一个完整os的所有文件和目录构成，所以这个压缩包里的内容跟你本地开发和测试环境用的os一样。

假设你的应用在本地运行时，能看见环境是CentOS 7.2的所有文件和目录，那只要用CentOS 7.2的ISO做个压缩包，再把你的应用可执行文件也压缩进去，无论在哪解压这压缩包，都可得到与你本地测试时一样的环境。当然，你的应用也在里面！

这就是Docker镜像最厉害之处：有这压缩包，你就能用某种技术创建一个“沙盒”，在“沙盒”中解压这压缩包，然后运行你的程序。

更重要的，这压缩包有完整的os文件和目录，即包含应用运行所需所有依赖，所以你可先用这压缩包在本地开发测试，再把压缩包上传云端运行。在这过程，无需新增任何配置或修改，因为这压缩包赋予你极宝贵能力：**本地环境和云端环境一致**！这就是Docker镜像的精髓。

有Docker镜像，PaaS最核心的打包系统一下就无用武之地，最让用户抓狂的打包过程也消失了。当今互联网，Docker镜像需要的os文件和目录唾手可得。只要提供一个下载好的os文件与目录，然后使用它制作一个压缩包即可，这命令就是：

docker build "我的镜像"

一旦镜像制作完成，用户就能让Docker创建一个“沙盒”来解压这个镜像，然后在“沙盒”中运行自己的应用：

$ docker run "我的镜像"

docker run创建的“沙盒”，也是使用Cgroups、amespace机制创建出来的隔离环境。

直接打包应用运行所需整个os，保证本地和云端环境一致，避免用户通过“试错”匹配两种运行环境差异痛苦。

Docker项目固然解决应用打包难题，但并不能代替PaaS完成大规模部署应用的职责。可惜考虑到：

- Docker公司是一个与自己有潜在竞争关系的商业实体

- 对Docker项目普及程度错判

Cloud Foundry项目没第一时间使用Docker作为自己的核心依赖，去替换自己饱受诟病的打包流程。反倒一些创业公司都第一时间推出Docker容器集群管理开源项目（如Deis和Flynn），它们一般称自己为CaaS，即Container-as-a-Service，用来跟“过时”PaaS划清界限。

而2014年底DockerCon，Docker公司雄心勃勃对外发布自研“Docker原生”容器集群管理项目Swarm，将这波“CaaS”推向高潮，更寄托整个Docker公司重新定义PaaS的宏愿。

PaaS日渐深入人心，Cloud Foundry为首传统PaaS，开始蓄力基础设施领域的**平台化**和**PaaS化**，于是发现

Cloud Foundry/OpenShift/Clodify都没答案，走向碎片化歪路。名不见经传PaaS创业公司dotCloud却选择开源自研容器项目**Docker**。就这样一个平淡无奇技术，开启“Docker”新时代。

公司最重要战略之一：坚持**把“开发者”群体放在至高位置**。Docker项目推广策略从一开始就呈现出一副“憨态可掬”姿态，把每位后端技术人员（而非资本家）作为主要传播对象。简洁UI，有趣demo，“1分钟部署一个WordPress网站”“3分钟部署一个Nginx集群”，这种同开发者之间与生俱来的亲近关系，使Docker项目迅速成为全世界会议上最受追捧新星。

- 解决了应用打包和发布这一困扰运维人员多年的技术难题

- 第一次把一个纯后端的技术概念，通过友好的设计和封装，交到开发者手里

无需精通TCP/IP/Linux内核原理，一个前端或后端工程师，都会对如何把自己的代码打包成一个随处可运行的Docker镜像充满好奇和兴趣。

解决应用打包，同开发者与生俱来的亲密关系，再加上PaaS概念已深入人心的契机，成为Docker项目一炮而红重要原因。一个以“容器”为中心的、全新的云计算市场正呼之欲出，而作为这个生态的一手缔造者，此时dotCloud突然宣布将公司名称改为 Docker。

2014发布，虽通过“容器”完成对经典PaaS“降维打击”，但Docker项目和Docker公司还得回到PaaS项目原本躬耕多年的田地：如何让开发者把应用部署在我的项目？

Docker项目发布之初就全面发力，从技术/社区/商业/市场全方位争取到的开发者群体，为此后吸引整个生态到自家“PaaS”上的一个铺垫。**只是这时，“PaaS”定义已全然不是Cloud Foundry描述，而变成一套以Docker容器为技术核心，以Docker镜像为打包标准、全新“容器化”思路**。**这正是Docker项目一开始悉心运作“容器化”理念和经营整个Docker生态的主要目的**。

Swarm项目就是接下来承接Docker公司所有努力的关键。

- Docker镜像通过技术手段解决了PaaS的根本性问题

- Docker容器同开发者之间有着与生俱来的密切关系

- PaaS概念已经深入人心的完美契机。

2014年底的DockerCon欧洲峰会，才正式拉开Docker公司扩张序幕。