開源與自研：自動化運維平臺從0到1的三段式探索

天府雲創發表於2018-01-11

運維

本文根據DBAplus社群第133期線上分享整理而成。俗話說利用開源可以避免重複造輪子，自研是當開源已經滿足不了實際的業務需求的時候就要自行程式設計開發。兩者的共同目標就是實現自動化目的。

講師介紹

隨著業務規模的逐漸增大，IT運維的環境變得龐大而複雜。傳統的運維手段已無法滿足我們的要求，而自動化運維能把週期性、重複性、規律性的工作交給平臺去處理，通過標準化、自動化、過程優化來降低運維成本，從而提高運維效率。

當前市場上有不少商業和開源的運維產品工具，各有特色也各有利弊，這造成一個尷尬局面：產品工具很多，卻很難找出一個可以很好適應自身企業持續變化的需求的產品。畢竟不同的企業其管理規模、實施環境和安全規定都不盡相同。

本文主要圍繞我們在建設自動化運維平臺的過程中所遇到的困難挑戰和踩過的坑，並就開源和自主研發的方向選擇聊聊我們在嘗試過程中的看法和做法。

我們的平臺建設主要分為以下三個階段：

基於Ansible的嘗試驗證

當時內部其它部門有使用Ansible來做一些場景的運維操作的經驗，並在此累積了一定量的運維指令碼庫，有複用的價值。同時Ansible也是一款非常優秀的工具，具備以下優點：

SSH by default ：安全，agentless無需安裝客戶端
配置簡單、功能強大、擴充套件性強
通過Playbooks來定製強大的配置、狀態管理
Stupied Simple：上手簡單，學習曲線平滑

基於以上考慮，我們初步選定了Ansible作一個嘗試。這裡用圖例描述下Ansible的工作機制：

但在驗證階段，發現Ansible在場景應用壓測上暴露了下面的缺點：

效率不高，容易掛起，不太適合中大規模環境（例如500臺以上）的應用
難以進行大批量的耗時業務操作。

我們通過求助並不斷嘗試去優化效能，期望能支撐起中大規模的託管裝置量。但針對一些複雜的場景應用，特別是耗時的操作，效率還是無法接受。

Ansible暫不能很好地滿足中大型規模的運維管理場景。當然，在百臺以內的環境，使用Ansible做一些小規模的簡單運維場景，還是有它的優勢：非常簡潔，基於SSH，容易落地。

小插曲過後，經過一段時間的重新選型和驗證，我們敲定了使用SaltStack來作為我們的技術選型。

基於SaltStack全而穩的快速建設階段

相比Ansible的小巧，SaltStack更加大而全，同時在應用上也更加靈活，可以輕鬆應對更加多複雜的場景。

SaltStack的master和minion通過ZeroMQ傳輸資料，而Ansible是預設通過標準ssh進行資料傳輸。得益於架構上的差異，SaltStack的響應速度要比Ansible快很多，同時ZeroMQ也起到了很好緩衝的作用。

SaltStack的非同步執行模式可以很好地應對上千臺裝置（甚至更多）的任務執行，特別適合耗時場景的應用。下面是SaltStack的簡單通訊架構圖：

在此後時間，我們主要投入開發擴充套件模組以實現一些常用的運維場景，同時也改造了SaltStack的入庫邏輯，把相關的event等資料轉換為我們需要的資料寫入儲存中。

平臺開發過程中一切順利，很快進入了上線階段，這裡描述下上線背景：

託管裝置規模龐大，超5000臺以上
所有託管裝置不能通過ssh進行通訊，22埠對外是被禁用的，且使用者的密碼是定期變更。
僅且只能基於某指定埠進行通訊

基於以上特殊要求，我們的接入方案是：所有託管機器都統一安裝minion，基於埠通訊；通過我們研發的WEB統一管理平臺來批量部署和升級等管理。

上線初期，我們根據業務劃分的順序進行納入管理，很快接入了大量的主機，一切看起來進行得比較順利。但在接入一個老業務平臺的時候，我們遇到了困難：處理平臺的相容性比我們預想的複雜得太多。

（1）裝置繁雜

形色各異的伺服器，有IBM小機、SUN伺服器、HP伺服器、浪潮伺服器等。還存在大量的網路裝置（路由器、交換機等）需要託管。

（2）系統平臺標準雜亂

作業系統版本混亂，存在了大批量的AIX5、AIX6、SunOS、HP-Unix、RedHat5、PowerLinux、Window(Server 2000、2003、2008等)等系統平臺。

（3）許可權認證

很多裝置不提供Root管理員許可權，agent更是不允許以Root執行。

（4）禁止外網訪問的區域網

導致的結果是我們的minion無法安裝，在官網中，我們找到了SaltStack支援的所有平臺的列表：

期間，我們嘗試與運維團隊負責人溝通，是否可以升級作業系統的版本，調整部分安全的規定，負責人表示很理解但也很無奈，安全規定無法改變。

此時,我們更深刻認識複雜的IT環境、歷史負擔是必須首要面對的問題，很多在網際網路中玩得轉的方案，在這個環境裡面變得步步艱辛，難以推進。

同時許可權管控也是一個大問題，部分實施環境對託管主機agent執行的許可權更加嚴格，資源訪問上也更加嚴格，有大量切換使用者增強許可權的方式來進行運維操作。

一路走來，深感不易，作為技術通用型的代表，基於開源運維管理技術（Ansible、SaltStack等）的產品工具多多少少都存在著某方面的侷限性，無法涵蓋不同行業的企業需求，不能很好適應不同行業的特殊實施環境。

基於上述經驗的累積，我們的意見愈發統一：要很好地解決這些問題，或者說要把主動權握在自己手中，必須得走上開源+自主研發整合的道路。

基於開源並整合自主研發應需而變的平臺建設階段

一路磕碰，一路踩坑的同時也為我們在建設自動化運維平臺提供了最真實的反饋，讓我們得以不斷調準方向。

平臺建設方向

目前我們正處於開源整合自主研發階段，已無需再去論證這樣做是否正確、是否有必要，實踐已出真知。吸收經驗後，平臺的建設方向明確了以下幾點：

（1）開源整合自主研發

擁抱開源，針對不可控和無法滿足的部分，我們進行了自主研發，最後整合開源以滿足實施環境的需求。

（2）平臺部署能應需而變

針對託管裝置既能以agentless也可以以agent的模式，要能很好地應對複雜的網路拓撲要求。支援分散式叢集部署，能快速地擴容以支撐海量的託管裝置。

（3）agent必須支援以下系統平臺，並能以非Root使用者執行

linux/unix/ aix (aix5/6/7)/windows/ppc等。

我們自主研發的agent，增加了對AIX5、AIX6、SunOS、HP-Unix、Power Linux、Windows Server(2000及以上)等系統的支援，彌補SaltStack在系統支援上的不足。

在操作執行過程中，可以支援使用者切換增強許可權，避免直接以Root執行agent，許可權過大。

（4）提供完備的憑證管理

例如針對上面提及的伺服器使用者密碼定期更換這個情況，需要細化到支援每臺託管裝置的憑證更新管理，方便使用者使用。

（5）提供統一管理web平臺，批量安裝和升級等管理。

（6）提供統一易用的運維API給上層業務，上層業務無需關注底層實現。

平臺簡述

整合後的自動化運維平臺分為三層：業務層、運維管理層、託管層，如下圖：

業務層：指各個運維業務的合集。運維業務呼叫運維API，通過運維管理層進行運維操作
運維管理層：運維管理層並不涉及任何的業務邏輯，只提供通道和任務分派、結果回傳處理。
託管層：被託管的伺服器、網路裝置、中介軟體、資料庫等。

平臺提供了以下常用的運維場景：

應用安裝：Tomcat、Weblogic等中介軟體的安裝；MySQL、Oracle等資料庫的安裝。
配置管理：日常運維涉及的一些配置檔案管理，例如基線對比、批量更新等。
執行監控：監控相關程式的執行狀態，例如Zabbix的執行狀態檢測等。
定時排程：支援定時排程，任何操作/作業編排都可定時執行。
日常運維：登入伺服器、單機、批量等日常運維巡檢操作，支援流程編排。
…

平臺的基本操作流向：

平臺的運維基本單位是“操作”，通過定時排程+資源+操作可以組合成不同的巡檢或者流程編排。巡檢和編排最後通過解析轉化為具體的作業任務。作業任務由agent或者代理agent解析後執行。

“操作”支援版本管理和流程稽核，此外平臺還提供了更加細緻的許可權控制和分級管理。根據業務需要可以指定操作執行使用者，提供許可權增強。

為了彌補minion在相容性上的不足，我們研發了自己的agent端。

自研agent的設計理念

為應對複雜多變的運維業務，在agent設計上我們一致認同：原子化的外掛式功能模組是基本，穩定高效的通道是保障。

只有擁有大量原子化的外掛式功能元件，才能大規模重用和組裝。每一個上層的運維業務都可以分解成原子化的操作集合。
業務運維的操作組合是無限的，原子化的元件是有限的，原子化後更加方便管理維護，從而提供穩定可靠的服務。
穩定高效的通道是整個平臺可靠執行的最重要的保障。要求能接入上萬臺規模的裝置。

agent的核心功能可以總結為兩大塊：管控通道和外掛服務呼叫。

管控通道：所有的運維操作最終都會轉化為命令傳送給snc-agent。這裡會有相應的使用者許可權控制、操作審計、高危命令攔截、流量管控等能力。
原子化服務呼叫：每一個命令組合都會被snc-agent 的解析引擎轉化為最基本的原子操作集合並呼叫執行。

下圖是平臺在生產環境中執行的統計資料，從四個維度展示了整個系統的運算元據量：巡檢、編排、操作和原子任務。

平臺架構

除了相容Ansible和SaltStack環境外，增加了snc-agent叢集環境，用於彌補SaltStack在非主流系統支援上的不足。

下面針對snc-agent描述兩個工作主流程：

snc-agent會有一個預設的配置檔案，啟動後會自動連線到ZooKeeper，在ZooKeeper上維護一個節點，節點中記錄了agent的配置資訊，包括伺服器的ip、硬體等相關資訊。基於該節點可以實時地監控agent的狀態和主機對應的一些不常變化的資訊。
下發命令並執行。業務系統呼叫運維公用API，把命令傳送至訊息佇列。snc-agent從訊息佇列中拉取屬於自己的命令，通過解析引擎分解為最基本的原子操作集合，所有操作執行完畢後，把結果合併後回送到訊息佇列。snc-agent具備流量管控能力，因為不同的裝置其運算能力有所不同，需要針對其效能適當地消費，避免影響生產業務的正常執行。

部署架構