私有雲的難處
——我們為什么需要 CloudEngine？
鄭昀 創建於2016/7/31 最后更新於2016/8/3
關鍵詞：
容器、Docker、OpenStack、虛擬機、私有雲、Mesos、配置管理、部署、發布
提綱：
- Docker+OpenStack，就夠了嗎？
- 累覺不愛的部署
- 你家的業務系統能DRP嗎？
- 大前提：配置管理規范
- 還要考慮什么？
現在，OpenStack 又回來了，與 Docker 並肩作戰。不管是容器化 OpenStack，還是 Docker 集群，做到這一步就解決問題了嗎？
Docker+OpenStack，就夠了嗎？
我們要的不僅僅是容器或虛擬機
我們都知道，Docker 實現的只是鏡像內部的小環境的一致性，它保證了一個應用程序在不同機器上運行時的一致性。
就我們之前持續經營了五年之久的 O2O 電商平台而言，首先它存在多條業務線：
- 團購
- POP 平台
- 電影訂座
- 網店通
- ……
其次，它打通了供應鏈管理的全鏈條，從商機管理，銷售行動管理，簽約，終端設備鋪設，……，到與商戶的資金結算，與銷售體系的佣金計算，與第三方支付的自動對賬，與流量渠道的佣金對賬，各種平台收費的核帳和攤銷等等，加上外圍技術支撐體系（如天機和鷹眼），里里外外大約近百個 Java 和 PHP 工程，每個工程都是集群。
這還不算上那些開源組件所需的集群，如 ZooKeeper，Redis， MyCat，Elastic Search，還不算上商業智能的那套體系。
所以才雲科技的張鑫說得對：
然而大中型企業用戶很快意識到，真正的難點在於如何保證“大環境”一致，即整個業務系統中眾多容器、組件、服務之間如何配置、互聯、依賴，如何保證開發、測試、生產環境能相互轉化、克隆等。這些環境和配置在容器概念之上，是容器自身無法解決的，只能依賴集群層面的管理工具。
是的，給你一堆虛擬機，給你鏡像庫和一堆容器，你仍然很難構建出能 Run 起來的業務系統。
累覺不愛的部署
環境維護傷不起
一線互聯網公司的技術團隊紛紛誇耀自己在生產環境發布的頻次。無疑，一天之內發布頻次越高，同時發布質量還很穩定，意味着技術管理水平越高超。
好吧，假定我們僅僅是每周發布一個常規版本（少則幾個工程，多則幾十個工程），每日可能有幾次 hotfix。那么在生產環境中，部署時間 30 分鍾 還是 2 小時，區別不大，畢竟部署是一次性的工作。
但對於開發聯調和測試來說，就完全不一樣。如果 1 分鍾就能完成一次部署，信手拈來，毫無心理負擔，可以測試驗證的東西，和幾個小時才能完成一次的部署，差異是巨大的。
說白了，分布式系統的線下環境維護，做過的人都知道，傷不起。
你家的業務系統能DRP嗎？
如何快速重建
何謂 DRP？
Disaster Recovery Plan，災難恢復計划是也。
2011年藝龍曾經因為 EMC 存儲設備故障而連續 27 個小時無法對外提供服務，在此之后他們做了相應的規范和開發，我去年看到一份資料說，藝龍可以在 30 分鍾內異地重建集群。此后適逢著名的攜程 5·28 停服 11 個小時的大事件，驚嚇之余我們啟動了 DRP 計划。
DRP 涵蓋的事務有：
- 代碼
- 配置
- 數據
DRP 面對的災難場景：
- 生產機房物理毀滅，或短時間內網絡不通（如光纜被挖斷）
- 線下機房毀滅
- 代碼庫備份，
- 鏡像庫（包括了基礎鏡像）備份，
- 分環境的配置管理（一個環境對應一套持久化配置中心），
- 運維層面的 CMDB 備份，
- 數據庫備份（跨機房數據同步），
- 在虛擬機和容器集群之上的集群管理工具
那 DRP 可能真的是水到渠成。
大前提：配置管理規范
配置與代碼分離
前面說過，給你 OpenStack 和 Docker，你也很難快速構建出可運行的業務系統，那該怎么辦？
首先我們要明白，要做到真正的大環境一致，必須將配置完全與代碼分離，這里的配置不僅僅是服務之間的 IP 地址/內部域名/自動發現，還包括不同環境下不同應用的配置參數等。
我們要求的是，線下測試環境測試通過的包（或鏡像），可以直接上預發環境，上生產環境，一路穿行沒有障礙。
我們不希望看到的是，不同環境需要打不同的包/鏡像。
因此，首先我們要一套環境對應一個持久化配置中心，與環境有關的參數都存儲在配置中心里。
其次，每個應用都有自己的配置模板，不同環境部署的應用默認繼承配置模板，人們可以通過集群管理工具（或配置中心的管理界面）對本環境配置做一些微調。
一定要能管到應用層面
自研的 Java/PHP 工程，中間件，開源組件，這些都叫“應用”。
我們在集群管理工具里，操作的對象是“應用”而不是裸機（當然你也能申請裸虛擬機）。
重要的是，將鏡像的構建與代碼庫的分支構建整合。
你自己的應用，應用的元信息里已經指定好了代碼倉庫地址，你本次只需要指定分支（一套環境對應一個分支，如測試環境對應於測試分支），選擇虛擬化技術（虛擬機還是容器），指定節點數量；
開源組件，比如你選擇構建一個 Redis 集群，你只需要選擇相應的鏡像，指定節點數量，微調下配置；
幾分鍾后一切成為現實，網絡已經配置好了，內部域名就位，你能立刻開始聯調測試，是不是很美好？
背后對應哪些事情？我們以阿里的 ACP 給應用分配虛擬機資源為例吧：
- 分配機器
- 服務器初始化
- 天網
- 創建安全掃描黑盒任務
- 添加監控
- 添加ssh
- 安裝ccbin
- 安裝httpd/jboss/tomcat/resin等
- 安裝jdk
- 安裝acc
- 初始化sharedata
- 下載代碼/鏡像
- 鳳蝶
- 下載額外流代碼
- 配置assert
- 獲取antx
- 初始化template目錄
- 初始化uiweb
- build
- 部署前自檢
- deploy
- checkservice
我們的應用申請容器資源，背后的步驟大致為：
- 發送容器創建請求
- 從 iDB（注：自研的數據庫自動化運維系統） 獲取數據源配置：這樣應用訪問哪些數據庫，用什么工程帳號，都自動解決了；
- 上傳配置（含要注入的環境變量）和 Dockerfile 至 Git
- 創建 Jenkins Job
- 從 TouchStone（注：自研的容器私有雲管理系統） 獲取配置
- 下載代碼
- 編譯
- 打包
- 構建 Docker 鏡像
- 鏡像上傳
- 部署信息結果處理
- Haproxy 配置文件生成
- Marathon 鏡像創建
- DNS 配置
- checkservice
- 容器創建結果返回
還要考慮什么？
大致想來，集群管理工具還需要解決：
- 灰度發布；
- 安全管理：如何在虛擬機和容器的基礎上做好安全檢測，就像上面阿里 ACP 的“創建安全掃描黑盒任務”之類的步驟一樣；
- ……
上面說了這么多，這個集群管理工具就是我們的 CloudEngine，之前我在《CloudEngine：大殺器如何煉成》里介紹過。
-EOF-
歡迎長按二維碼訂閱我的微信訂閱號『老兵筆記』
轉載時請注明“轉載自旁觀者-博客園”或者給出本文的原始鏈接。