施曉權(quán)，林平榮，楊俊欽，陳沛?zhèn)?/p>

（廣州軟件學(xué)院軟件研究所，廣州 510900）

0 引言

隨著《教育信息化2.0 行動(dòng)計(jì)劃》的頒布，中國(guó)教育信息化邁進(jìn)了“2.0”時(shí)代。智慧校園作為教育信息化的更高級(jí)形態(tài)，高校需要在此新時(shí)代的機(jī)遇與挑戰(zhàn)中，依托大數(shù)據(jù)、物聯(lián)網(wǎng)、人工智能、區(qū)塊鏈等新興技術(shù)，為智慧校園的建設(shè)提速?！丁笆濉眹?guó)家信息化規(guī)劃》明確指出，高校要把握技術(shù)變革趨勢(shì)，聚力建設(shè)智慧校園，推動(dòng)教育智慧化轉(zhuǎn)型［1］。在智慧校園建設(shè)過(guò)程中，高校在教學(xué)、管理等方面演化出繁多的信息化系統(tǒng)，隨著建設(shè)推進(jìn)，系統(tǒng)規(guī)模也日益龐大［2］。為了滿(mǎn)足智慧校園的可持續(xù)活躍，需要持續(xù)的優(yōu)化迭代升級(jí)與運(yùn)維來(lái)保障，而教育政策的變革、智慧校園系統(tǒng)日益頻繁變更的需求、新老技術(shù)的更新迭代，這些都需要龐大的變更和維護(hù)成本。此外，軟件開(kāi)發(fā)與運(yùn)維已經(jīng)進(jìn)入容器時(shí)代，構(gòu)建環(huán)境容器化早已應(yīng)用于各大規(guī)模的項(xiàng)目中，連貫的工作流程和流水線也需要一種方便易上手的方案?；诖?，構(gòu)建一套既滿(mǎn)足發(fā)展需要，又能銜接陳舊系統(tǒng)的開(kāi)發(fā)迭代方案對(duì)于智慧校園轉(zhuǎn)型是十分必要的。本文圍繞高校轉(zhuǎn)型智慧校園背景，提出基于Rancher 的DevOps 平臺(tái)，來(lái)降低開(kāi)發(fā)迭代的成本，降低持續(xù)活躍的難度系數(shù)，提高產(chǎn)品發(fā)布的容錯(cuò)性，借助用戶(hù)反饋加速產(chǎn)品迭代，推進(jìn)智慧校園建設(shè)，促進(jìn)高校教育信息化踏上新階段。

1 Rancher簡(jiǎn)介

目前容器管理的標(biāo)準(zhǔn)是Kubernetes，Kubernetes 也被大多數(shù)的云廠商作為標(biāo)準(zhǔn)的基礎(chǔ)設(shè)施對(duì)外提供。Rancher 支持對(duì)所有的Kubernetes 集群進(jìn)行集中化創(chuàng)建和管理，用戶(hù)可以通過(guò)Rancher 提供的UI 界面進(jìn)行點(diǎn)擊操作即可管理Kubernetes 集群，不再需要執(zhí)行復(fù)雜的腳本命令。這為高校信息化系統(tǒng)上Kubernetes 提供了可行性。而Kubernetes 可以實(shí)現(xiàn)容器自動(dòng)化部署、自動(dòng)化擴(kuò)容、自動(dòng)故障遷移等，在各種信息化系統(tǒng)數(shù)量及規(guī)模日益龐大的智慧校園場(chǎng)景中，如果高校如果能夠基于Kubernetes構(gòu)建，其中的價(jià)值不言而喻。

Rancher 是一款開(kāi)源的企業(yè)級(jí)容器管理工具。Rancher 提供了在生產(chǎn)環(huán)境中使用的管理Docker和Kubernetes 的全?；萜鞑渴鹋c管理平臺(tái)，主要由基礎(chǔ)設(shè)施編排、容器編排與調(diào)度、應(yīng)用商店和企業(yè)級(jí)權(quán)限管理四部分組成。Rancher 的運(yùn)行僅需主機(jī)具有CPU、內(nèi)存、硬盤(pán)和網(wǎng)絡(luò)資源即可，并且可以運(yùn)行在任何Linux 主機(jī)中，因此Rancher 可以運(yùn)行在各種公有云或私有云上。此外，Rancher 的各種服務(wù)是通過(guò)容器化部署的，具有靈活的容器編排與調(diào)度機(jī)制和嚴(yán)密的企業(yè)級(jí)權(quán)限管理機(jī)制，這些讓Rancher 具備了通用、高可用和安全等特性。

Rancher 由五層架構(gòu)組成。最底層是基礎(chǔ)的虛擬化環(huán)境，可以使用VMWEAR 搭建或者由各大云廠商提供；第二層是運(yùn)行在虛擬化環(huán)境的各種Linux 主機(jī)；第三層是各種基礎(chǔ)硬件和網(wǎng)絡(luò)服務(wù)；第四層是用戶(hù)管理、由Docker Swarm、Kubernetes 等各種容器編排管理工具組成的容器編排管理服務(wù)等；第五層是運(yùn)行在容器上面的各種應(yīng)用。五層架構(gòu)說(shuō)明如圖1所示。

圖1 Rancher五層架構(gòu)說(shuō)明

2 基于Rancher的DevOps方案

Meyer［3］提出實(shí)現(xiàn)持續(xù)集成系統(tǒng)的關(guān)鍵因素是版本控制和持續(xù)集成服務(wù)器。Armenise［4］提出Jenkins 可以實(shí)現(xiàn)持續(xù)集成和自動(dòng)化的構(gòu)建,通過(guò)Jenkins 可以實(shí)現(xiàn)持續(xù)交付。張兆晨和羅鐵堅(jiān)［5］在他們的基礎(chǔ)上，提出了一種基于Jenkins和Docker的CCI 持續(xù)集成系統(tǒng),提出代碼管理、持續(xù)集成和持續(xù)交付的一體化工作流方案。但并沒(méi)有實(shí)現(xiàn)容器的管理和部署編排工具, 缺乏可視化的用戶(hù)管理界面。在高校中，專(zhuān)業(yè)且職責(zé)單一的運(yùn)維人員比較少，低門(mén)檻、高可用的運(yùn)維平臺(tái)是高校運(yùn)維人員優(yōu)先的選擇，因此，本文提出一種基于Rancher 的DevOps 方案，不僅可以達(dá)到一體化代碼管理、持續(xù)集成和持續(xù)交付，而且可以通過(guò)可視化的用戶(hù)管理界面進(jìn)行容器編排管理、滾動(dòng)發(fā)布，并實(shí)現(xiàn)了自動(dòng)化部署、自動(dòng)化擴(kuò)容、自動(dòng)故障遷移等，降低了運(yùn)維的門(mén)檻和成本。

基于Rancher 的DevOps 方案主要借助Gitlab、Jenkins、Maven、Nexus、Docker Registry 等工具，構(gòu)建高可用的自動(dòng)化DevOps平臺(tái)。開(kāi)發(fā)人員在編碼階段通過(guò)GitLab 版本管理工具對(duì)代碼進(jìn)行版本管理，初次編寫(xiě)完成后上傳到Gitlab，通過(guò)Jenkins 自動(dòng)觸發(fā)構(gòu)建動(dòng)作，DevOps 會(huì)自動(dòng)拉取代碼，通過(guò)腳本使用Maven進(jìn)行打包并上傳到Nexus私服上，之后執(zhí)行容器化部署操作，將最新的代碼打包成docker 鏡像，并發(fā)布到Docker Registry私服上，之后發(fā)布到Rancher 集群環(huán)境下的Kubernetes 上，通過(guò)Rancher 進(jìn)行監(jiān)控服務(wù)狀態(tài)，同時(shí)Jenkins 會(huì)將代碼發(fā)送到Sonar 進(jìn)行審查，審查結(jié)果會(huì)通過(guò)Sonar 告訴開(kāi)發(fā)人員，對(duì)存在隱藏Bug的地方，開(kāi)發(fā)人員可以根據(jù)修改建議進(jìn)行修正。開(kāi)發(fā)人員對(duì)程序代碼進(jìn)行迭代操作時(shí)，再次自動(dòng)構(gòu)建時(shí)，DevOps 會(huì)自動(dòng)再次執(zhí)行以上操作，唯一不同的是發(fā)布到的Kubernetes 上時(shí)是通過(guò)滾動(dòng)發(fā)布的形式，會(huì)自動(dòng)對(duì)服務(wù)逐個(gè)進(jìn)行升級(jí)，不需要停止對(duì)外服務(wù)即可依次完成更新升級(jí)。運(yùn)維人員可以進(jìn)行指定版本代碼，打上標(biāo)簽標(biāo)記發(fā)布到生產(chǎn)環(huán)境，Rancher 會(huì)根據(jù)調(diào)度規(guī)則創(chuàng)建指定代碼的服務(wù)，運(yùn)維人員也可以根據(jù)Rancher 提供的可視化監(jiān)控界面，實(shí)時(shí)查看CPU 使用率、內(nèi)存使用率、磁盤(pán)壓力、Pod、Service 等各種的資源情況，根據(jù)實(shí)際需求情況在Rancher 對(duì)各服務(wù)進(jìn)行調(diào)整?；赗ancher的DevOps方案如圖2所示。

圖2 基于Rancher的DevOps方案

3 遺留系統(tǒng)過(guò)度到DevOps方案

在智慧校園的建設(shè)中，新的信息化系統(tǒng)采用新技術(shù)開(kāi)發(fā)，可以直接使用DevOps方案，但更多的需要考慮舊系統(tǒng)的改造，讓其平穩(wěn)過(guò)度到智慧校園中。教育信息化的發(fā)展過(guò)程存在階段性的差異，在教育信息化推薦的過(guò)程中，技術(shù)也在不斷的迭代更新，國(guó)內(nèi)高校在教育信息化初期發(fā)展過(guò)程中普遍對(duì)信息化認(rèn)知不足，缺少頂層設(shè)計(jì)與規(guī)劃，導(dǎo)致信息化建設(shè)各項(xiàng)標(biāo)準(zhǔn)未能完全統(tǒng)一，各業(yè)務(wù)模塊之間存在壁壘，出現(xiàn)了各種“煙囪式”信息化系統(tǒng)［6］。為了迎合政策變化、需求變更，不斷在現(xiàn)有系統(tǒng)堆砌業(yè)務(wù)，加上開(kāi)發(fā)和運(yùn)維人員流動(dòng)、文檔缺失等因素，越來(lái)越多的系統(tǒng)逐漸演化成遺留系統(tǒng)（legacy system）［7］。應(yīng)用系統(tǒng)分散，業(yè)務(wù)不協(xié)調(diào)，日積月累，導(dǎo)致大部分高校普遍存在“信息孤島”現(xiàn)象，嚴(yán)重阻礙了智慧校園發(fā)展的融合［8］。

遺留系統(tǒng)對(duì)高校的發(fā)展決策具有重大意義，管理層可以利用數(shù)據(jù)分析、數(shù)據(jù)挖掘等新技術(shù)從遺留系統(tǒng)中挖掘出潛在的數(shù)據(jù)價(jià)值，為今后的發(fā)展決策提供寶貴的數(shù)據(jù)資料。隨著技術(shù)的發(fā)展，老技術(shù)不再適合現(xiàn)有的業(yè)務(wù)場(chǎng)景，也將逐步淘汰，相對(duì)應(yīng)的專(zhuān)業(yè)人才也逐步減少，這給遺留系統(tǒng)的維護(hù)、迭代帶來(lái)了一定的挑戰(zhàn)。在微服務(wù)、DevOps 技術(shù)還沒(méi)有出現(xiàn)之前，對(duì)遺留系統(tǒng)的遷移是舉步維艱，牽一發(fā)而動(dòng)全身，不可能做到既能保持現(xiàn)有業(yè)務(wù)穩(wěn)健運(yùn)行，又能逐步對(duì)遺留系統(tǒng)進(jìn)行改造，而且對(duì)遺留系統(tǒng)的改造還需要耗費(fèi)巨大的人力物力。DevOps 的出現(xiàn)，讓遺留系統(tǒng)的改造具備了可行性。遺留系統(tǒng)過(guò)度到DevOps可以分為兩步走。第一步是數(shù)據(jù)遷移，遺留系統(tǒng)過(guò)度到智慧校園，必然是由新系統(tǒng)接替，但其積累的大量彌足珍貴的數(shù)據(jù)如何平穩(wěn)遷移到新系統(tǒng)是必須優(yōu)先考慮的，結(jié)合系統(tǒng)遷移的需求，可以采用縱向劃分的辦法，根據(jù)功能模塊對(duì)數(shù)據(jù)進(jìn)行劃分，設(shè)計(jì)新的數(shù)據(jù)庫(kù)，再通過(guò)ETL 工具將數(shù)據(jù)遷移到新的數(shù)據(jù)庫(kù)，逐步的對(duì)數(shù)據(jù)進(jìn)行遷移。在新系統(tǒng)沒(méi)有完全改造完成、停止舊系統(tǒng)使用前，新老數(shù)據(jù)庫(kù)同時(shí)使用，定時(shí)同步，確保數(shù)據(jù)的一致性。第二步是系統(tǒng)改造，大部分的遺留系統(tǒng)都是初期的信息系統(tǒng)演變而來(lái)，大多數(shù)是整體部署的項(xiàng)目，一個(gè)項(xiàng)目就一個(gè)工程，沒(méi)有按功能模塊劃分，所有的功能實(shí)現(xiàn)都放在里面，高度耦合，只能統(tǒng)一部署。對(duì)遺留系統(tǒng)的改造，可以根據(jù)現(xiàn)有的業(yè)務(wù)場(chǎng)景進(jìn)行功能劃分，并選擇第一步劃分好所需要的數(shù)據(jù)庫(kù)，采用模塊化、按需逐步的開(kāi)發(fā)方式，使用DevOps做到快速開(kāi)發(fā)，縮短改造的工期和所需的人力物力。

通過(guò)以上的改造，無(wú)論是新老系統(tǒng)，都可以在DevOps 上進(jìn)行迭代開(kāi)，做到系統(tǒng)之間的解耦，逐步使用新系統(tǒng)替換遺留系統(tǒng)，通過(guò)Rancher 還可以做到系統(tǒng)的滾動(dòng)升級(jí)，不需要停機(jī)也可以做到系統(tǒng)升級(jí)。后續(xù)如果需要對(duì)系統(tǒng)服務(wù)再次升級(jí)改造時(shí)，只需要選擇對(duì)應(yīng)的服務(wù)進(jìn)行升級(jí)即可，這樣就可以做到業(yè)務(wù)和技術(shù)同時(shí)不斷迭代更新，不會(huì)再產(chǎn)生新的遺留系統(tǒng)。

4 DevOps平臺(tái)搭建

通過(guò)Vmwear 平臺(tái)，虛擬出一臺(tái)4 核8 G 的Centos7 主節(jié)點(diǎn)和兩臺(tái)4 核8G 的Centos7 從節(jié)點(diǎn)，構(gòu)建了基于Rancher 的DevOps 平臺(tái)。將基于Racher的DevOps應(yīng)用到智慧校園下的統(tǒng)一身份認(rèn)證平臺(tái)和智慧校園建設(shè)中的智慧迎新項(xiàng)目（由迎新遺留系統(tǒng)迭代演變而來(lái)），驗(yàn)證平臺(tái)的可行性。具體環(huán)境配置如表1所示。

表1 環(huán)境配置

通過(guò)Jenkins 安裝好Git、SonarQube Scanner、Shell 等相關(guān)的插件，構(gòu)建一個(gè)Maven 的項(xiàng)目，配置從Gitlab 拉取代碼并設(shè)置鉤子，當(dāng)開(kāi)發(fā)人員提交代碼時(shí)會(huì)觸發(fā)鉤操作，在Jenkins定義構(gòu)建shell腳本，通過(guò)自定義腳本，對(duì)代碼進(jìn)行編譯、打包，再通過(guò)Docker-compose 根據(jù)預(yù)先編寫(xiě)好的Dockerfile 構(gòu)建程序的Docker 鏡像，完成后通過(guò)Post Steps 發(fā)送通知給Rancher，并將代碼發(fā)送到SonarQube 對(duì)項(xiàng)目代碼進(jìn)行審查，SonarQube 會(huì)自動(dòng)發(fā)送檢測(cè)報(bào)告郵件給提交者。Rancher 接收到Jenkins 的通知后，根據(jù)預(yù)先設(shè)定好的命令對(duì)容器進(jìn)行更新啟動(dòng)。雖然實(shí)驗(yàn)過(guò)程遇到不少挫折，如安裝Rancher 集群時(shí)需要預(yù)先開(kāi)放好端口或者關(guān)閉防火墻，否則集群會(huì)搭建失敗，Jenkins 搭建需要通過(guò)命令預(yù)先修改為國(guó)內(nèi)源，否則會(huì)在初始化階段失敗，導(dǎo)致搭建失敗，最終將兩套代碼部署到平臺(tái)上，部分構(gòu)建過(guò)程日志如圖3 所示，驗(yàn)證了基于Rancher的DevOps的可行性。

圖3 構(gòu)建日志

5 總結(jié)

基于Rancher 的DevOps 平臺(tái)在高校智慧校園建設(shè)過(guò)程中，為遺留系統(tǒng)的改造提供了可行性，節(jié)約改造成本，避免新遺留系統(tǒng)的產(chǎn)生，也讓新系統(tǒng)的開(kāi)發(fā)可以高效交付，快速迭代。通過(guò)平臺(tái)實(shí)現(xiàn)容器化部署、自動(dòng)化運(yùn)維，統(tǒng)一部署環(huán)境，做到一次構(gòu)建到處運(yùn)行，降低部署成本和人工參與的頻率，避免陷入瑣碎且易犯錯(cuò)的盲區(qū)。通過(guò)平臺(tái)的實(shí)踐使用，為高校在智慧校園建設(shè)中搭建DevOPS和遺留系統(tǒng)的改造提供借鑒。