【原文编者的话】快速创新的迫切要求，使得 Uber 开始在服务部署中应用 Docker 。这篇文章讲述了部署方式的转变过程，强调在全面容器化之前，必须做充足的准备。
无论你对 Uber 的看法如何， Uber 无疑是创新的同义词，因为它在颠覆交通行业的同时***了共享经济。像Uber 这样的最快创新者，就像 Microsoft, Apple 和 Amazon 公司一样，都面临一个问题：一旦你开始创新并且取得成功，你不得不一直保持这样快的创新速度，这就导致了下面的后果：有时你看不到更远大的前景，有时会被途中的障碍绊倒。
今年初， Uber 发现自己就处于这样的境地。那时候，软件工程师 Casper S. Jensen 加入了 Uber 公司的计算机平台团队。
在 Dockercon EU 的***天， Jensen 说 Uber 应用有非常易用的用户界面，看起来就是一个简单的应用;“实际上 Uber 是一个非常非常复杂的产品”，“应用只是冰山之一角”，底层包含了无数的功能特性。要知道，目前 Uber 面对的是 69 个国家的不同市场和法律，每天安排百万次行程，有4,000 员工使用 Uber 平台。
以前的软件开发模式
那时候， Jensen 和团队中的其他四个人刚刚加入 Uber 不久。工作简直是“一团糟”，他们正在寻求一种解决方案。
这是去年冬天他们的开发流程：
- 编写服务 RFC(Request for Commments，请求评论)—— Uber 是一家极其依赖反馈的公司，在启动一项新服务时，他们首先描述该服务的架构和理念，发布到邮件列表中。
- 收集反馈——例如，“你们知道其他人也在做类似的事情吗?”——集中精力，力争在早期就找出错误。
- 手工列出该服务的所有依赖。
- 开始开发服务。
- 等待基础设施团队编写服务的依赖。
- 等待 IT 确定服务的位置。
- 等待基础设施团队提供服务。
- 部署到开发服务器，测试。
- 部署到生产环境的服务器。
- 监控迭代。
他说，步骤 5-7 “是特别特别令人痛苦的部分，很容易耗费数日乃至数周的时间。”原因何在?“到不是说这些步骤特别难，大部分环节我们都有相应的脚本，”只包括大约十行的集成代码。
“简单是简单，但是这些脚本的扩展性差，因为公司里只有少数人真正地知道如何扩展且不会破坏已有的部署”， Jensen 说。再加上一些小错误——例如，本来应该是连接线，结果写成了斜线——***导致所有的服务都慢得要命。
2015 年2 月，在一封内部邮件中，他们设置了下列目标：
Jensen 说他们想要做到：
- 允许服务的拥有者有专用的服务器切片，他们自行决定安装什么，我们不干涉，但是不能影响其它的服务。
- 并且，他们的安装过程也不用我们参与。
- 必须得有所改变了，还不能破坏现有的服务。
Uber 需要克服的自身问题
如果一家公司有如此快速增长的基础设施，自然会有一些限定，如 Jensen 所讲，“无论如何，我们必须保证基础设施快速增长，避免拖慢开发团队的高速开发流程”。
这不仅是因为 Uber 要求 7×24 的可用性以及支持无数的本地化特性，更重要的是，“没有任何一个人能够看到 Uber 的所有服务，每个人只能看到自己从事的部分。”他列举了几个特性，像 UberPOOL、UberKITTENs、UberIceCream 和 UberEATS，每一个都在“增加新功能，好像世界末日到了一样”。 Uber 的耀眼成功，是建立在全方位超快发展的基础之上的，包括数据中心、服务器和基础设施。需要找到保持增长的解决方案。
“我们希望有非常方便的流程和基础设施，这样开发者就能非常快地增加新功能。其中最重要的一个部分是创建新服务的流程，” Jensen 说，“我们意识到这不就是 要用 Docker 吗。”理由很简单，“很容易向别人解释 Docker 的作用，人们早就了解过它，理解基本的概念”。每个人都有自己喜欢使用的容器，因此开发团队很容易接受 Docker 。
容器带来的痛苦
他们心想，“我们都能写代码，这还不是小菜一叠?两天就能干完。”实际上不是那么回事。他们 2月份作出决定，直到仲夏，才真正用上 Docker 。
Jensen 解释说，用了 Docker ，“一切都有所改变，思路也必须随之转换。”
采用 Docker 的***障碍是 Uber 内部使用的集群管理系统 uDeploy 。它要能在支持回滚的前提下做持续的滚动升级。它包含很多报错的触发器，像健康检查或者发生故障时的图形化显示。它还支持有错就回滚的负载测试和集成测试。 uDeploy 包括：
- 每周 4,000 次升级
- 每周 3,000 次构建
- 每周 300 次回滚
- 管理系统包含的 600 多个服务
做不到完全不使用 uDeploy ，所以 Uber 团队决定同时部署旧有的服务和 Docker 服务。
“我为此花了很多时间，检查每一个功能，添加支持以便能够把它封装为 Docker 服务，” Jensen 说，“ uDeploy 支持显示标准输出和标准错误，我们必须在 Docker 中也实现这一点。”
他们在开始使用 Docker 时，没有那么多规划。后来 Jensen 意识到一开始给予开发者的自由度太大。“不应该这样，”他打了个响指，说：“你真的要考虑到基础设施的方方面面”。
Jensen 说，如果你提前做好规划，真正审视基础设施以及容器在其中的一小部分作用，结果就会好很多。
Docker 正在驱动一个全新的可扩展的 Uber
现在 Uber 大约有 1/3 服务是 Docker 化的，希望不久实现***的容器化。为什么?虽然转换的过程很痛苦，但是最终的结果符合期望，去掉了持续部署中的三个巨大的痛点。有了 Docker ，他们无需再：
- 等待基础设施团队编写服务的依赖;
- 等待 IT 确定服务的位置;
- 等待基础设施团队提供服务。
现在，他们不再手工编写或者复制以前项目的依赖定义，而是使用包含标准服务的配置和构建文件的工具，从而把服务提供时间从以前的几小时、几天缩短到现在的大约 10 分钟。
不仅如此， Uber 认识到， Docker 消除了团队之间的依赖，提供了更高的自由，因为不再绑定在特定的框架和版本。框架和服务的拥有者现在可以尝试新技术，管理自有的环境。
