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