范國偉

（中國人民大學信息學院，北京 100000）

商業(yè)軟件具有功能豐富多樣、版本頻繁更新等特點，為了滿足用戶需求，軟件開發(fā)公司通常選擇敏捷開發(fā)模式。雖然該模式減輕了前端開發(fā)人員的壓力，但是后期運維工作量明顯增加，這一問題在Web 應用軟件中表現(xiàn)的尤其明顯。近年來，容器技術逐漸向輕量化、可移植方向發(fā)展，這就為DevOps 云平臺設計創(chuàng)造了有利條件和技術支持。設計基于容器的DevOps 云平臺系統(tǒng)，成為現(xiàn)階段軟件公司實現(xiàn)產(chǎn)品從前端開發(fā)到運行維護全生命周期管理的一種優(yōu)先選擇。

1 基于容器的DevOps 云平臺架構設計

DevOps 系統(tǒng)的組成架構共分為5 個模塊，各模塊實現(xiàn)的基本功能如下：（1）資源管理模塊。為進一步提高資源利用率，在資源管理中引入了集群管理的概念。利用MooseFS 集群、Kubernetes 集群，將分散在平臺各處的資源整合到一起，為資源的調(diào)用、存儲等提供必要的支持。（2）項目管理模塊。項目經(jīng)理可根據(jù)系統(tǒng)開發(fā)需要，創(chuàng)建新的項目。還可以通過權限管理，為每個成員賦予不同的權限，加快開發(fā)進度。在任務管理中，創(chuàng)建任務計劃，并利用任務匯報表隨時掌握任務進度。（3）在線開發(fā)模塊。支持在線編輯代碼和調(diào)試程序。在文件管理中，管理員可執(zhí)行獲取代碼、刪除代碼等操作。開發(fā)人員還可以自定義代碼編輯的快捷鍵，進一步提高軟件開發(fā)的效率。（4）鏡像管理模塊。包括鏡像制作、上傳、刪除等內(nèi)容，確保該平臺上始終有充足的鏡像滿足工作人員的使用需求。（5）應用管理模塊。在程序完成開發(fā)并經(jīng)過在線調(diào)試確定不存在問題后，將所有代碼進行編譯打包，并形式存儲，生成應用。運維人員可對該應用進行發(fā)布、升級、刪除等操作。該平臺的組成架構如圖1 所示。

圖1 基于容器的DevOps 云平臺架構

2 基于容器的DevOps 云平臺功能設計

2.1 資源管理模塊設計

2.1.1 集群管理模塊設計。DevOps 云平臺的部署環(huán)境中包含了大量的工作節(jié)點，集群管理的核心功能在于根據(jù)運行需要添加、刪除節(jié)點，從而實現(xiàn)資源利用的最優(yōu)化。進行設計時需要注意，如果集群中資源不能滿足應用需要時，應添加新的節(jié)點，保證應用正常運行；當集群中資源過剩時，則刪除多余節(jié)點。集群管理模塊面向的對象是Node 節(jié)點，而非Master 節(jié)點。為了防止誤操作，還需要設計節(jié)點驗證，方法是添加一個由Master 節(jié)點產(chǎn)生的token 驗證碼，每24h 刷新一次。具體流程如下：（1）在添加節(jié)點時，控制節(jié)點調(diào)用Cluster Ctrl::get_token () 分別向Master 節(jié)點和Node 節(jié)點發(fā)送請求token 數(shù)據(jù)。（2）當Node 節(jié)點接收token 驗證碼后，向Master 節(jié)點發(fā)出“加入集群”的請求。Master 在接收該請求后，將控制節(jié)點提供的token 碼，與Node 發(fā)送請求中的token 碼進行配對。（3）若配對成功，則響應該請求，將token 碼和請求結果返回控制節(jié)點，由控制節(jié)點完成Node 節(jié)點的添加。整個流程如圖2 所示。

圖2 添加Node 節(jié)點流程

2.1.2 存儲管理模塊設計。在DevOps 云平臺開發(fā)中，以容器作為應用部署環(huán)境，如果容器因為各種原因無法正常使用，則內(nèi)部存儲數(shù)據(jù)也會隨之丟失。為進一步提高數(shù)據(jù)的安全性、完整性，可選擇存儲卷作為數(shù)據(jù)存儲載體，除了提供較大容量的存儲環(huán)境外，還能夠支持容器與物理機之間無障礙的數(shù)據(jù)交換。通常情況下，存儲卷應用于單臺物理機上，而不適合在集群中應用。要想將存儲卷內(nèi)的信息資源達到跨主機共享的效果，進一步優(yōu)化文件保存和調(diào)用的操作體驗，可以將存儲卷與MooseFS 文件系統(tǒng)加以整合。具體設計流程如下：（1）選擇兩個或多個容器（pod），首先將這些容器的存儲卷合并，實現(xiàn)數(shù)據(jù)的整合，然后在物理機上建立新的MooseFS 文件，后臺調(diào)用靜態(tài)成員函數(shù)create Volume()，并對存儲卷進行初始化；（2）按照同樣的方式，將其他容器也進行數(shù)據(jù)合并，最后將多臺物理機上的MooseFS 文件整合，即可得到MooseFS Flie 系統(tǒng)；（3）在對空間進行限制過程中需要采用靜態(tài)方法get Volume (S path) 獲取Volume 對象，并配合參數(shù)對調(diào)整對象采用setquota(Ssize)的方法實現(xiàn)空間分配。其存儲架構如圖3 所示。

圖3 存儲卷架構圖

2.2 項目管理模塊設計

2.2.1 項目的創(chuàng)建。系統(tǒng)管理員掌握著創(chuàng)建項目的權限。管理員可利用自身掌握的權限，進入到Gitlab 服務器中，指定一個遠程代碼倉庫，調(diào)用task Create()函數(shù)進行創(chuàng)建，并進行初始化。之后再選擇項目經(jīng)理，全權負責該項目的運行和管理。

2.2.2 任務管理模塊設計。該模塊的功能除了支持項目的新建、刪除外，還包括項目進度、項目人員的管理以及任務管理。以任務管理為例，項目經(jīng)理負責任務分配。創(chuàng)建新的任務后，分別分配給開發(fā)組和運維組。開發(fā)人員領取項目開發(fā)任務后，根據(jù)任務需求完成開發(fā)。具體設計流程如下：

2.2.2.1 任務創(chuàng)建后，調(diào)用set Task Depend()進行設置，并定期編制開發(fā)進度表匯報給項目經(jīng)理，方便監(jiān)督開發(fā)進度。待taskependence 表完成開發(fā)任務后，進行任務提交。

2.2.2.2 運維人員領取運維任務后，根據(jù)項目特點、運維需求分析，開展項目的運行維護。定期編制運維進度表，維護功能是由getTaskByUser () 完成。該函數(shù)會在task 表中查找depend_count 值為0 的任務，并匯報給項目經(jīng)理。完成運維任務后，進行提交。反饋的任務如下：

2.2.2.3 項目經(jīng)理以提交的任務匯報表作為依據(jù)，對項目開發(fā)進度進行實時監(jiān)督，避免出現(xiàn)任務延期的情況。最后經(jīng)由task Check() 函數(shù)對任務進行審核，無誤后順利完成項目開發(fā)任務。整個設計流程如圖4 所示。

圖4 任務管理流程圖

2.2.3 操作管理。為了防止出現(xiàn)誤操作導致系統(tǒng)功能受到影響，對于系統(tǒng)中涉及到的敏感操作，均要求由項目經(jīng)理審核。只有在審核通過后才能繼續(xù)下一步的操作。以鏡像刪除操作為例，用戶首先要提交“刪除鏡像”的操作請求；該請求發(fā)送至項目經(jīng)理后，進行請求審查。若該操作符合要求，則批準此操作，向?qū)涌诎l(fā)送請求，由用戶自行完成鏡像刪除的操作；若該操作不符合要求，則否決此操作。這就避免了運維人員誤操作將鏡像刪除，導致開發(fā)人員無法正常開展鏡像調(diào)試的情況，從而保證了系統(tǒng)開發(fā)的順利進行。需要注意的是，操作管理面向的對象為系統(tǒng)中的敏感操作，對于其他常規(guī)操作則不作審核，從而減輕系統(tǒng)負擔。

2.3 在線開發(fā)模塊設計

2.3.1 文件管理模塊設計。支持在線開發(fā)是DevOps 云平臺的特色功能，將開發(fā)環(huán)境從原來的物理平臺，轉移到容器云上，一方面有利于開發(fā)程序和編程代碼的安全保存，有效解決信息丟失和泄露的問題，另一方面也能夠?qū)崿F(xiàn)開發(fā)環(huán)境和運維環(huán)境的一致性，對DevOps 云平臺的運行穩(wěn)定也有一定的幫助。Web項目開發(fā)過程中，會生成海量化的代碼文件、配置文件，做好文件管理尤為重要。文件管理的設計流程如圖5 所示。

圖5 文件管理流程圖

獲取訪問權限的用戶從系統(tǒng)登錄界面完成驗證后，進入到系統(tǒng)主界面，從工具欄中選擇“打開”選項，找到需要管理的文件，正常讀取文件后顯示內(nèi)容。管理員經(jīng)檢查，確定文件不存在問題后，可選擇上傳文件、移動文件、刪除文件等操作。

2.3.2 代碼編輯。編寫代碼是Devops 云平臺設計的核心工作，有些代碼編輯器可提供代碼高亮、代碼折疊、自動縮進等功能，為程序員提供了諸多便利。目前技術成熟度極高、應用比較廣泛的在線代碼編輯器有ACE、Monaco 等幾種。其中ACE 具有集成方式簡單、不易受網(wǎng)絡性能影響等特點。在代碼編輯設計流程如下：

2.3.2.1 編輯器配置文件獲取，編輯器設置文件獲取是Coding OL::get Edit Con FIle () 函數(shù)完成的，并向后臺發(fā)送消息，程序員可根據(jù)自己的偏好設置快捷鍵。在登錄系統(tǒng)之后，調(diào)出快捷鍵菜單欄，在自定義快捷鍵之后，從前臺發(fā)送請求快捷鍵的信息，后臺通過Conf File Op::readconfig()接收請求之后將設置信息保存在editor.json 配置文件中。當下一次用戶登錄系統(tǒng)后，激活配置文件，用戶可調(diào)用快捷鍵。配置文件如下：

2.3.2.2 編輯器設置，在前端接收到數(shù)據(jù)后調(diào)用set Edit Conf()進行下一步操作，然后通過ace.edit() 函數(shù)獲取ACE 編輯器對象，結合不同的設置編輯不同的函數(shù)；

2.3.2.3 代碼斷網(wǎng)保存，在線開發(fā)平臺必須要考慮在突然斷網(wǎng)之后的代碼保存問題，在ACE 代碼編輯器中設有一個定時器，可由管理員手動設置間隔時間。然后每隔一段時間就檢查一次是否出現(xiàn)斷網(wǎng)情況，若檢測到斷網(wǎng)情況，則將用戶最新編輯并且尚未保存的代碼，自動保存在本地，防止代碼斷網(wǎng)丟失的問題。

2.3.3 在線調(diào)試。在線編輯代碼、完成程序開發(fā)后，還要通過在線調(diào)試，檢測程序是否存在BUG。特別是基于Web 前端的程序開發(fā)，開發(fā)人員除了要確保代碼本身不存在邏輯問題，還要經(jīng)常性的檢查Web 頁面的呈現(xiàn)效果。因此，在線調(diào)試的重要性不言而喻。其設計流程為：（1）準備在線調(diào)試所需的環(huán)境。選擇單個容器進行測試，保證容器端口對用戶開放，使用戶能夠直接進行訪問；（2）啟動在線調(diào)試功能。運行Web 項目，如果該項目存在語法錯誤，可直接在網(wǎng)頁中暴露出來。調(diào)試人員可根據(jù)顯示結果，針對語法錯誤進行代碼修改。然后刷新一次項目，直到語法錯誤消失。配置內(nèi)容如下：

2.4 鏡像管理模塊設計

2.4.1 鏡像制作。要想使系統(tǒng)中的容器能夠滿足應用運行的需要，必須要提供多種可供選擇的鏡像。制作鏡像既是鏡像管理的首要環(huán)節(jié)，也是保障系統(tǒng)運行的關鍵步驟?；诰€上平臺的鏡像制作，無須訪問底層物理機，除了簡化運行流程外，對保障數(shù)據(jù)信息的安全也有積極幫助。現(xiàn)階段制作鏡像的工具有2種流程：（1）DockerFile 工具，主要支持用戶自定義基礎鏡像，在此基礎上嵌入配置文件，自動構建鏡像；（2）Commit 工具，是將某個正在運行的容器作為鏡像，在該容器中執(zhí)行Linux 命令進行環(huán)境配置，配置結束后即可得到鏡像?，F(xiàn)以DockerFile 工具為例，其制作流程如圖6 所示。

圖6 鏡像制作流程圖

2.4.2 鏡像上傳。制作好的鏡像，需要將鏡像信息完全保存至鏡像倉庫，以便功能正常發(fā)揮。鏡像信息保存的過程即為鏡像上傳。為了方便后期進行鏡像管理（添加、維護、刪除），需要在鏡像信息中添加Layer 文件。對于成功上傳的鏡像信息，后期可通過調(diào)用Layer 文件的方式，查找目標信息，或檢索維護記錄，從而實現(xiàn)快速操作。

3 基于容器的DevOps 云平臺系統(tǒng)測試

3.1 測試環(huán)境的創(chuàng)建

系統(tǒng)測試在仿真環(huán)境下進行，使用虛擬機代替物理服務器。共用13 臺虛擬機，其中2 臺為Web 服務器，用于處理用戶請求；1 臺為Nginx 服務器，用于將用戶提出請求轉移到Web 服務器中。除此之外，還配置了數(shù)據(jù)庫集群、MooseFS 集群等，具體的測試環(huán)境如表1 所示。

表1 測試環(huán)境說明表

3.2 系統(tǒng)性能測試

3.2.1 在線開發(fā)可靠性測試?；贒evOps 云平臺的在線開發(fā)模塊，假如在開發(fā)過程中出現(xiàn)斷電、斷網(wǎng)的情況，能否將已經(jīng)編寫但是尚未保存的代碼進行自動保存，是衡量在線開發(fā)可靠性的重要指標。針對這一指標開展性能測試，操作流程為：開發(fā)人員正常登錄系統(tǒng)后，在主界面上選擇“在線開發(fā)”模塊，新建一個文件，點擊工具欄的“打開”選項，在彈出的選擇頁面中，打開test.php 文件，并在該文件中添加add 函數(shù)，然后保存。任意編寫一段代碼，此時將網(wǎng)絡斷開，等待10s 后關閉瀏覽器。然后將網(wǎng)絡重新連接，并打開瀏覽器，在搜索欄中采用關鍵字檢索剛才的項目，并雙擊打開。系統(tǒng)在頁面加載完畢后，會自動檢查本地緩存，判斷是否有可供選擇的保存代碼。如果有，則彈出“檢測到test.php 文件有本地緩存，是否選擇恢復？”的提示框，如圖7所示。開發(fā)人員點擊“確認”后，之前的代碼完全恢復，則說明DevOps 云平臺的在線開發(fā)功能可靠。

圖7 代碼恢復測試圖

3.2.2 網(wǎng)頁響應速度測試。DevOps 云平臺系統(tǒng)的全部功能，都是基于Web 網(wǎng)頁來實現(xiàn)的，為了優(yōu)化用戶的操作體驗，必須要盡可能的提高網(wǎng)頁響應速度。通過開展網(wǎng)頁響應速度測試也能夠在一定程度上判斷該系統(tǒng)的性能。

3.2.2.1 數(shù)據(jù)庫查詢接口測試。云平臺運行期間，需要頻繁進行數(shù)據(jù)訪問、調(diào)用、存儲等操作，因此該項測試中選擇數(shù)據(jù)庫查詢接口，測試其在多個用戶并發(fā)訪問情況下的響應速度。試驗中分別選擇100、200。300。500 個并發(fā)數(shù)，每個并發(fā)數(shù)測試15次，然后求平均值。試驗結果記錄見表2。

表2 數(shù)據(jù)庫查詢接口測試結果

在實際使用中，數(shù)據(jù)庫查詢結果的反饋時間在2s 以內(nèi)，用戶體驗良好；2-5s 則一般，超過5s 體驗較差。從測試結果來看，在并發(fā)數(shù)為100 時，響應時間為0.264s；并發(fā)數(shù)為500 時，相應時間為0.338s，均明顯低于2s，故該系統(tǒng)的響應速度較快，操作體驗較好。

3.2.2.2 資源創(chuàng)建接口測試。為了提高響應速度和減少系統(tǒng)資源占用，該測試中利用在線調(diào)試接口作為資源創(chuàng)建接口，測試方法如下：

用戶登錄系統(tǒng)后，根據(jù)選擇的鏡像配置，在后臺新建一個容器，在獲取容器地址后開始測試。測試內(nèi)容主要包括3 部分，分別是信息傳遞時間、信息處理查詢時間、容器創(chuàng)建時間。其中，信息傳遞時間檢測難度較大，而另外2 個參數(shù)可通過修改程序獲得，因此本次測試只選擇信息處理時間和容器創(chuàng)建時間作為研究對象。為最大程度上消除結果誤差，進行了4 組測試，每組分別在1 個、5 個、10 個和20 個并發(fā)的情況下檢測響應速度，結果如表3 所示。

表3 任務創(chuàng)建接口測試表

結合表3 可知，在并發(fā)數(shù)為1 的情況下，該系統(tǒng)的平均響應時間僅為1.86s；而并發(fā)數(shù)為5 個時，響應時間則需要2.34s，屬于一般速度；繼續(xù)增加并發(fā)數(shù)至20 個時，響應時間則需要6.04s，屬于較慢速度。根據(jù)平均響應時間的變化規(guī)律來看，數(shù)據(jù)處理時間與響應時間的變化規(guī)律不符合，而容器創(chuàng)建時間與響應時間的變化規(guī)律基本一致。由此可得，容器創(chuàng)建時間是導致系統(tǒng)響應時間增加的關鍵因素。創(chuàng)建容器的數(shù)量越多，則占用的系統(tǒng)資源響應增加，物理機的負荷加大，進而導致響應時間延長。為了驗證這一結論，在物理機上編寫腳本進行測試，腳本如下：

如上，使用腳本創(chuàng)建容器用時2 分19 秒，減去等待時間，則每個容器創(chuàng)建的平均用時為2.25s。由此驗證了上述結論，即容器數(shù)量增加會導致相應速度變慢。針對此類情況，可以選擇創(chuàng)建虛擬機的方式，將多余的容器創(chuàng)建請求分擔到虛擬機上，這樣就能夠減輕物理機上的并發(fā)數(shù)，從而達到提高響應速度的目的。

4 結論

為了更好地滿足用戶需求，同時也是縮短開發(fā)周期，現(xiàn)階段的軟件開發(fā)越來越多的使用敏捷開發(fā)模式。該模式雖然為軟件開發(fā)創(chuàng)造了便利，但是異構環(huán)境下服務器部署和運維的工作量明顯增加。基于容器的DevOps 云平臺，實現(xiàn)了項目開發(fā)、運維管理、環(huán)境部署的一體化，為軟件的在線開發(fā)創(chuàng)造了更好的環(huán)境。從系統(tǒng)功能上來看，該系統(tǒng)除了支持在線開發(fā)外，還能夠?qū)崿F(xiàn)鏡像管理、進度調(diào)控等一系列功能。并且通過系統(tǒng)測試，證明了DevOps 云平臺的在線開發(fā)具有較強的可靠性，網(wǎng)頁響應具有及時性，具有推廣應用價值。