文/魏海濤

自動化批量部署管理的實踐

文/魏海濤

努力提高物理服務器環(huán)境下的自動化部署效率和可控管理能力，一直是運維開發(fā)人員不斷追求的目標。隨著新華社“媒體融合發(fā)展項目”的不斷推進，在統(tǒng)一運維體系模式下，基礎平臺環(huán)境的建設在實際工作中面臨著為上層業(yè)務應用系統(tǒng)提供基礎環(huán)境支撐的任務，承擔了近千臺物理服務器節(jié)點的部署和運維工作，急需解決操作系統(tǒng)自動化批量部署和管理，及時響應業(yè)務系統(tǒng)部署需求的難題。

服務器；可控管理；自動化；批量

1.物理服務器部署的痛點

與傳統(tǒng)“豎井式業(yè)務”小規(guī)模運維相比，統(tǒng)一運維體系下規(guī)?；牟僮飨到y(tǒng)部署存在以下幾方面的挑戰(zhàn)：

（1）并存多個系統(tǒng)版本，數(shù)據(jù)和基礎類軟件要求的系統(tǒng)版本較低，適合容器化的應用軟件要求的系統(tǒng)版本較高。

（2）交付界面上移，更加精細化。任務不再是簡單安裝操作系統(tǒng)，而是在統(tǒng)一設計要求下，完成磁盤分區(qū)和掛載、軟件包安裝、網(wǎng)絡設置、NTP時間校對、用戶設置及個性化配置等。

（3）物理服務器部署節(jié)點需求數(shù)量通常在上百臺，網(wǎng)絡環(huán)境復雜，網(wǎng)絡安全域不同，服務器具有多塊網(wǎng)卡。

（4）部署過程中，要能夠監(jiān)控查看每一臺服務器的詳細進度。

（5）對網(wǎng)絡連通、用戶賬戶和軟件包等進行安裝結果驗證。

面對以上挑戰(zhàn)，如果靠人力部署，勢必效率低下，也極易因為人為因素出現(xiàn)配置差錯。

2.自動化部署方案

針對操作系統(tǒng)規(guī)?；渴疬\維的弱點，我們設計了適用于新華社實際環(huán)境的操作系統(tǒng)自動化部署和管理方案：

（1）搭建基于PXE的網(wǎng)絡自動安裝環(huán)境，自定義kickstart（簡稱ks）自動安裝配置文件和shell腳本。

（2）開發(fā)配置管理服務，以服務器設備序列號為索引，將ks中的配置數(shù)據(jù)抽象為參數(shù)進行封裝管理，用于服務器配置管理、配置API查詢等。

（3）開發(fā)監(jiān)控服務，同樣以服務器設備序列號為索引，用于監(jiān)控數(shù)據(jù)上傳、進度監(jiān)控、安裝驗證等。

技術架構如圖1所示。核心為配置管理服務和監(jiān)控服務，由服務器工程師規(guī)劃編制《服務器基礎規(guī)劃表》并上傳至配置管理服務器，目標主機在自動安裝時從配置管理服務器根據(jù)設備序列號加載屬于自己的配置，全程進度上傳監(jiān)控服務器，供服務器工程師瀏覽驗證。

以下為各系統(tǒng)組件的功能描述。

DHCP服務器，為需要安裝操作系統(tǒng)的服務器提供DHCP/BOOTP服務。承擔該任務的為管理網(wǎng)的三層交換機，安裝時在交換機上的對應VlanIf上設置DHCP服務即可。相較于在服務器上配置DHCP服務的傳統(tǒng)方案，在交換機上配置更為穩(wěn)定，也適用于跨網(wǎng)段的批量服務器安裝。

TFTP服務器，對應DHCP服務器上的next-server配置，提供最小啟動鏡像的下載服務，承擔該任務的為中控服務器。依賴操作系統(tǒng)的xinetd服務對tftp服務進行管理。將CentOS 6和CentOS 7等不同操作系統(tǒng)版本的最小啟動鏡像文件分開存放，實現(xiàn)不同操作系統(tǒng)的同時自動化安裝。

HTTP Web服務器，對應TFTP服務器上的ks配置文件URL，提供ks配置文件以及操作系統(tǒng)rpm軟件安裝包的資源下載服務，承擔該任務的為中控服務器。將CentOS 6和CentOS 7等不同操作系統(tǒng)版本的ks文件和rpm包分開存放。相較于傳統(tǒng)方案，根據(jù)配置自動化設計，我們在這里增加了靜態(tài)路由、磁盤分區(qū)等配置文件的下載。

配置管理服務器，為安裝人員提供服務器配置管理操作，提供Excel格式的配置文件上傳和瀏覽功能，該部分為單獨開發(fā)實現(xiàn)，承擔該任務的為中控服務器。

監(jiān)控服務器，為安裝人員提供服務器安裝部署實時監(jiān)控服務，該部分為單獨開發(fā)實現(xiàn)，承擔該任務的為中控服務器。

CMDB服務器，服務器配置的最終狀態(tài)記錄數(shù)據(jù)庫。

3.自動化原理與執(zhí)行流程

操作系統(tǒng)安裝自動化的原理是基于PXE和kickstart的網(wǎng)絡自動安裝。在此基礎上，我們以服務器設備序列號為索引，將個性化配置的數(shù)據(jù)抽取出來，封裝為配置管理服務，結合ks配置文件的pre段和post段的自定義Shell腳本，實現(xiàn)個性化配置的自動化部署。

目標主機的安裝執(zhí)行分為兩個階段。

第一階段為目標主機的最小安裝啟動鏡像加載，如圖2所示。目標主機通過支持PXE功能的網(wǎng)卡從DHCP服務器獲取網(wǎng)卡IP、網(wǎng)關、TFTP服務器地址和最小安裝啟動鏡像路徑，然后從TFTP服務器下載啟動鏡像和安裝啟動配置文件，從配置文件中獲取ks文件URL路徑。pxelinux.0為啟動文件（bootfile），pxelinux.cfg/default文件為安裝啟動配置文件，內(nèi)含ks文件URL；vmlinuz為啟動內(nèi)核，initrd.img為掛載文件系統(tǒng)。

第二階段為KickStart方式自動安裝階段，如圖3所示。KickStart安裝方式為我們提供了安裝前（%pre）和安裝后（%post） 2個自定義執(zhí)行階段，允許我們利用這2個階段編寫Shell腳本實現(xiàn)配置自定義。我們將相同部分直接寫在ks文件中，包括軟件安裝包列表、root及公共賬號配置、SELinux和防火墻配置、NTP配置、DNS配置等。對于個性化配置，編寫變量shell腳本調(diào)用配置管理服務，利用pre階段實現(xiàn)磁盤分區(qū)和主機名的配置導入，post階段實現(xiàn)IP、靜態(tài)路由及其他系統(tǒng)初始化配置。兩個階段的所有配置操作均上傳監(jiān)控服務器。

圖3 詳細執(zhí)行流程第二階段

4.配置管理和監(jiān)控服務設計

配置管理和監(jiān)控服務采用nodejs語言編寫，提供配置上傳和瀏覽、配置查詢API、安裝進度監(jiān)控等功能，技術架構如圖4所示。

圖4 配置管理服務技術架構

配置管理服務具有以下幾個特點：

（1）定位為工具類，采用內(nèi)存數(shù)據(jù)庫作為數(shù)據(jù)存儲方式；配置元數(shù)據(jù)包括：服務器序列號、機柜物理位置、操作系統(tǒng)版本、主機名、業(yè)務網(wǎng)卡和帶內(nèi)管理網(wǎng)卡IP（對應于硬件網(wǎng)卡位置，含bonding）、遠程帶外管理卡IP、RAID劃分、磁盤分區(qū)和掛載點，如圖5所示。

圖5 配置列表及詳情頁

（2）為了配合服務器工程師的工作習慣，增加了Excel導入配置的轉(zhuǎn)換適配模塊；

（3）配置查詢接口采用Restful API格式。特別是針對網(wǎng)卡配置查詢進行了詳細設計，包括IP地址、網(wǎng)絡掩碼、子網(wǎng)、網(wǎng)關、網(wǎng)卡名稱等，以應對ks自動安裝過程中的IP地址類查詢，減少shell腳本的文本解析工作。如：

http://[ip]:[port]/api/confs/[serialid]/operateIP

http://[ip]:[port]/api/confs/[serialid]/operateIPNetmask

http://[ip]:[port]/api/confs/[serialid]/operateIP

http://[ip]:[port]/api/confs/[serialid]/operateIPGateway

http://[ip]:[port]/api/confs/[serialid]/operateNic

4.1 安裝實施步驟

操作系統(tǒng)安裝自動化將服務器工程師從繁重的重復勞動中解放出來，只需少量手工操作，從而使其精力更多地集中在配置規(guī)劃設計。

（1）從配置管理服務器下載《服務器基礎規(guī)劃表》模板，借助Excel表格工具對服務器配置進行規(guī)劃設計。

（2）將Excel文檔上傳到配置管理服務器，同時將列表中的服務器加入到待安裝服務器列表。

（3）在目標主機所在管理網(wǎng)當前網(wǎng)段的三層交換機的對應VlanIf上設置DHCP服務配置DHCP服務，開始安裝系統(tǒng)。

（4）通過監(jiān)控服務頁面瀏覽安裝進度（見圖6），同時可以訪問每臺服務器的帶外管理地址，通過打開KVM遠程Console來查看系統(tǒng)安裝情況（見圖7）。

（5）安裝完成后，通過安裝管理界面保存此次安裝過程和結果。

圖6 安裝監(jiān)控頁面

圖7 服務器安裝界面

4.2 實施中的一些經(jīng)驗

盡可能降低業(yè)務系統(tǒng)對基礎環(huán)境的個性化要求，強制約束系統(tǒng)命名規(guī)范、用戶賬號規(guī)范、操作系統(tǒng)版本等，是實現(xiàn)自動化部署和提高可控管理能力的先決條件。為此，我們重點從以下兩個方面對業(yè)務應用系統(tǒng)做出限制。

（1）制定系統(tǒng)部署規(guī)范，保證系統(tǒng)部署的一致性。我們制定了《主機域名和內(nèi)部服務域名命名規(guī)范》、《用戶賬戶和目錄使用規(guī)范》、《操作系統(tǒng)初始化規(guī)范》、《多網(wǎng)卡IP使用規(guī)范》。

（2）強制操作系統(tǒng)基線版本。綜合考慮基礎軟件兼容性、操作系統(tǒng)穩(wěn)定性和官方維護支持期限，我們選用了CentOS6.8和CentOS7.3作為操作系統(tǒng)基線版本。對于數(shù)據(jù)庫、大數(shù)據(jù)等數(shù)據(jù)類軟件，考慮到軟件本身的兼容性和穩(wěn)定性，部署到CentOS6.8，對于移植性較好的Java/J2EE等應用，適合容器化擴展的，部署到CentOS7.3。CentOS官方提供維護支持的操作系統(tǒng)截至日期見表1 。

表1 操作系統(tǒng)官方維護截至日期

5.總結

該解決方案在傳統(tǒng)的自動化部署方案基礎上，根據(jù)新華社媒體融合發(fā)展項目的特點進行了優(yōu)化完善，提高了服務器規(guī)?；渴鸬呐渲霉芾砟芰Γ鰪娏瞬渴鸸芾淼目梢暬炞C。在新華社融發(fā)項目的實踐中，該方案從一定程度上解放了服務器工程師的重復繁重勞動，實現(xiàn)了系統(tǒng)批量安裝自動化，極大地提高了系統(tǒng)部署效率，增強了系統(tǒng)運維管理能力，解決了系統(tǒng)按需按期交付的難題。

[1] Kickstart documentation. http://pykickstart.readthedocs.io/en/latest/

[2] BOOTP. https://en.wikipedia.org/wiki/Bootstrap_Protocol

[3] DHCP. https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

[4] DHCP RFC. https://tools.ietf.org/html/rfc2132

[5] PXE. https://en.wikipedia.org/wiki/Preboot_Execution_Environment

（作者單位：新華社技術局）

TP311

A

1671-0134（2017）10-119-03

10.19483/j.cnki.11-4653/n.2017.10.050