2013年，我加入了聚美優(yōu)品，當時成都團隊僅有四五個人，負責一些輔助系統(tǒng)的日常運維，比如查查日志等。隨著公司規(guī)模逐漸的擴大，一些重要的業(yè)務往成都遷移，這對成都團隊是一個非常大的挑戰(zhàn)。業(yè)務部署最開始是手工的，我們逐漸覺得應該有一個平臺來滿足我們的工作，所以我們打造了一個運維平臺。
本文將圍繞平臺里有關(guān)自動化的東西做一個介紹，當然我們是一個小團隊，不足的地方請大家指正。
傳統(tǒng)運維帶來的坑
說到運維自動化，前兩年還是比較炙手可熱的話題。先說一下傳統(tǒng)運維的痛點和運維自動化的意義。我們?nèi)粘＿\維工作是比較繁瑣的，一些研發(fā)同學會經(jīng)常讓我們幫他們到服務器上查一下日志、或者是說今天上線一個東西陪他們加一下班部署下環(huán)境。這些瑣事的事情充斥在我們的大部分工作，導致整個運維的部門產(chǎn)出不高。
還有一個關(guān)于標準的問題，這個問題讓我們吃了很大的虧，早期聚美內(nèi)部因為部署習慣千差萬別，導致一些項目不可維護，誰去動，誰就死。2014年北京那邊負責訂單的同事離職，把訂單系統(tǒng)的運維工作交接到成都這邊來，我們當時面臨“雙十一”的上線，我們經(jīng)常兩三個通宵的搞，相當痛苦的。傳統(tǒng)運維模式還有會帶來效率的問題。到服務器上執(zhí)行命令和部署程序的效率很低，并且非常容易出錯，出錯之后也不太好排查問題，浪費很多的時間。效率問題就引申出成本的問題，我們云服務器是從提供商那里購買的，需要花很多的時間準備運行環(huán)境、上下線，這對公司來說是不小的開支。
我們希望按點下班，陪陪家人什么的。我們運維工程師有一個習慣，電腦喜歡用多個顯示器，窗口管理器也喜歡使用平鋪的，這樣子看上來好象挺牛，但是做的是很雜的一些工作，沒什么效益。我們做自動化運維平臺的話，就能夠把日常遇到的這些個問題給解決掉。
運維自動化的演進
現(xiàn)在說一下運維自動化的演進過程：一開始并沒有專門的工具為我們做這些事情；后來逐漸有了運維自動化的一些工具，比如說Bcfg2、Puppet、SaltStack等；最后打造出一個運維自動化的平臺。
圖1 運維自動化的演進過程
說到工具，確實為我們提供一些提高效率的方法，但還給我們帶來了一些其他的問題，比如聚美早期時候采用Bcfg2＋Fabric作為服務器部署的工具，由一兩個核心的運維負責到主控的機器上采用命令行的方式執(zhí)行操作，這時效率同樣是很低的，而且隨著運維工作量的增多，所有的工作都要丟到一兩個人的身上，就很不方便。但如果把權(quán)限開放出來，對運維操作的權(quán)限沒有任何限制也不利于審計。
還有一個問題，F(xiàn)abric執(zhí)行時執(zhí)行輸出刷屏不好定位問題，比如說執(zhí)行20臺，可能有19臺在真正執(zhí)行，有1臺沒有執(zhí)行，輸出內(nèi)容就一閃而過，沒有很好的反饋，這時我們將機器上線就會出錯。我們需要用平臺把這個問題給規(guī)避掉。
資產(chǎn)系統(tǒng)是運維自動化的基石
說到運維自動化的話，有一個東西是必須要說的，就是咱們的資產(chǎn)系統(tǒng)，這是運維自動化的基石。
資產(chǎn)系統(tǒng)為運維提供一些基礎(chǔ)的信息，比如說機器是屬于哪一個項目的、這個機器是運行在什么樣的環(huán)境。還有一些描述機器的屬性，包括IP地址、IPMI管理地址、機器的類型，運維人員信息、所在的機柜、所連接交換端口。有了這些信息在機器出問題的的情況，可以讓機房協(xié)調(diào)我們快速找到機器的位置。我們也可以通過這些信息做資產(chǎn)的盤點。
資產(chǎn)系統(tǒng)的信息包括物理信息和邏輯信息。物理信息包括硬件信息和網(wǎng)絡連接的信息，是實實在在存在的信息；邏輯信息需要人工填進去，自動化運維的時候用得到。
圖2 資產(chǎn)系統(tǒng)包括的信息
SaltStack，自動化運維工具
講完資產(chǎn)系統(tǒng)，還要講一個運維自動化的工具——SaltStack。不管使用手工的方式還是使用自動化工具都要熟練的去配置服務器的操作系統(tǒng)、配置各項基礎(chǔ)服務。比如說一些系統(tǒng)優(yōu)化：包括sysctl.conf、ulimit.conf、網(wǎng)卡軟中斷的綁定。還有機器標準化的修改，包括機器locale、服務器時區(qū)、yum（apt）的配置。這些內(nèi)容的標準化可以統(tǒng)一我們服務器的運行環(huán)境，避免出現(xiàn)因為環(huán)境差異導致各種奇葩的問題。除此之外還需要對服務器做一些基礎(chǔ)服務的配置，每個公司都有些自己編寫或者定義的程序需要在每一臺服務器上面運行。比如聚美內(nèi)部有統(tǒng)一登錄認證服務、系統(tǒng)監(jiān)控程序需要在服務器上面安裝部署好。
除了系統(tǒng)配置和一些基礎(chǔ)服務之外，還需要對各個業(yè)務服務熟悉配置。比如說包括負載均衡器：比如LVS、Nginx。還有就是JAVA和PHP等相關(guān)的業(yè)務：比如Tomcat、FPM、PHPServer。PHPServer是我們內(nèi)部的一個RPC服務，所有業(yè)務主線都用這個。
我們使用SaltStack作為自動化運維可以簡化以上一堆服務的配置工作。
自動化運維平臺的運行邏輯
有了資產(chǎn)系統(tǒng)、運維自動化工具這兩個基礎(chǔ)之后，我們就要開始構(gòu)建自動化運維平臺，這個平臺就是把資產(chǎn)系統(tǒng)和運維自動化工具結(jié)合起來。
圖3 自動化運維平臺的運行邏輯
資產(chǎn)系統(tǒng)里面會為平臺提供一些基礎(chǔ)的信息，資產(chǎn)系統(tǒng)與SaltStack有一個信息交互的過程。比方說剛才說到的一些邏輯信息導入到SaltStack的grains里面去，一些物理信息需要使用SaltStack提交到資產(chǎn)平臺。自動化的平臺通過SaltStack的API去執(zhí)行SLS文件，執(zhí)行完了之后，通過SaltStack的returners調(diào)用運維平臺的API將執(zhí)行結(jié)果返回回來。
SaltStack是通過grains獲取資產(chǎn)系統(tǒng)的信息的，在SaltStack的客戶端salt-minion啟動之后，SaltStack的master會收到一個“minion_start”的事件，可以在事件上面綁定一個sync_grains的動作，這個動作使得salt-minion資產(chǎn)平臺拉所要的信息，把這些信息存到grains里面去。通過SaltStack初始化系統(tǒng)的時候我們會引用一個SLS文件，這個文件的內(nèi)容是將SaltStack的grains里面保存的信息提交到資產(chǎn)平臺。
現(xiàn)在來說說平臺調(diào)用SaltStack執(zhí)行的邏輯。一種場景是SaltStack代碼要管理多個項目，常規(guī)的做法是每個項目定一個SLS文件，定義需要初始化的內(nèi)容，這種做法也是可以的，但是對平臺的開發(fā)沒那么方便。我們的設(shè)計是的是無論多少個項目，根據(jù)配置文件來表述這些項目需要初始化的服務，這樣子平臺的話邏輯會變得相對簡單。比如說有一個項目，我們把這個項目要定義的一些東西放到配置文件里面去，比如說它的項目屬性、發(fā)布目錄，還有就是要初始化什么樣的服務，把這些東西通過配置文件組裝起來。初始化的時候不用關(guān)心具體是什么項目，都調(diào)用統(tǒng)一的入口文件deploy。在deploy.sls做一些邏輯，按照配置文件初始化好各個服務整個項目就初始化好了。
SaltStack反饋執(zhí)行效果的邏輯
剛才講了去平臺調(diào)用saltstack的邏輯，現(xiàn)在講一下saltstack把結(jié)果反饋到平臺的邏輯。
圖4 自動化運維平臺的反饋邏輯
這個很簡單的，剛才提到行的時候可能會有一大堆信息輸出到屏幕上，沒辦法跟蹤、定位具體哪一個地方出錯了。我們就把執(zhí)行的結(jié)果，通過調(diào)用平臺的API返回到平臺里面，平臺把返回的結(jié)果存儲到數(shù)據(jù)庫里面去，后續(xù)可以在界面上可以看到每一步執(zhí)行的詳細結(jié)果，并且可以根據(jù)執(zhí)行的一些信息做一些審計的工作。
SaltStack部署方法
運維自動化平臺以穩(wěn)定性為第一原則。我們之前老的系統(tǒng)為每一個項目新建一個用戶，通過這個用戶來運行FPM進程，而咱們新的平臺一上線的時候，每個跑FPM的機器用戶名都是一樣的，執(zhí)行用戶的改變就導致之前寫的日志沒法寫入了，出現(xiàn)了業(yè)務的故障。所以之后我們將老的系統(tǒng)遷移到新的自動化平臺的時候都需要非常小心。
簡單介紹一下SaltStack用戶部署的方法。部署SaltStack的客戶端salt-minion時候會有一個KEY接收的過程。傳統(tǒng)的做法是是用“salt-key -L”命令看一下哪些機器已經(jīng)注冊到平臺中，然后再使用“salt-key -a”把key接收進來。在咱們的平臺中這個過程是自動的，我們通過reactor的機制來實現(xiàn)的。具體為：機器注冊進來之后有一個“salt/auth”的事件，我們把給個事件綁定一個動作，然后在這個動作里面檢查key是預定義的來決定是否讓這個機器來注冊到salt-master上面。如果salt-minion的機器配置目錄被刪除了，salt-minion重啟之后不會注冊到salt-master 上面。這時我們只需要在salt-minion的機器上重新跑下配置salt-minion的配置腳本，將統(tǒng)一的KEY下發(fā)給它就可以保證salt-minion能夠重新被salt-master接受。
打造運維自動化平臺遇到的問題
說一下初始化業(yè)務環(huán)境的時候，遇到的一些問題。
圖5 打造運維自動化平臺過程中遇到的坑
先說資產(chǎn)信息的頻繁變更，比如說這個機器可能覺得數(shù)量比較多之后，將機器挪到其他項目上去，此時salt-minion 里面記錄的grains還是之前項目的信息。出現(xiàn)這種情況需要我們在每次對機器執(zhí)行初始化等操作的時候先給他綁定同步資產(chǎn)信息的動作。
還有一個是大量添加機器的刪除的問題，比方說大促的時候兩千臺機子，大促完了之后會把機器給下掉，此時salt-master 接收的機器不會被刪除，會有很多冗余的信息。我們目前想到的辦法是通過cron把salt-master上面的機器列表拿出來ping一下，如果能ping通的就保留在salt-master上面，不能ping通的機器則使用“salt-key -d ”命令給刪除掉。還有是一個“max open file”的問題，通過saltstack重啟的服務，重啟之后進程的“max open file”變成了默認的1024，此時我們需要定制下這些服務的啟動腳本，在里面加入“ulimit -n 65535”等內(nèi)容。
展望
最后，自動化運維平臺后面會往容器或者是微服務的方向過渡，而傳統(tǒng)的自動化方式對我們來說就沒那么重要，我們現(xiàn)在也在做這方面的工作，因為我們公司內(nèi)部有一些使用FPM的項目，對單個節(jié)點效率要求也不太高，放在容器里面運行比較合適，我們也在使用Kubernetes加上Docker做我們下一步的部署方案，但現(xiàn)在只是一個初期階段。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領(lǐng)域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標題：詳解自動化運維平臺的構(gòu)建過程
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839320287.html
相關(guān)文章
