大话Docker（三）：Docker 和 Google Borg的渊源

首先我们需要知道，Docker是一个“箩筐”：
存储：Device Mapper、BtrFS、AUFS
名字空间：UTS、IPC、Mount、PID、Network、User
网络：Veth、Bridge、Iptables
Cgroups：CPU、CPUset、Memory、Device
安全：Capability、SELinux、Seccomp
……

Docker的诞生其实跟Google有很大的渊源：那年，Jeffrey Dean还是一坨老鲜肉。

众所周知 MapReduce 是现在通用大数据处理的理论基石，在Jeffrey Dean 提出这个模型后，Google 内部率先用这个模型在内部实现了大数据计算的统一模型。Jeffrey Dean 在2004年的 OSDI（Operating Systems Design and Implementation）会议上发表了 MapReduce 论文之后，Hadoop 按图索骥慢慢成为了开源界最为流行的大数据处理框架。甚至在后面，Hadoop 变成了一个生态系统，和Android 一起养活了一大批 Java 程序员。

据说国外的Java程序在饭前都祷告：

“噢，感谢伟大的Hadoop，感谢Android赐予我们食物，Amen！”
但和Hadoop不一样的一点是：Hadoop需要搭建专属的集群，而Google的MapReduce离线计算是和线上的业务是共享计算资源的。

首先说一下Google这么做的必要性：

绝大多数线上的业务的繁忙程度是和业务类型、用户的作息、地理位置相关的。
例如：在中国11.11是一个大日子，所有电商都拼了命的在搞促销，而在欧美国家与之相对应是圣诞节；传统的办法为了应对高峰期的流量往往要预备很多硬件资源备用，但这些资源在平时基本上是闲置状态。对于更新速度极快的IT设备来说，闲置就是浪费。
Google这样做的好处自然是能大大的提高计算资源的利用率。但之所以大多数公司没有这么做，是由于Linux Kernel对资源（CPU、内存、I/O）隔离设施的缺乏。谁也不愿意看到一个日志挖掘的任务导致线上业务宕机。

但Google毕竟是Google，Kernel不支持，那就改Kernel。于是Google的工程师就在Kernel里增加了一种可以做资源隔离的设施：Control Groups，再配合chroot实现了一套较为完善的机制来保证进程之间可以不互相影响。

作为这套系统的某后英雄之一的Borg就是Google内部的分布式计算调度系统，负责统一调度各种MapReduce的资源分配和线上服务。

当时Google之所以选择了这条路，也一定程度上是由于Xen、KVM这些虚拟化技术还不成熟。但即使后来外面的公司广泛的用Xen、KVM来做资源隔离，Google也并没有跟风，正是因为Google的这种方式省去了额外的Hypervisor和Guest OS的开销，可以达到更高的资源利用率。

Google几乎所有的机器都是混部的，在一台机器上，可能运行着不同jobs的tasks。根据Google在Borg论文里披露的数据：

Google的50%的机器运行了9个甚至更多的tasks；90%的机器运行着25个tasks，达到4500个线程。
当然Google也并不排斥KVM、Xen等虚拟化技术。对于外部运行在GAE（Google App Engine）和GCE（Google Compute Engine‎）上的代码，Google的做法就是让它们运行在虚拟机（KVM）上，KVM进程被作为 Borg 的 task 运行。也就是说，Borg 是作为下层的，KVM 运行在它之上。

资源隔离机制在 Google 内部使用的比较稳定了之后，就被毫无保留地贡献给了开源社区，并把它命名为 Cgroups。

Cgroups 出现后，Docker 所需要的各种原材料就齐备了：

2010年，几个雄心勃勃的年轻人怀揣1000万美元的融资在旧金山成立了一家做PaaS平台的公司，起名为 dotCloud。目标是做世界上最好的 PaaS，打败他们：

• Amazon AWS
• Google GAE
• IBM Bluemix
• RedHat OpenShift
• Microsoft Azure
• VMware Cloud Foundry
• Heroku
• ……

面对这些动辄千亿市值的大佬，前路之艰辛更与何人说。

在苦苦支撑了几年之后，公司业务始终不见起色。dotCloud 的创始人Solomon Hykes 决定把 dotCloud 的所有源代码开源来搏一把。 没想到，他们的核心引擎Docker 重现了当年 Linux Kernel 开源时的丰彩，获得了广大服务端程序员的追捧：“这个容器管理引擎大大降低了容器技术的使用门槛，轻量级，可移植，虚拟化，语言无关，写了程序扔上去做成镜像可以随处部署和运行，开发、测试和生产环境彻底统一了，还能进行资源管控和虚拟化。”

于是，dotCloud 迅速停下其它手中业务的开发，开始专心研发 Docker 产品和维护相关社区，过上了幸福而快乐的生活。后面甚至把公司名字都改成 Docker，2014年8月 Docker 宣布把平台即服务的业务 dotCloud 出售给位于德国柏林的平台即服务提供商 CloudControl，dotCloud 的历史告一段落，Docker 的序幕缓缓拉开。

运维自动化班 6 期火热报名中

课程概述：

理论结合实战，使学员既可掌握快速从零构建一套实用、完整、可扩展的运维自动化平台。
一
Django 基础

• Django 类视图
• Django 模型
• Django 权限
• Django rest framework
• Django视图综述及综合实战
  二
  SQL 自动化上线平台
• 手动VS自动的现状对比
• Mysql，Inception，SQLAdvisor 讲解
• 用户权限设计，执行流程梳理，平台登录双因子安全认证
• 敏感配置加解密实现，人员/数据库配置设计，整体代码实现
  三
  公有云管理系统
• 通过API对「Aws、阿里云、腾讯云、青云、百度云」管理
• 工单系统和云管理平台联动
• 后续展望：公有云账单、比价、资源监控
  四
  任务管理系统
• Ansible 简介及常用场景分析
• Ansible API 二次开发入门
• 基于Ansible Playbook API 快速实现任务管理系统
  五
  运维工单系统
• 工作中流程规范的设计思路
• 典型工单系统的实现原理 —— 状态机
  六
  代码管理系统及发布平台
• 基于 Gitlab + Jenkins + DevOps 平台实现 CI/CD 的设计思路
• 结合运维平台流程规范实现持续集成与交付
• 展望：结合 ELK 的日志分析平台，实现代码上线运维无人值守
  七
  赠送 SaltStack 二次开发视频
• SaltStack 快速入门
• SaltStack 数据系统
• SaltStack 远程执行
• SaltStack 配置管理
• SlatStack 管理实践
• SaltStack 实践案例
• SaltStack 常用 API 使用及源码剖析
• SaltStack 怎么和发布平台联动
  上课模式：
  网络直播班 线下面授班
  咨询报名：
  QQ(1)：979950755 小月
  WeChat : 1902433859 小月
  开课时间：12月24日（周日）
  课程大纲