背景

云計算在今天已經被絕大多數的企業所采用，具知名云服務廠商?RightScale 最近的調查顯示，已經有越來越多的廠商采用多云管理。客戶有太多的理由來選擇多云管理了，其中最大的原因莫過于采用單一的供應商，會導致被鎖定。因此，如何管理多云環境，并在多云的環境下進行自動化，正成為眾多企業的剛需，而在這其中，應用程序的管理顯得尤為的重要。進一步講，頗具挑戰的是創建一個一站式的應用管理平臺，來管理不同類型的應用程序，其中包括傳統的應用（或者稱之為單體應用，或者傳統的主從、分片、peer-to-peer 架構的企業分布式應用）、微服務應用、以及近來發展迅猛的 Serverless 應用等，OpenPitrix 就是為了解決這些問題而生的。用一句話來描述 OpenPitrix：

OpenPitrix 是一款開源項目，用來在多云環境下打包、部署和管理不同類型的應用，包括傳統應用、微服務應用以及 Serverless 應用等，其中云平臺包括 AWS、Azure、Kubernetes、QingCloud、OpenStack、VMWare 等。

微服務，即眾所周知的微服務架構，這是程序設計的必然趨勢，企業創建新的應用時選擇的主要方式。另外，開源項目 Kubernetes 已經成為事實上的編排平臺的領導者，其在自動化部署、擴展性、以及管理容器化的應用有著獨特的優勢。但是，仍然有大量的傳統遺留應用用戶想在毋須改變其架構的情況下遷入到云平臺中，而且對很多用戶來講，采用微服務架構，或者是 Serverless 架構還是比較遙遠的事情，所以，我們需要幫助這些用戶將他們的傳統應用遷入到云計算平臺中，這也是 OpenPitrix 很重要的一個功能。

在2017年3月27日，QingCloud 發布?AppCenter，一款旨在為傳統企業應用開發商和云用戶之間架設友好橋梁的平臺，該平臺最大的亮點在于其可以讓開發者以極低的學習成本就可以將傳統的應用程序移植到 QingCloud 中運行，并且具有云計算的所有特性，如敏捷性、伸縮性、穩定性、監控等。通常，一位開發者只需花上幾個小時就可以理解整個工作流程，然后，再花一到兩周的時間(這具體要取決于應用的復雜性)將應用移植到云平臺中。該平臺上線之后一直頗受用戶的青睞和夸贊，但有一些用戶提出更多的需求，希望將之部署到他們內部來管理他們的多云環境。為了滿足用戶的需求，QingCloud 將之擴展，即在多云的環境下管理多種類型的應用程序，并且采用開源的方法來進行項目的良性發展。

俗語有云："知易行難"，盡管 OpenPitrix 原始團隊在云計算應用開發有著足夠豐富的經驗，并成功的開發出了穩定的商業化產品：AppCenter，要知道，等待在前方的依然有很多困難要克服。OpenPitrix?從一開始就是以開源的方式來進行，并且在2017年的8月份在 GitHub 上創建了組織和項目，一直到2018年2月24日才寫下第一行功能代碼，在此期間，團隊的所有成員都在思考系統的每個關鍵點，這些討論的細節均可在 GitHub 上公開訪問。

以上便是 OpenPitrix 項目的來龍去脈介紹，接下來會解釋一些詳細的功能和設計細節。

主要的功能

OpenPitrix 所希望實現的功能包括以下內容：

• 支持多個云平臺，如 AWS、Azure、Kubernetes、QingCloud、OpenStack、VMWare 等等;
• 云平臺的支持是高度可擴展和插拔的;
• 支持多種應用程序的類型：傳統應用、微服務應用、Serverless 應用;
• 應用程序的支持也是高度可擴展的，這也就意味著無論將來出現哪種新的應用程序類型，OpenPitrix 平臺都可以通過添加相應的插件來支持它;
• 應用程序的倉庫是可配置的，這也就意味著由 OpenPitrix 所驅動的商店，其應用均是可以用來交易的;
• 應用程序庫的可見性是可配置的，包括公開、私有或僅讓某特定的一組用戶可訪問，由 OpenPitrix 所驅動的市場，每個供應商都能夠操作屬于她/他自己的應用商店。

用戶場景實例

OpenPitrix 典型的用戶場景有：

• 某企業是采用了多云的系統（包括混合云），要實現一站式的應用管理平臺，從而實現應用的部署和管理；
• 云管平臺（CMP）可以將 OpenPitrix 視為其其中一個組件，以實現在多云環境下管理應用；
• 可以作為 Kubernetes 的一個應用管理系統。OpenPitrix 和 Helm 有著本質上的不同，雖然 OpenPitrix 底層用了 Helm 來部署 Kubernetes 應用，但 OpenPitrix 著眼于應用的全生命周期管理，比如在企業中，通常會按照應用的狀態來分類，如開發、測試、預覽、生產等；甚至有些組織還會按照部門來歸類，而這是 Helm 所沒有的。

架構概覽

OpenPitrix 設計的最根本的思想就是解耦應用和應用運行時環境（此處使用運行時環境代替云平臺，下同），如下圖所示。應用程序能夠運行在哪個環境，除了需要匹配 provider 信息之外，還需要匹配應用所在倉庫的選擇器 (selector) 和運行時環境的標簽 (label)，即當某個最終用戶從商店里選擇了某個具體的應用，然后嘗試部署它時，系統會自動選擇運行時環境。如果有多個運行時環境可以運行此應用的話，則系統會彈出相應的對話框來讓用戶自行選擇，更多設計細節請參考?OpenPitrix 設計文檔。

應用程序倉庫子系統

如上面架構概覽圖所示，倉庫子系統分為三大組件：倉庫管理 (Repo Manager)、倉庫索引 (Repo Indexer)、倉庫存儲 (App Repo)；其中倉庫管理包括倉庫服務 (Repo Service) 和其后端的數據庫 (Repo DB)，架構圖如下所示。用戶創建應用倉庫時需配置的信息如：URL、憑證、是否可見等，通常是系統管理人員或開發者為平臺創建倉庫。倉庫索引的守護進程會周期性地掃描新增的倉庫、現有倉庫的任何更新，并將信息更新到應用管理服務的數據庫中。我們可以看出，倉庫的存儲是獨立于特定的 OpenPitrix 平臺的，所以，倉庫存儲的應用可以共享給任何基于 OpenPitrix 的應用管理平臺使用。更多設計詳情請參考?OpenPitrix 倉庫子系統設計。

由倉庫組織的應用，都可以作為獨立資產由基于 OpenPitrix 的商店來售賣。

如何將傳統的應用遷移到多云的環境

首先要申明的是，OpenPitrix 不會特別地去區分多云和混合云之間的差別，在本文中，在沒有特別提示的情況下，多云意味著多個云環境，無論它們是公共云還是私有云，還是來自相同或不同的供應商。

規范

很顯然，我們將大量借助 QingCloud AppCenter 的經驗來實現在多云環境下“云化”傳統應用，這其中包括規范在內。為了簡單起見，我們在這里展示了一個不完整的 ZooKeeper 云化規范版本，如下所示，完整版本請參考?AppCeneter 示例，該規范很容易理解，文件?cluster.json.tmpl定義了 ZooKeeper 集群信息，如名稱、描述、多少節點（每個節點的 CPU、內存、存儲、鏡像、生命周期等），雙花括號中的變量來自最終用戶從 UI 輸入的信息，這些變量是由文件config.json定義的。ZooKeeper 應用開發者將這兩個文件打包上傳到 OpenPitrix 平臺，最終用戶在部署應用的時候輸入必要的信息、點擊部署按鈕即可。這個應用程序包(還包含語言文件)如同鏡像是虛擬機的模板一樣，它是一個應用程序的模板，只是它相比鏡像更為的復雜罷了，因為它可能包括多個鏡像，而且要定義應用程序集群的整個生命周期，還有，它還要支持自定義的監控、健康監測等等更多的功能。正如我們所看到的，開發者將傳統應用移植到云平臺中除了幾個說明文件毋須任何的編碼。

cluster.json.tmpl for ZooKeeper

config.json for ZooKeeper

架構

整個系統中最具挑戰性的工作就是如何將上述的一套標準的傳統應用軟件包無需任何修改就能部署到多個云平臺中，因為傳統的應用均是基于虛擬機而非容器的。OpenPitrix 設計團隊經過了激烈的討論，最后總結出如下幾個原則：

• OpenPitrix 自身是可以部署到任何地方的。因此，該平臺必須支持最終用戶同時將應用程序部署到公共云和私有云中，這意味著 OpenPitrix 從架構必須支持能夠通過公共互聯網部署應用程序；
• 針對每個 IaaS 平臺供應商的架構是一致的；
• 最終用戶部署應用程序毋須任何麻煩的配置，這意味著對于最終用戶而言，一切都是透明的，例如元數據服務的初始化。

經過反復的討論后，我們提出了以下解決方案。首先解釋一下架構中出現的一些術語。

• Drone：該組件由 agent 和?confd?所構成，Confd 是自動配置 app 實例的守護進程，agent 負責和 Frontgate 的通信，例如來自最終用戶發來的指令。agent 也會負責根據應用的狀態啟動和停止 confd。Drone 是預先安裝到應用程序所在的每一個鏡像中。
• Frontgate：該組件包含 proxy 和 etcd，Etcd 是后端的存儲，存儲集群的信息包括集群名稱、描述、多少節點、由最終用戶發來的指令等。Proxy 連接 Pilot 和 Drone 的 agent，因為虛擬機是運行在 VPC 中，Pilot 無法和 Drone 直接進行通信，所以需要在它們二者之間設置一個 proxy。在有應用運行的 VPC 中會存在一個 Frontgate，這個 VPC 內的所有應用集群共享這個 Frontgate，這個 Frontgate 是當最終用戶第一次部署應用程序時，系統自動創建的，且 Frontgate 對最終用戶不可見。
• Pilot：接受來自集群服務的指令和信息的組件，如創建集群等，并可以傳遞指令給 Frontgate，它還接收來自 Frontgate 上傳上來的信息。

毫無疑問，工作流程很復雜。我們以部署一個應用程序為例來進行簡要的說明，一般步驟如下：

最終用戶發送請求到 API 網關，API 網關會將之轉發給相應的服務，如集群服務；

集群服務收到請求之后，將之放到 job 隊列，job 控制器收到后將其分解成 task，然后放到 task 隊列；

Task 控制器將 Task 從隊列中提出，然后去調用特定的云平臺 API，創建集群資源如主機；

集群服務同樣會給 Pilot 發送集群的元數據；

Pilot 轉發信息給 Frontgate 的 proxy，然后 proxy 會將信息注冊到后端的 Etcd；

應用程序鏡像內部的 Drone 的 Confd 會監測 etcd 的更新，然后自動更新應用配置；

最后，Drone 中的 agent 為用戶啟動應用。

整個流程，如下圖所示：

應用程序鏡像

正如上面所闡述的，傳統應用通常是部署到虛擬機中的，而微服務應用往往是進行容器化的。如果我們使用虛擬機來支持傳統應用部署到多云環境中的話，會遇到非常大的挑戰。這意味著應用的開發者或供應商在每一個環境中都需要上傳或創建鏡像，而這在現實中往往很難行得通，尤其是公有云供應商提供很多的 region 和 zone。鑒于此種情況，我們選擇了在虛擬機中運行容器的方式來解決此問題，可以建立集中的容器鏡像倉庫，需要運行時直接拉到云平臺中的虛擬機中即可。此種方式也有弊端，那就是在網絡不好的地方，拉容器鏡像就是一個大的問題，如果下載容器鏡像的時間過長，對于用戶的體驗和耐心都是極大的挑戰。要解決此問題，在每個云環境部署緩存或 mirror 是非常好的選擇。第二個問題是開發人員需要知道 Docker，這似乎不是一個大問題，因為在我看來，掌握 Docker 是當今開發人員的基本技能。

但是，我們依然需要支持直接在 VM 中安裝應用程序軟件，并將 VM 分發到每個云環境中，原因如下。

• 有一些應用需要定制化 Linux 內核；
• 開發者沒有掌握 Docker 技術，或者說因為額外的學習或開發成本，開發者并不愿意用 Docker 的方式將傳統應用移植到云環境中；
• 最終用戶沒有意愿去創建一個諸如 Kubernetes 這樣的容器編排集群去部署一個傳統應用，或者是用戶沒有 Kubernetes 環境。

在第一個版本中，會在虛擬機中使用 Docker 的方式來解決應用程序鏡像的分發問題，在下個版本中，將支持直接在 VM 中安裝應用程序軟件。

如何支持多種類型的應用

正如我們開始所說的，OpenPitrix 是支持多種類型的應用程序。當一個用戶開始部署一個應用的時候，系統會自動識別應用類型并選擇相應的插件去創建應用集群。我們用 provider interface 和 provider plugin 來支持不同類型應用以及將來可能出現的未知應用類型。系統目前有兩大類應用類型：基于虛機的和基于容器的，前者是支持傳統應用上云，這個我們已經在上一章節解釋過了，現在我們解釋一下 OpenPitrix 如何支持日益流行的基于互聯網規模的應用程序：微服務和 Serverless。對于 OpenPitrix 的第一個版本，沒有打算支持 Serverless，我們認為 Serverless 應用還沒有標準，而且也沒有看清楚誰將贏得最后的勝利。市場上沒有與其他主要供應商兼容的產品或服務。那么這樣的局面就是家家都是標準的制定者，所以，OpenPitrix 團隊決定第一個版本暫時先不支持將 Serverless 應用部署到多云環境, 并持續關注 Serverless 最新標準的進展。

另外，在容器的編排方面，開源項目 Kubernetes 已經贏得了勝利，因此，OpenPitrix 會支持 Kubernetes。Helm?是一個非常不錯的 Kubernetes 包管理器，在第一版 OpenPitrix 中，我們使用 Helm 作為 Kubernetes 應用程序的部署工具，在下一版或許會直接采用 Kubernetes 的應用編排格式。

如下圖所示，我們將 Helm 的客戶端打包到 OpenPitrix 中，另外 Helm 的服務端組件 Tiller 也會作為 OpenPitrix 的組件，這樣作為 OpenPitrix 的最終用戶，根本就不需要學習任何關于 Helm 的內容，就可以將應用部署到 Kubernetes 中，然而，在撰寫本文時，Helm 服務對于 Kubernetes 多集群的管理還尚待改善，詳情見 issues?1586和1918，因此，在問題解決之前，我們會要求用戶將 Tiller 安裝到每個 Kubernetes 集群中。當最終用戶配置 Kubernetes 集群時，系統將自動配置并測試 OpenPitrix 和 Kubernetes 集群之間的連通性。然后，用戶就可以將 Kubernetes 應用程序部署到任意集群中了。

總結

我們規劃未來的 OpenPitrix 會增加更多的功能，例如：

• 針對開發者的工作臺，可以讓開發者在此以極簡的方式開發應用；
• 開發者可以查看使用其應用程序的所有狀態包括統計信息；
• 計量計費功能
• 各種報表功能
• ......

OpenPitrix 將會逐步發展為多云環境下應用程序管理系統的全方位的解決方案。

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術人生

總結

以上是生活随笔為你收集整理的OpenPitrix 是一款开源多云应用程序管理系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。