談談 OpenStack 與 Docker 的落地方案選擇

一、OpenStack & Docker 綜述

時至今日，云計算已經從概念、評估而逐步進入了 Gartner 定義的復蘇期 （Slope of Enlightenment） ，逐步在企業中落地推廣。而云計算中熱門的兩個技術 OpenStack 與 Docker也早已是企業中不可或缺的技術話題，看看國內圍繞兩大技術的創業公司、技術Meetup、技術大會以及各聯盟組織就可見一斑。Google Trends 的趨勢曲線也印證了兩大技術的火熱情況：

圖 1 OpenStack & Docker Google Trends

先簡單回顧一下兩大技術的歷史和現狀：

OpenStack 起源于2010年7月的 Austin 版本，作為典型的云計算 IaaS 層的具體實現工具，在與當年的 OpenNebula、CloudStack 的血拼中脫穎而出。通過命名為 Nova、Neutron、Keystone、Glance 等各組件實現對裸機、虛機、塊存儲、對象存儲、文件目錄、網絡、負載均衡、防火墻等數據中心基礎架構的統一調度管理，目前已經發布到 M 版本，形成了較強的開源生態圈和產業鏈，同時也成為了國內企業開源私有云構建的事實首選。

Docker 起源于2013年3月的首版，是基于LXC為基礎構建的容器引擎，通過 Namespace 和 Cgroup 實現了資源隔離和調配，使用分層存儲來構建鏡像，這些特性實現了將 OS 和應用捆綁的方法，直接造成了整個玩法的變革，使得應用系統環境標準化、集裝箱化傳遞成為現實。 如果說 OpenStack 只能讓數據中心的架構師、系統網絡工程師興奮的話，那么 Docker 則是可以讓開發、測試、應用運維、系統網絡工程師都興奮的東西 （從曲線的熱度即可印證），同時隨著DevOps、CI/CD、微服務的火熱，Docker 正好是實現上述名詞的極佳載體。由于 Docker 本身是缺乏集群調度、管理、監控、服務注冊發現等集群化運行管理能力的，因此目前也存在三種主流的 COEs（Container Orchestration Engines） 容器調度引擎：原生的 Docker Swarm、Google 的 Kubernetes（Borg 簡化版）以及 Apache Mesos，這三種主流的 COEs 目前還在都還在發展中，下圖為 Google Trends：

圖 2 Kubernetes & Mesos & Docker Swarm Google Trends

二、OpenStack & Docker 的融合開源技術方案

Nova Docker

圖 3 Nova Docker 方案

該方案將容器像 VM 一樣操作，通過增加 Nova Docker driver，實現對 Docker容器的啟停、創建等常規 VM 的操作，可以通過 Docker save 方式將鏡像存放在 Glance 之中，該種方案很大的好處在于可以使用現成的 OpenStack Neutron 來管理網絡、實現租戶的資源配額、使用 Host OS（注：此處不等于 BareMetal ）等 OpenStack 的天然好處。然而缺點也明顯，沒法使用 Docker/COEs 帶來的更有價值功能，例如服務發現、端口映射等。國內某大型電商就使用的該方案。該方案是早期的集成方案。目前已經不在官方版本中。參考 https://wiki.openstack.org/wiki/Docker。

Zun

社區的新項目，6月剛剛起步。目標在于解決 Nova Docker 方案存在的問題，獨立于 Nova 之外實現 Docker 部署調度框架，自身實現與 Glance、Neutron、Cinder等組件的集成。然而并不實現對COEs的部署調度。該項目由國內民族 IT 企業社區活躍大神主導，參考 https://wiki.openstack.org/wiki/Zun。

圖 4 Zun方案

Heat Docker plugin

圖 5 Heat Docker plugin 方案

該方案不依賴于 Nova 的調用，而是通過 OpenStack 編排組件 Heat 進行編排調用，通過使用 Heat Docker plugin 在創建的 VM 上使用 Heat Templates 設定 Docker 的參數，這樣則可以使用 Docker API 提供的所有功能，缺點在于 VM 上使用 Docker，無法實現資源調度，需要較多的配置工作，無法實現規模集群管理 。參考 https://github.com/MarouenMechtri/Docker-containers-deployment-with-OpenStack-Heat。

Magnum

在14年的 Nove Docker 及 Nove Heat plugin 總是不夠完美的情況下，社區于15年3月推出了 Magnum 版本。通過管理 COEs，將 COEs 作為服務進行提供。同時在15年的官方白皮書中也再次發布了容器與 OpenStack 的未來：通過 Magnum 管理在 VM 及 BareMetal 上提供 COEs 的服務。

圖 6 OpenStack 與 COEs 的規劃，來源：OpenStack 白皮書

圖 7 Magnum 架構圖，

現在的 Magnum 的架構圖如上，目前對 Swarm、Kubernetes、Mesos 均可以支持。通過定義 Bay、Node、Pod 映射為 COEs 的集群、Pod 的實現，完成對 COEs 的部署調度，由 COEs 調度部署 Docker，可以理解成 COEs as a service 的實現。通過 OpenStack現有的 Heet、Nova、Heat、Neutron、Glance 和 Keystone 等組件實現租戶、編排、鏡像、認證、網絡等其他功能管理功能。 現有的方案還不能實現在 BareMetal 上的部署 。網絡方案一直是各種集成解決方案的重中之重，目前 Magnum 主要為通過與 COEs 的 Flannel 的 Overlay 方案，存在一定性能問題，同時由于現有 COEs 的網絡方案還存在多樣性和變數，因此存在需要多種驅動的逐一實現的問題。

不過畢竟 Magnum 是 OpenStack 官方主攻的容器集成方案，因此有大量的貢獻者在完善該項目，通過 Magnum 的 Blueprints 可以看到即將發布（10月）的 OpenStack Newton 版本將進行大量的更新，其中重要的在裸機上部署COEs將得到完全支持：

圖 8 Magnum Blueprints，

Kuryr

剛才提到了由于 COEs 網絡方案的多樣性與變數，因此社區專門孵化了 Kuryr 項目，該項目用于實現 Neutron 與 Docker/COEs 網絡的驅動映射工作，未來可成為 Magnum 網絡的選擇，實現容器網絡的功能性能加強。參考 https://wiki.openstack.org/wiki/Kuryr。

圖 9 Kuryr 架構圖，

Kolla

前面談到的方案均是 OpenStack 怎么與 COEs/Docker 結合，提供不同形式的混合負載給上層使用的需求，而 Kolla 則是用于實現 OpenStack 這個“龐大復雜“的管理工具自身的部署/升級/維護的。雖然 OpenStack 也有許多的自動化運維項目，如 Fuel、Ansible、Puppet 等項目，然而隨著 OpenStack 的日益發展和被管理的節點及環境日志擴張，在龐大的生產系統長期維護和運行一套/多套 OpenDtack（Day 2 Operations） 也會日漸成為嚴重的問題。而隨著容器化的發展，OpenStack 社區也想到自身使用容器進行部署將不僅解決上述問題，也證明自己充分擁抱容器的決心。

圖 10 Kolla 架構，

目前 Kolla 通過容器化絕大部分的 OpenStack 組件，并通過 Ansible 來實現配置自動化管理。實現 OpenStack 自身的容器化管理。未來也會逐步成為國內企業 OpenStack 的管理方案首選。參考 http://docs.openstack.org/developer/kolla/。

以上所描述的方案是無論是完美的還是有缺陷的，也無論方案現在是否熱門主流，對于在開源社區分享貢獻開源技術方案的個人或團隊都是值得欽佩與尊敬的。

三、落地方案的選擇

想要進行數據中心整體資源管理調度，實現裸機、VM、容器、LB、FW、Storage 等多層級服務，可以參考以下落地方案進行選擇：

OpenStack 與 Docker 都沒有部署

等 OpenStack Newton 版本出來再開始試用，也不需要等太久。那時 Magnum 將更成熟，且支持裸機的部署，同時 COEs 也都會有一定進展，可以更清晰的選擇 COEs。

已經部署了 OpenStack ，等不急 Newton 版本

OpenStack 的大版本生產升級本身就是個工程，因此 OpenStack 與 COEs 的部署建議從物理上分開，各自部署各，當然可以在前端 UI 上進行整合。在 newton 發布后進行遷移及升級評估，看是否能較無縫進行后端技術方案集成升級。

已經獨立部署了 COEs 其中的一種，是否還需要 OpenStack

OpenStack 最大的用處是實現整個數據中心基礎架構的管理，比如硬件服務器、存儲、負載均衡、SDN 硬件、防火墻等，已經有大量的軟硬件廠商與其實現了驅動集成，因此如果考慮的是整個數據中心的整體調度管理的話，則可選用OpenStack Magnum + COEs的方案。如果考慮的是上層的 PaaS 層的資源調度及管控以及 CI/CD ，則還是堅持只使用 COEs。

開源世界唯一不變的是變化，所以無論選擇哪種方式都必定會踩很多坑，需要做好充分的技術準備或者找到合適的合作伙伴，充分評估自己的需求及選擇合適的技術方案。

 

 

 

來自：https://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649691621&idx=1&sn=e22d91be5cc5563d50a95c11af41a357&chksm=88932a86bfe4a390c56b4ecc1a3e7c85973434c88d4dfaa3472645e93e78940441c65444585d&scene=1&srcid=0912HiTXxTtT3zh9jxJb3lt8&pass_ticket=feMF89%2FaWDCE9JaaqaPgdFCsVEJkwJB8UFygHgcGojQ%3D#rd