OpsFlow：一種面向DevOps的應用自動化部署引擎?

李 超 花 磊 宋云奎

（1.新華通訊社中國經濟信息社有限公司 北京 100803）（2.中國科學院軟件研究所 北京 100190）

1 引言

近年來，互聯網公司業務迅速擴展，用戶需求頻繁變化，傳統基于單體架構的軟件系統難以適應互聯網技術的快速發展。因此，微服務架構應運而生，將單一應用劃分成眾多規模較小、功能專一的服務。其中，每個服務對具體業務邏輯進行封裝構建，獨立運行于生產環境中，通過服務模塊之間的相互配合以對外提供服務［1］。微服務架構由于模塊自治性強，可以滿足互聯網應用變化快、模塊獨立更新的需求。但是微服務模塊數量眾多、交互復雜，增加了運維的難度與成本，如何應對微服務快速頻繁的更新與部署已成為微服務架構應用亟需解決的主要問題之一。

為了實現關注點或任務的分離，將微服務的開發測試和運行維護過程進行嚴格區分，使得不同項目組具有不同的目標與流程。開發人員的目標是快速將變更實現到生產環境，而運維人員的目標是保持生產環境的穩定，這成為快速頻繁發布軟件的障礙。開發和運維人員之間的協作通常通過手工進行，該過程低效且易錯，因此將更改應用、增加特性和修復錯誤實現到生產環境中需要投入大量的人力和時間。為了快速響應用戶需求以及微服務應用的不斷變化，軟件企業需要應對快速頻繁的微服務應用發布，填補開發和運營之間的鴻溝。DevOps是應對微服務應用開發與運維的新興技術，可以實現開發和運維兩個部門間的有效協作［2］。微服務應用實例不僅需要部署到開發環境以運行測試用例或者檢查更新代碼，也需要不斷部署和重新部署到生產環境以提供服務。由于應用會頻繁部署到不同環境，實現高效自動化的應用部署至關重要。同時，應用需要從簡單的開發環境到復雜的分布式生產環境無縫對接，部署邏輯需要具有可移植性。

DevOps社區提供開源工具（如Chef［3］，Puppet［4］，Ansible［5］）來支持部署過程自動化以實現軟件的持續交付；在中間件與應用層，可以獲取可重用的構件（如腳本、模板）以實現部署自動化；在基礎設施層，云計算平臺為應用按需提供底層物理資源自動化部署API。因此，本文結合各層次多種技術、服務和構件以應對各類微服務應用的部署問題，從而實現高效的微服務組件組合和自動化的微服務應用組件部署。本文面向DevOps，提出了一種高效動態的應用部署引擎OpsFlow，設計與實現了技術框架以自動生成OpsFlow，最后，通過實驗評價了生成OpsFlow的開銷，并且使用微服務應用的實例研究驗證了方法的有效性。

2 微服務應用自動化部署

2.1 應用自動化部署引擎OpsFlow

應用部署引擎OpsFlow目標是組合多種自動化部署技術以應對異構應用與部署環境，從而實現高效自動化的微服務應用部署。OpsFlow作為可移植可定制的部署邏輯包，為用戶或外部系統提供API以便于部署應用實例，同時也提供管理邏輯對已部署的某些應用組件進行擴展，具有以下功能：

1）為特定應用實例指定編程語言以生成可移植包，使得應用實例在本地主機開發環境、本地服務器測試環境、遠程云計算生產環境等不同的環境中運行；

2）生成可執行構件（如腳本、編譯程序）以實現“原子”部署操作，其實現形態是安裝和配置軟件包的部署腳本，或是通過調用云服務接口來使用虛擬資源的代碼；

3）編排多個部署可執行程序以形成云應用部署模板。部署可執行程序負責執行部署計劃，協調部署操作，并創建特定應用拓撲；

4）提供公開API以觸發部署計劃的執行或創建應用拓撲，如圖1所示API可以被用戶或外部系統調用，例如，高層調度器可以根據當前負載調用OpsFlow接口以創建更多應用實例。

圖1 OpsFlow系統架構

根據應用拓撲動態生成定制的OpsFlow引擎具有以下優點：

1）只包含實現部署操作所必需的部署可執行程序，具有較少的軟件規模、資源消耗和配置操作，以及較高的性能。

2）打包所需要的部署可執行程序，以自包含方式部署特定應用，彼此間相互獨立。由于不依賴于集中的中間件，避免了單一故障點，從而具有更高的可靠性。

3）使用開源生態系統提供的可重用構件（如Chef、Juju）自動生成部署計劃，實現部署可執行計劃的編排和執行，開發人員只需調用所需的API而無需手動開發粘連代碼。

2.2 OpsFlow部署引擎生成方法

OpsFlow的動態生成方法如圖2所示，分為設計、構建和運行等三個階段，遵循通用規范使用不同技術實現。

圖2 OpsFlow部署引擎生成方法

1）設計階段：創建和維護應用拓撲模型；根據基礎設施、中間件和應用組件選擇部署可執行程序，這些可執行程序可以定制開發，也可以使用現有構件（如Chef，Juju，fog，Jclouds）；將所需的部署可執行程序關聯到應用拓撲。其中，部署可執行程序，既可以獨立開發，也可以重用現有開源社區提供的構件。對于現有開源部署構件（如Chef Supermarket，Docker Hub），由于每個開源社區獨立維護存儲庫，并且提供有限的搜索能力，因此缺乏全面的知識，難以選擇合適的構件，本文通過整合知識庫的元模型來解決該問題。部署需求來自于應用拓撲，可以通過需求參考文件來表達部署可執行程序的需求以及與其他部署可執行程序的關聯。

2）構建階段：創建部署計劃，即部署可執行程序，編排所有必需的部署可執行程序，以創建特定應用拓撲模型的實例。部署計劃可以手工完成，也可以使用計劃自動生成技術，如使用BPEL引擎自動生成應用部署的工作流程；在創建部署計劃時，所有必需的部署可執行程序都已就緒，生成Ops-Flow部署引擎。

3）運行階段：生成可定制的OpsFlow引擎；根據建模的應用拓撲，提供API以創建部署計劃，并部署與管理應用實例；如果不需要部署和管理更多的應用實例，則終止OpsFlow引擎。

2.3 OpsFlow部署引擎生成框架

OpsFlow部署引擎生成框架如圖3所示，包括設計、構建和運行等三個階段，具體包括以下幾個組件。

應用拓撲模型的建模環境：建立和維護應用拓撲模型，并將所需的部署可執行程序關聯到這些拓撲模型中的組件和依賴項。

部署計劃產生器：動態自動生成部署計劃，能夠處理創建的應用拓撲模型。為了將建模環境與計劃生成器分離，本文使用基于標準的建模方法（如TOSCA［10］）。為了達到自定義目標而改進部署計劃，則需要提供相應的部署計劃開發環境，本文將Eclipse BPEL Designer作為BPEL工作流環境。

API生成器：生成部署可執行程序，隱藏和抽象實現的技術細節，創建通過API訪問的部署計劃，實現在不修改源碼的情況下包裝部署可執行程序。例如，如何調用可執行文件，如何傳遞輸入參數，以及如何收集輸出數據。如果涉及多個特定應用的部署可執行程序，手工為單個應用包裝可執行文件以實現API耗時費力，那么就需要自動化創建API。由于使用多種自動化技術來部署異構應用，需要手工修改與細化部署計劃。特別是，當使用工作流建模語言（如BPEL），集成各種技術非常復雜且容易出錯，因此，將這些技術特點及其調用機制封裝在API中，就可以使用HTTP等標準化通信協議來調用。部署計劃生成器不需要了解各種技術的調用機制細節，而只需了解如何調用API以支持自動生成部署計劃。

部署引擎包裝器：生成自包含的OpsFlow引擎，作為可移植可執行包，在運行時部署應用實例。API生成器和OpsFlow引擎包裝器都可以基于API化框架實現，比如 Any2API［11］。

OpsFlow引擎運行時環境：根據OpsFlow引擎的打包格式，使用API來部署和管理應用實例。同時，通過使用可移植的虛擬化方法，可用于在不同的環境中打包和執行OpsFlow引擎。

圖3 OpsFlow部署引擎生成框架

2.4 OpsFlow部署引擎生成框架實現

本文基于TOSCA實現了原型系統，其中的工具鏈用以應對可移植性和可擴展性，涵蓋了設計、構建和運行等三個階段。在設計階段，建模工具提供了可擴展的基于TOSCA標準的建模環境以改善可移植性。并且，使用Winery［12］實現應用拓撲建模，以管理不同類型的組件和依賴關系。

在構建階段，本文使用OpenTOSCA作為部署計劃生成器以動態為特定應用拓撲模型生成部署計劃，從而滿足應用拓撲的特定部署需求。對于常見的通用組件類型（如MySQL數據庫和Apache服務器），部署計劃生成器能夠自動生成部署計劃，而無需手工進行細化。

在運行階段，基于工作流建模語言（如BPMN或BPEL）生成的部署計劃，需要在構建時生成相應的API以暴露部署可執行程序所需功能，這些功能關聯到應用拓撲模型的組件和依賴項。本文使用Any2API框架生成這些API，例如，為部署可執行程序生成基于SOAP/WSDL的Web服務API，以支持在BPEL中實現的部署計劃，從而調用和處理底層的可執行程序。另外，當使用腳本語言（如Python或Ruby）與相關庫（rest-client）連接一起實現部署計劃時，生成基于RESTFul的Web API。由于生成的部署計劃也是通過調用API執行的，基于API的遞歸聚合可以支持眾多不同的拓撲模型。最后，Docker容器作為可移植的虛擬化技術在構建時使用Dockerfile包裝OpsFlow引擎，同時使用Any2API執行包裝操作。

3 實例研究

3.1 實驗環境

本文以典型的網上商店應用作為實例來分析應用部署所面臨的問題。圖4描述了網上商店應用架構，采用混合云部署方式，由左邊部署在Amazon EC2的應用和右邊部署在OpenStack的數據庫構成，以避免將敏感數據暴露給公有云服務提供商。PHP應用部署在Apache服務器以展示用戶界面并執行業務邏輯，數據庫采用MySQL主/從模式以提高應用的可伸縮性與高可用性。應用由不同組件構成，采用不同部署技術。其中，Web應用使用Unix Shell腳本部署，PHP模塊和Apache服務器使用Chef部署，Mysql數據庫使用Juju部署。同時，在基礎設施層（包括虛擬機和網絡配置）使用Fog部署，與云計算平臺（Amazon、OpenStack）通過API進行交互。

實現該應用部署涉及到多種類型的部署腳本和構件，需要考慮眾多技術細節和差異，除了特定應用的Shell腳本外，Chef和Juju都需要特定部署引擎支持。此外，應用拓撲以多云方式部署，即Amazon作為公有云服務提供者，而OpenStack作為私有云管理平臺。

通用的自動化部署框架（如 OpenTOSCA［6］，Terraform［7］，Brooklyn［8］）通過引入統一的元模型進行抽象以實現不同部署可執行程序的編排，使得不同方法使用相應的元模型，但需要手工對特定部署模塊進行適配開發而不能自動實現。同時，由于通用的部署引擎需要支持多種部署方法，通常是重量級模塊，維護復雜度高。

3.2 開銷分析

實驗使用三種公開的Chef cookbooks來部署Apache服務器、PHP運行時環境和MySQL數據庫，實現兩個Ruby腳本在Amazon EC2云基礎設施上部署虛擬服務器，使用Amazon關系數據庫服務（RDS）部署MySQL數據庫實例。

圖4 部署結構圖

該實驗系統部署在一臺虛擬機（4個2.8 GHz主頻64位的虛擬CPU，4 GB內存），使用Virtual Box Hyperviso，在Debian Linux容器中完成部署可執行程序的處理和調用。本文監測容器層的所有度量，關注部署可執行程序和API實現相關的度量，執行每個部署可執行程序20次（其中，10次有API實現，10次沒有API實現）。每組10次執行中的5次是初始執行（在干凈的部署環境中運行，而沒有執行任何操作），另外5次是后續執行。生成API實現的平均時間是構建階段的開銷，為8s～33s，其中包括檢索特定部署可執行程序的依賴項。由于對生成的API進行了簡化，運行時具有較少的執行時間和較小的內存開銷。此外，當直接使用簡單的部署可執行程序，編排組件會減少生成API實現的復雜性。因此，資源的總體消耗取決于所選的編配方式，同時可以復用API實現在不同的遠程環境中運行可執行程序，以減少大型運行環境的開銷。本文從設計、構建和運行等三個階段對應用部署開銷進行評估，實驗結果如下：

1）設計階段：生成API所需的時間，實驗結果如圖5所示；

2）構建階段：部署可執行程序所需時間，實驗結果如圖6所示；

3）運行階段：可執行程序運行所需內存，實驗結果如圖7所示。

圖5 生成API實現時間

圖6 部署執行時間

圖7 運行內存使用

4 相關工作

與傳統的通用部署引擎不同，OpsFlow在運行時不依賴于集中的中間件。論文［13］利用可擴展的通用部署引擎來部署和管理各種應用，通過減少生成定制引擎的步驟來減少構建時的開銷。與Ops-Flow相比有以下幾個缺點：1）通用部署引擎提供的API并不適合所有的部署場景，需要實現多種部署技術，具有較高的復雜性，因而難以維護和擴展；2）通用部署引擎通常采用集中式中間件，存在單點失效的問題，因此需要維護其可靠性。3）使用通用部署引擎通常需要領域知識，通過二次開發來包裝現有的API，從而實現多應用組件部署的編排。4）通用部署引擎不是專門針對給定的應用拓撲，因此運行開銷較高。Bootware［14］首先創建部署引擎，然后用其部署應用實例，該方法使用通用部署引擎，而OpsFlow是面向特定應用動態生成的部署引擎。論文［15］將不同類型的部署可執行程序轉換為基于TOSCA標準的構件，便于現有多樣化開源生態系統所提供內容的復用。該方法雖然能夠有效實現設計階段和構建階段的部署自動化，但是在運行階段需要通用部署引擎來部署和管理應用拓撲。云提供商提供了建模和編排工具［16］，同時提供了PaaS（Platform-as-a-Service）服務［17］，調用該服務可以部署和管理應用實例，而不需要顯式建模應用拓撲。文獻［18］提出了基于Xen的云平臺自動部署框架。文獻［19～20］提出了PM、VM和應用等三個層次的云應用部署的描述語言。但以上方法難以實現多云或混合云部署，將應用或部分應用自動化遷移到不同的提供者非常困難。同時，API是由提供者預先定義的，并且必須通過開發自定義的粘合代碼來手動包裝，因此不適用于特定部署場景。

5 結語

當前互聯網應用的用戶需求快速變化，高效自動部署技術是縮短軟件發布周期的關鍵。DevOps技術有助于實現快速自動化部署過程，通過不斷迭代交付微服務來縮短發布周期。本文面向DevO-ps，提出了一種高效動態的應用部署引擎OpsFlow及其生成方法，設計并實現了技術框架以支持所提出方法，最后，實驗結果表明，生成部署引擎具有較小的開銷。