面向云服務的DevOps知識獲取與應用①

陳詠秋, 張 斌, 徐明珠, 顧永生

(江蘇電力信息技術有限公司, 南京 210024)

面向云服務的DevOps知識獲取與應用①

陳詠秋, 張 斌, 徐明珠, 顧永生

(江蘇電力信息技術有限公司, 南京 210024)

DevOps作為一種新興范型能夠實現開發和IT運維之間的高度協同, 從而在完成高頻率部署的同時, 提高生產環境的可靠性、穩定性、彈性和安全性. DevOps與云計算一起能夠實現資源的按需供給. DevOps制品和云服務的規模不斷增長, 大量的DevOps知識分散在不同的社區和來源中, 沒有得到有效的組織、管理和使用, 如何針對大量可選的DevOps方法和工具進行有效的決策和選擇成為亟待解決的問題. 針對這一問題, 提出了一套完整的DevOps知識管理方法. 方法首先針對一組可訪問的知識源進行多種方式的知識獲取、組織、轉換和存儲;然后提出了DevOps知識分類方法, 并設計實現了DevOps知識庫原型系統; 最后基于謂詞邏輯提出了DevOps需求的描述方法, 并展示了基于需求的DevOps知識庫的使用.

DevOps; 云計算; 知識管理; 知識庫

隨著互聯網信息技術的快速發展, 軟件和服務的生命周期迭代間隔不斷縮短, 用戶都期望能夠在第一時間獲得新版系統的最新功能特性, 也希望系統缺陷能夠在最短時間內被修復. 因此, 應用系統的快速交付和持續更新能力已成為衡量軟件廠商與服務提供商競爭力的重要標準之一, 有效縮短應用發布周期是滿足用戶期望并提高自身競爭優勢的關鍵[1].

作為一種新興范型, DevOps (Development 和Operations的組合)能夠消除開發人員和運維人員之間的隔閡[2-4], 實現開發和IT運維之間的高度協同, 從而在完成高頻率部署的同時, 提高生產環境的可靠性、穩定性、彈性和安全性.

DevOps是一組過程、方法與系統的統稱, 用于促進開發(應用程序/軟件工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合. 它的出現是由于軟件行業日益清晰地認識到: 為了按時交付軟件產品和服務, 開發和運營工作必須緊密合作. 因此, 開發與運維之間的緊密協作以及端到端的過程自動化(如全自動化的部署流水線[1])是DevOps實現持續交付的有效方法.

在DevOps的各個環節中都存在著大量的、各種各樣的工具、系統、可重用制品和服務來支持開發和運維的協同, 其中具有代表性的有配置管理框架Chef[6]、持續集成服務器Jenkins[14]和容器虛擬化技術Docker[15]等. Chef采用基于Ruby的領域描述語言來創建和執行系統運維腳本—Chef cookbooks, 而這些腳本是執行應用系統軟件棧組件自動化部署的基礎. Docker容器鏡像使組件具有較好的隔離性和可重用性.其他的DevOps工具及其相應制品還包括: Juju[16]和Juju charms[17], Puppet[7,8]和Puppet modules[18]等.

DevOps通常和云計算[9]相結合, 以自服務的方式實現資源的按需供給, 如虛擬化服務器和存儲資源等.云計算提供方(如Amazon[19])提供了不同形式的接口(包括: 圖形化接口、命令行接口和API)來供給和管理云計算資源, 尤其是基于API和命令行接口能夠通過編程方式實現DevOps自動化方法和云計算資源的集成, 并且適用于公有云、私有云以及混合云的不同場景. 例如, Amazon的云計算API能夠實現虛擬服務器的供給, 然后通過執行Chef cookbooks或者是Juju charms實現在虛擬服務器上部署應用軟件棧. 部分云提計算供方還提供了諸如中間件服務(如: 運行環境即服務、數據庫即服務)和自動化運維服務, 這些服務可以作為底層基礎設施服務的補充.

DevOps和云服務的出現和發展變化十分迅速, 存在數量眾多、類型多樣的DevOps相關工具和方法, 并且很多工具在功能方面十分相似, 由此給選擇最恰當的方法和工具并將其組合在一起來實現面向特定應用系統的DevOps自動化帶來困難. 另一方面, 豐富的DevOps知識分散在互聯網上(如開源工具社區等), 并沒有得到有效的管理和使用. 因此, 提供有效的DevOps知識管理方法是實現DevOps自動化和協作的必要前提, 基于系統化的DevOps知識管理為系統設計開發和運維人員提供恰當的DevOps工具和方法集合, 從而最終實現應用和服務的持續交付.

針對上述問題, 本文首先提出一套系統化的DevOps知識管理方法; 然后面向DevOps的知識管理需求對DevOps知識庫原型系統進行了設計和實現;最后, 提出了面向應用DevOps需求的形式化描述方法, 并實現基于形式化表達式的DevOps知識庫查詢.

1 問題分析

WordPress[20]是當前流行的開源博客應用系統, 基于其三層架構, WordPress的部署和運維需求包括: 1) 5.0或更高版本的MySQL數據庫服務器; 2) 5.2.4或更高版本的PHP運行時環境; 3)Web服務器, 可以是Apache HTTP Server或者Nginx. 為了支持WordPress新版本的持續交付, 上述需求必須在系統的DevOps中加以考慮.

圖1 WordPress應用的中間件部署可選項

WordPress的多層體系架構如圖1所示, 其中不同類型的中間件組件可以具體的采用不同的可選技術和實現, 如圖1中標注所示. 當選擇Amazon的虛擬機鏡像(Amazon Machine Image, AMI)來提供底層基礎設施,并安裝LAMP(Linux+Apache+MySQL)軟件棧來支持WordPress的部署和運行時, 所有資源都局限于一臺虛擬機實例, 使得應用的可擴展性收到限制. 因此, WordPress的部署運維可以使用開源配置管理工具Chef, 通過自動化腳本的執行把MySQL和PHP應用分別部署在兩臺不同的虛擬機上. 當WordPress部署運維還需要提高MySQL數據庫服務器的可擴展能力時, 可以使用Juju提供的MySQL charm創建主從(master-slave)結構的MySQL集群, 實現應用數據的讀寫分離以及在多個從數據庫實例間的負載均衡. 但是Juju charm的使用必須滿足一個前提約束, 即Juju charms只能夠部署在Ubuntu操作系統上.

對WordPress的部署和運維需求進一步擴展, 如果需要使WordPress具有根據負載進行彈性伸縮的能力, 那么可以通過提供數據庫即服務(database-as-asercie)和運行環境即服務(runtime-as-a-service)[10]來實現. 例如, Amazon Elastic Beanstalk 和 Google App Engine提供了PHP運行環境, 并對用戶屏蔽底層基礎設施環境. Amazon Relational Database Service (RDS)可以作為WordPress的MySQL數據庫服務來滿足WordPress對數據庫的需求. 但是云服務提供商的服務在系統可配置性方面受到限制. 例如, 獨立安裝的MySQL數據庫能夠根據用戶和實際情況進行任意調整與配置, 而提供商的數據庫服務則必須使用預先設置好的參數配置.

綜上所述, 即使是WordPress這類較為簡單的應用系統, 雖然只有少數幾個部署和運維需求, 仍然存在大量的部署運維可選方案. 另一方面, 不同的DevOps方案優缺點各不相同, 導致應用設計和運維人員難以做出方案決策, 從而簡潔有效的部署和運維他們的應用系統. 因此, 本文需要解決的主要問題是“如何系統的獲取、關聯和使用DevOps知識, 將其作為應用設計和部署時方法決策的基礎”.

圖2 DevOps知識管理方法

圖3 DevOps知識的管理和應用

2 DevOps知識管理

應用系統的開發和運維對于基礎設施和中間件的選擇都存在大量不同的可選方案. 隨著DevOps的興起和發展, 豐富的DevOps知識以非結構化和半結構化數據的形式分散在互聯網上, 具有不同的信息來源.例如, 包括Chef cookbook repository, Puppet forge, Docker Hub, Amazon Web Service’ Marketplace在內的不同公共制品庫可以對外提供如腳本、模板和鏡像等類型的可重用制品來支持應用系統的運維. 上述類型的公共制品庫對其中的制品信息進行了元數據標注和描述(例如: 資源依賴、制品類型、輸入/輸出、評價信息等), 能夠基于網絡爬蟲自動化的獲取這些半結構化的知識、信息和數據.

非結構化數據的自動發現和獲取較為困難, 而諸如文檔分類[11]的自然語言處理技術存在結果不準確的問題, 因此本方法采用人工方式對非結構化數據(包括:文檔、DevOps工具、云資源和服務等)進行抽取、整理和評價. 人工方式又可以分為領域專家方式和眾包方式(crowdsourcing approach)[12]. 領域專家的優勢在于有豐富的知識背景和經驗積累, 因此對于抽取和評價的DevOps知識具有較高的可信度和準確度, 而眾包方式則是以DevOps工具和制品相關的開源社區(如Chef、Puppet、Juju和Docker)為基礎的DevOps知識的收集.

系統化的DevOps知識管理方法如圖2所示, 將基于爬蟲、專家和眾包方式獲得的DevOps知識進行關聯、細化, 并存儲在DevOps知識庫中. DevOps知識庫能夠以多個分布式存儲的方式組織和管理不同層面的資源, 包括: 基礎設施層的資源供給庫、中間件層的部署腳本和應用棧的模板等. 同時, DevOps知識的發現、獲取可以是一個持續的、迭代的過程, 如圖3所示.

在知識使用方面, 如圖2和圖3中所示, 開發和運維人員針對某個應用提出DevOps需求, 從DevOps知識庫中查詢出能夠滿足這些需求的可選方法. 通過更新和增加新的DevOps知識信息(例如增加新的中間件組件部署腳本), 整個知識庫可以不斷更新存儲內容和擴展知識規模. 除此之外, 通過對應用系統的運行時監控, 可以根據系統運行時狀態和存在的問題對相應的DevOps需求進行細化和調整. 例如, 當系統中某個中間件存在運行時異常, 那么相關的DevOps需求也必須隨之發生變化.

因此, 系統化的DevOps知識管理方法能夠在應用的整個生命周期中促進DevOps知識的持續性、迭代式的積累、組織和使用.

3 DevOps知識庫

DevOps知識庫是DevOps知識管理系統的核心組件. 基于知識庫的協同并不局限于開發和運維人員,還包括了基于專家、爬蟲和眾包方式協同的DevOps知識發現、獲取和評價. 本節著重討論DevOps知識庫的概念結構, 從技術上來講, DevOps知識庫可以由多個分布式的知識存儲組成. 例如, 其中的公共知識庫可以由開源社區維護, 這些存儲主要涉及某些諸如Chef cookbooks和Docker鏡像的制品. 私有知識庫能夠由公司或者部門維護, 主要包括某些特定資源或者不希望對外公開的數據信息. 因此, 實際的知識庫是有多個公共和私有知識庫組成.

3.1 知識分類

知識分類和關聯是實現DevOps知識系統化存儲管理和使用的必要前提, 本文提出了一組DevOps領域知識分類來對當前已有的DevOps工具、制品和服務等進行系統的類型劃分和關聯.

當前DevOps涉及的知識類型主要包括: 中間件、基礎設施、服務提供方和DevOps自動化工具, 本文將上述幾種類型作為知識分類中的抽象類型, 這些抽象類型可以包括和劃分為多個子類型, 例如在中間件類型中可以包括: 運行環境、Web服務器等, 如圖4所示.每個具體的工具、可重用軟件制品和服務等則作為具體的DevOps實現與一個或多個抽象類型關聯. 圖4所示的中間件分類以云服務提供方和DevOps工具提供方的中間件分類為依據, 如Heroku, Google, IBM bluemix和chef等.

圖4 中間件分類

3.2 DevOps知識庫原型實現

基于第2節提出的DevOps知識分類和管理方法,本文設計實現了DevOps知識庫的原型, 如圖5所示.原型系統從Google App Engine和Amazon Web Service提供的文檔和特征描述中獲取非結構化的數據, 從Chef Cookbook庫和Juju Charm庫中自動發現和獲取半結構化數據. 每條獲取的知識信息采用單個YAML文件的方式存儲在Git庫中, 并基于3.1節建立的知識分類方法對每條數據進行相應的類型標記和關聯.

圖5 DevOps知識庫原型實現

原型系統包括一個基于Node.js實現的知識庫構造器, 通過讀取所有知識庫內容并采用分級的結構化數據庫存儲的方式實現知識庫的創建和合并. 當前的原型系統包括了大約4000個中間件類型的具體實現,包括: 1430個Chef腳本, 2190個Puppet 腳本和278個Juju charms; 除此之外還包括了基礎設施、服務提供方和中間件類型的其他眾多實現.

原型系統還包括一個基于Node.js的知識庫展示器來對DevOps知識內容進行不同形式的呈現, 如JSON、XML、YAML等, 從而使知識庫能夠更好的應用于不同場景. 知識庫構建器和知識庫展示器均能夠通過編程方式或者命令行接口來加以使用.

4 DevOps需求描述

為了實現對DevOps知識庫的查詢, 獲取滿足DevOps需求的方法和工具, 本文提出了基于布爾表達式的應用DevOps需求描述方法. 布爾表達式通過謂詞邏輯的定義和組合描述應用需求, 并進行DevOps知識庫的查詢. 本文分別從DevOps知識涉及的實體、屬性和屬性值等方面進行表達式的定義.

① ε表示DevOps知識分類包括的所有實體的域,謂詞Prequires: ε-〉{true, false}為每個實體(包括抽象實體和具體實現)賦予一個布爾值. 當給定的實體是一個具體實現(或至少存在一個實現子類)時,Prequires值為true,否則為false.

② ρ表示所有屬性的域, υ表示所有屬性值的域;謂詞PpropertyEq: ε×ρ×υ-〉{true, false}為每個實體、屬性和屬性值的組合賦予一個布爾值, 如果給定實體具有當前屬性的當前值(或者存在子類實體具有當前屬性的當前值), 則PpropertyEq值為true, 否則為false.

③ 謂詞PpropertyEqGr: ε×ρ×υ-〉{true, false}與PpropertyEq相似, 但是只有當屬性值大于等于當前給定值時, 其值才為true.PpropertyEqGr可以用來表示版本依賴語義,例如需要某一特定版本或更高版本的軟件.

PpropertyEqGr與PpropertyEq的語義包含了Prequires的語義, 這是由于當對實體的某個屬性取值存在要求時,那么對應的實體本身也是需要的. 例如,Prequires(‘Middleware/DB/…/MySQL’)表達了對MySQL數據庫的需求, 當對數據庫的版本有特定要求時, 表達式進一步細化為:

除上述應用相關的DevOps需求外, 布爾表達式還可以描述應用無關的約束. 例如, 1)MySQL必須運行在Ubuntu虛擬機上; 2)不允許操作Amazon上的任何組件; 3)不允許使用Chef進行部署, 諸如此類的約束都可以通過表達式表示為附加性的需求.

附加需求可以通過自定義的附加謂詞表達. 例如,謂詞Pexcludes: ε-〉{true, false}表達對特定實體是否出現的約束: 不允許在任何應用棧中包含Amazon的表達式可以表達為Pexcludes(‘Provider/Amazon’).

應用系統完整的DevOps需求可以通過多個謂詞表達式的組合實現. 通過使用整體的布爾表達式來進行DevOps知識庫的查詢, 從而獲得滿足應用相關需求和應用無關需求的DevOps方法、工具、實現等. 本文采用標準化的Web服務策略框架(WS-Policy)[13]將表達式表示為策略. 最后, 合并的表達式轉換為WS-Policy標準形式來實現表達式的處理和查詢使用.

需要說明的是, Web服務策略框架僅僅是作為本文方法實現的技術手段之一, 同樣可以采用其他諸如約束求解器、規則引擎(例如 java drools)等技術手段加以實現. 在后續工作中, 我們將嘗試采用多種技術端進行系統的實現, 并從功能覆蓋、表達能力和執行效率等多方面對不同的技術實現加以分析比較.

以第1節中的WordPress為應用案例, 其最小需求集合可以表示為如下:

基于WordPressminimum可以在DevOps知識庫中查找是否存在合適的實現來支持WordPress的運維, 并通過從知識庫中獲得的實現構成多個可選的運維策略. 基于WordPressminimum從知識庫原型系統中找到的實現包括:

① LAMP AMI (middleware) 運行在 Amazon EC2 (provider)上;

② LAMP Charm (middleware) 運行在 Amazon EC2 (provider)的ubuntu (infrastructure)操作系統上;

③ PHP 應用腳本(middleware)部署在Amazon EC2 (provider)的ubuntu (infrastructure)操作系統上, 同時MySQL charm (middleware)部署在Amazon EC2 (provider)的ubuntu (infrastructure)操作系統上;

④ PHP on Elastic Beanstalk (middleware) 部署在Amazon Elastic Beanstalk (provider)上, 而且MySQL on RDS (middleware) 部署在 Amazon RDS (provider)上;

⑤ PHP on Google App Engine (middleware) 部署在 Google App Engine (provider)上, MySQL charm (middleware) 部署在Amazon EC2 (provider)的ubuntu(infrastructure)上.

上述為WordPress部署和運維可選的一些具有代表性的方案. 下一步可以通過增加附加約束的方法對可選方案進一步細化和過濾, 例如要求MySQL的實現具有可擴展能力.

類似的, 表達式可以進一步增加約束來進行DevOps方案的細化, 例如增加運行時環境彈性能力需求PpropertyEq(‘Middleware/Runtime/PHP’,‘elastic’,’ture’)和對服務提供方的約束Pexcludes(‘Provider/Amazon’).

5 結語

當前DevOps作為新興范型是實現有效的、無縫銜接的軟件自動化管理的有效途徑. DevOps與云計算一起能夠實現基礎設施資源的快速按需供給. 當前規模不斷增漲的可重用DevOps制品和云服務使應用設計和開發人員有大量機會進行DevOps的嘗試和實踐.但是, 由于大量可選DevOps方法和工具的存在使得如何進行有效的決策和選擇成為亟待解決的問題, 而且這些知識分散在不同的社區和來源中. 針對這一問題, 本文提出了一套完整的DevOps知識管理方法. 方法首先針對一組可訪問的知識源進行多種方式的知識獲取、組織、轉換和存儲; 然后提出了DevOps知識分類方法, 并進行了DevOps知識庫原型系統的設計和實現; 最后基于謂詞邏輯提出了DevOps需求的描述機制以及基于WS-Policy實現需求的轉換和使用. 未來工作將進一步改進DevOps知識管理方法, 包括: 提供更多的DevOps知識庫信息, 以及基于自動化爬蟲的知識評價方法.

1 Humble J, Farley D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional, 2010.

2 Humble J, Molesky J. Why enterprises must adopt DevOps to enable continuous delivery. Cutter IT Journal, 2011,24.

3 Walls M. Building a DevOps Culture. O’Reilly Media, Inc., 2013.

4 Wettinger J, Breitenbücher U, Leymann F. DevOpSlang –Bridging the Gap Between Development and Operations. Proc. of the 3rd European Conference on Service- Oriented and Cloud Computing (ESOCC), 2014.

5 Hüttermann M. DevOps for Developers. Apress, 2012.

6 Nelson-Smith S. Test-Driven Infrastructure with Chef. O’Reilly Media, Inc., 2013.

7 Turnbull J, McCune J. Pro Puppet. Apress, 2011.

8 Uphill T. Mastering Puppet. Packt Publishing Ltd., 2014.

9 Mell P, Grance T. The NIST Definition of Cloud Computing. National Institute of Standards and Technology, 2011.

10 K?chele S, Hauck FJ, Spann C, Domaschka J. Beyond IaaS and PaaS: An extended cloud taxonomy for computation. Storage and Networking, 2013.

11 Trinkle P. An Introduction to Unsupervised Document Classification, 2009.

12 Dustdar S, Bhattacharya K. The social compute unit. Internet Computing, IEEE, 2011, 15(3): 64–69.

13 W3C, Web Services Policy Framework (WS-Policy), Version 1.5, 2007.

14 Jenkins, http://jenkins-ci.org.

15 Docker, http://www.docker.com.

16 Juju. https://juju.ubuntu.com.

17 Juju charms. https://jujucharms.com.

18 Puppet modules, https://forge.puppetlabs.com.

19 Amazon EC2. http://aws.amazon.com/ documentation/ ec2

20 WordPress. http://wordpress.org.

Methodology of Capturing and Using DevOps Knowledge for Cloud Services

CHEN Yong-Qiu, ZHANG Bin, XU Ming-Zhu, GU Yong-Sheng
(Jiangsu Electric Power Information Technology Co., Ltd., Nanjing 210024, China)

DevOps is an emerging paradigm to achieve the highly collaboration between system development and operations in order to enable high frequency of software deployment and improve the reliability, stability, elastic and security of production environment. DevOps is typically combined with Cloud computing to realize rapid, on-demand provisioning of underlying resources. Today, an ever-growing amount of DevOps tools, reusable artifacts and Cloud services are available to implement DevOps automation, and a huge number of DevOps knowledge scatters between different communities and sources. As a result, how to make an appropriate decision and select the most suitable method and tools during application design and deployment has become a big challenge. To address this issue, we propose an approach to manage and utilize DevOps knowledge systematically. The approach firstly captures, links, transforms and stores DevOps knowledge from multiple resources in various ways. Then the approach proposes a set of DevOps knowledge taxonomy and implements a knowledgebase prototype. Finally, the approach describes application of DevOps requirements based on predicate logic, and shows how this knowledgebase is utilized.

DevOps; Cloud computing; knowledge management; knowledgebase

2015-12-07;收到修改稿時間:2016-01-29

10.15888/j.cnki.csa.005318