2.0.1 容器技术基础历史(1)

2013年 以Cloud Foundry为代表的开源PaaS项目，相比于AWS和OpenStack成为了当时的潮流。
dotCloud公司相比于Heroku，Pivotal，Red Hat等弄潮儿，由于与主流的Cloud Foundry社区脱节，长期无人问津，决定开源自己的容器项目Docker

PaaS项目被大家接纳的一个主要原因，就是它提供了一种名叫 应用托管的能力。
初期主流用户的普遍用法，就是租一批AWS或者OpenStack的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。
部署过程难免会碰到云端虚拟机和本地环境不一致的问题，所以当时的云计算服务，比的就是谁能更好地模拟本地服务器环境，能带来更好的上云体验
当虚拟机创建好之后，运维人员只需要在这些机器上部署一个Cloud Foundry项目,并执行

cf push my-application-name

像Cloud Foundry这样的PaaS项目，最核心的组件就是一套应用的打包和分发机制。
通过cf push，用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上Cloud Foundry的存储中，接着Cloud Foundry会通过调度器选择一个可以运行这个应用的虚拟机，然后通知这个机器上的agent把应用压缩包下载下来启动
由于需要在一个虚拟机上启动很多来自不同用户的应用，cloud foundry会调用操作系统的Cgroups和Namespace机制为每一个应用单独创建一个称作沙盒的隔离环境，然后在沙盒中启动这些应用进程。这样多个用户的应用互不干涉地在虚拟机里批量的自动运行起来。
Docker项目实际上跟Cloud foundry的沙盒容器并无不同，除了一点就是-Docker镜像。

Docker镜像是Docker项目作者Solomon Hykes的一个小小创新。却成为了横扫Cloud foundry的致命武器。

在Cloud Foundry中，一旦用上PaaS，用户就必须为每种语言，每种框架，甚至每个版本，维护一个打好的包。有些明明在本地运行好好的应用，却需要做很多修改和配置工作才能在PaaS里运行起来，cf push确实能意见部署，但为了实现一键部署，用户为每个应用的打包费劲心机。

Docker镜像解决的 恰恰就是打包这个根本性问题，相较于Paas的应用可执行文件 + 启停脚本的组合，
大多数的Docker镜像是由一个完整操作系统的所有文件和目录构成，所以这个镜像和本地开发和测试环境是一致的。
创建Docker镜像

docker build my_image

在沙盒中运行镜像

docker run my_image

2014年，dotCloud更名为Docker公司，开始发展Swarm项目，并在2014年底的DockerCon欧洲峰会上，正式拉开Docker公司扩张的序幕
最根本的目标，还是和原来PaaS一样，如何让开发者把应用部署在自家的项目上。