面向云服務(wù)的DevOps知識獲取與應(yīng)用①

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

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

面向云服務(wù)的DevOps知識獲取與應(yīng)用①

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

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

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

DevOps; 云計(jì)算; 知識管理; 知識庫

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

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

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

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

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

DevOps和云服務(wù)的出現(xiàn)和發(fā)展變化十分迅速, 存在數(shù)量眾多、類型多樣的DevOps相關(guān)工具和方法, 并且很多工具在功能方面十分相似, 由此給選擇最恰當(dāng)?shù)姆椒ê凸ぞ卟⑵浣M合在一起來實(shí)現(xiàn)面向特定應(yīng)用系統(tǒng)的DevOps自動化帶來困難. 另一方面, 豐富的DevOps知識分散在互聯(lián)網(wǎng)上(如開源工具社區(qū)等), 并沒有得到有效的管理和使用. 因此, 提供有效的DevOps知識管理方法是實(shí)現(xiàn)DevOps自動化和協(xié)作的必要前提, 基于系統(tǒng)化的DevOps知識管理為系統(tǒng)設(shè)計(jì)開發(fā)和運(yùn)維人員提供恰當(dāng)?shù)腄evOps工具和方法集合, 從而最終實(shí)現(xiàn)應(yīng)用和服務(wù)的持續(xù)交付.

針對上述問題, 本文首先提出一套系統(tǒng)化的DevOps知識管理方法; 然后面向DevOps的知識管理需求對DevOps知識庫原型系統(tǒng)進(jìn)行了設(shè)計(jì)和實(shí)現(xiàn);最后, 提出了面向應(yīng)用DevOps需求的形式化描述方法, 并實(shí)現(xiàn)基于形式化表達(dá)式的DevOps知識庫查詢.

1 問題分析

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

圖1 WordPress應(yīng)用的中間件部署可選項(xiàng)

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

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

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

圖2 DevOps知識管理方法

圖3 DevOps知識的管理和應(yīng)用

2 DevOps知識管理

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

非結(jié)構(gòu)化數(shù)據(jù)的自動發(fā)現(xiàn)和獲取較為困難, 而諸如文檔分類[11]的自然語言處理技術(shù)存在結(jié)果不準(zhǔn)確的問題, 因此本方法采用人工方式對非結(jié)構(gòu)化數(shù)據(jù)(包括:文檔、DevOps工具、云資源和服務(wù)等)進(jìn)行抽取、整理和評價. 人工方式又可以分為領(lǐng)域?qū)＜曳绞胶捅姲绞?crowdsourcing approach)[12]. 領(lǐng)域?qū)＜业膬?yōu)勢在于有豐富的知識背景和經(jīng)驗(yàn)積累, 因此對于抽取和評價的DevOps知識具有較高的可信度和準(zhǔn)確度, 而眾包方式則是以DevOps工具和制品相關(guān)的開源社區(qū)(如Chef、Puppet、Juju和Docker)為基礎(chǔ)的DevOps知識的收集.

系統(tǒng)化的DevOps知識管理方法如圖2所示, 將基于爬蟲、專家和眾包方式獲得的DevOps知識進(jìn)行關(guān)聯(lián)、細(xì)化, 并存儲在DevOps知識庫中. DevOps知識庫能夠以多個分布式存儲的方式組織和管理不同層面的資源, 包括: 基礎(chǔ)設(shè)施層的資源供給庫、中間件層的部署腳本和應(yīng)用棧的模板等. 同時, DevOps知識的發(fā)現(xiàn)、獲取可以是一個持續(xù)的、迭代的過程, 如圖3所示.

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

因此, 系統(tǒng)化的DevOps知識管理方法能夠在應(yīng)用的整個生命周期中促進(jìn)DevOps知識的持續(xù)性、迭代式的積累、組織和使用.

3 DevOps知識庫

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

3.1 知識分類

知識分類和關(guān)聯(lián)是實(shí)現(xiàn)DevOps知識系統(tǒng)化存儲管理和使用的必要前提, 本文提出了一組DevOps領(lǐng)域知識分類來對當(dāng)前已有的DevOps工具、制品和服務(wù)等進(jìn)行系統(tǒng)的類型劃分和關(guān)聯(lián).

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

圖4 中間件分類

3.2 DevOps知識庫原型實(shí)現(xiàn)

基于第2節(jié)提出的DevOps知識分類和管理方法,本文設(shè)計(jì)實(shí)現(xiàn)了DevOps知識庫的原型, 如圖5所示.原型系統(tǒng)從Google App Engine和Amazon Web Service提供的文檔和特征描述中獲取非結(jié)構(gòu)化的數(shù)據(jù), 從Chef Cookbook庫和Juju Charm庫中自動發(fā)現(xiàn)和獲取半結(jié)構(gòu)化數(shù)據(jù). 每條獲取的知識信息采用單個YAML文件的方式存儲在Git庫中, 并基于3.1節(jié)建立的知識分類方法對每條數(shù)據(jù)進(jìn)行相應(yīng)的類型標(biāo)記和關(guān)聯(lián).

圖5 DevOps知識庫原型實(shí)現(xiàn)

原型系統(tǒng)包括一個基于Node.js實(shí)現(xiàn)的知識庫構(gòu)造器, 通過讀取所有知識庫內(nèi)容并采用分級的結(jié)構(gòu)化數(shù)據(jù)庫存儲的方式實(shí)現(xiàn)知識庫的創(chuàng)建和合并. 當(dāng)前的原型系統(tǒng)包括了大約4000個中間件類型的具體實(shí)現(xiàn),包括: 1430個Chef腳本, 2190個Puppet 腳本和278個Juju charms; 除此之外還包括了基礎(chǔ)設(shè)施、服務(wù)提供方和中間件類型的其他眾多實(shí)現(xiàn).

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

4 DevOps需求描述

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

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

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

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

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

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

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

應(yīng)用系統(tǒng)完整的DevOps需求可以通過多個謂詞表達(dá)式的組合實(shí)現(xiàn). 通過使用整體的布爾表達(dá)式來進(jìn)行DevOps知識庫的查詢, 從而獲得滿足應(yīng)用相關(guān)需求和應(yīng)用無關(guān)需求的DevOps方法、工具、實(shí)現(xiàn)等. 本文采用標(biāo)準(zhǔn)化的Web服務(wù)策略框架(WS-Policy)[13]將表達(dá)式表示為策略. 最后, 合并的表達(dá)式轉(zhuǎn)換為WS-Policy標(biāo)準(zhǔn)形式來實(shí)現(xiàn)表達(dá)式的處理和查詢使用.

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

以第1節(jié)中的WordPress為應(yīng)用案例, 其最小需求集合可以表示為如下:

基于WordPressminimum可以在DevOps知識庫中查找是否存在合適的實(shí)現(xiàn)來支持WordPress的運(yùn)維, 并通過從知識庫中獲得的實(shí)現(xiàn)構(gòu)成多個可選的運(yùn)維策略. 基于WordPressminimum從知識庫原型系統(tǒng)中找到的實(shí)現(xiàn)包括:

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

② LAMP Charm (middleware) 運(yùn)行在 Amazon EC2 (provider)的ubuntu (infrastructure)操作系統(tǒng)上;

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

④ 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部署和運(yùn)維可選的一些具有代表性的方案. 下一步可以通過增加附加約束的方法對可選方案進(jìn)一步細(xì)化和過濾, 例如要求MySQL的實(shí)現(xiàn)具有可擴(kuò)展能力.

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

5 結(jié)語

當(dāng)前DevOps作為新興范型是實(shí)現(xiàn)有效的、無縫銜接的軟件自動化管理的有效途徑. DevOps與云計(jì)算一起能夠?qū)崿F(xiàn)基礎(chǔ)設(shè)施資源的快速按需供給. 當(dāng)前規(guī)模不斷增漲的可重用DevOps制品和云服務(wù)使應(yīng)用設(shè)計(jì)和開發(fā)人員有大量機(jī)會進(jìn)行DevOps的嘗試和實(shí)踐.但是, 由于大量可選DevOps方法和工具的存在使得如何進(jìn)行有效的決策和選擇成為亟待解決的問題, 而且這些知識分散在不同的社區(qū)和來源中. 針對這一問題, 本文提出了一套完整的DevOps知識管理方法. 方法首先針對一組可訪問的知識源進(jìn)行多種方式的知識獲取、組織、轉(zhuǎn)換和存儲; 然后提出了DevOps知識分類方法, 并進(jìn)行了DevOps知識庫原型系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn); 最后基于謂詞邏輯提出了DevOps需求的描述機(jī)制以及基于WS-Policy實(shí)現(xiàn)需求的轉(zhuǎn)換和使用. 未來工作將進(jìn)一步改進(jìn)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