【原文編者的話】快速創新的迫切要求，使得 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 消除了團隊之間的依賴，提供了更高的自由，因為不再綁定在特定的框架和版本?？蚣芎头盏膿碛姓攥F在可以嘗試新技術，管理自有的環境。
京公網安備 11010502049343號