Fabric 源碼學習：如何實現批量管理遠程服務器？

前不久，我寫了一篇《Fabric教程》，簡單來講，它是一個用 Python 開發的輕量級的遠程系統管理工具，在遠程登陸服務器、執行 Shell 命令、批量管理服務器、遠程部署等場景中，十分好用。

Fabric 2 是其最新的大版本，跟早前的 Fabric 1 有挺大的不一樣，更加好用了，可是沒填上的坑也挺多的……

本文繼續來聊聊 Fabric，不過我不想再面面俱到了，而是專一於這一個話題：它是如何實現對批量服務器的串行/併發管理的？

（友情提示：爲了有更好的閱讀體驗，若是你還不瞭解 Fabric 的基礎用法，建議先閱讀前面的教程。）

Fabric 經過 Group 來組合多臺服務器。區別在於由 fabric.group.Group 基類（父類）派生出的兩個子類：

• SerialGroup(*hosts, **kwargs)：按串行方式執行操做
• ThreadingGroup(*hosts, **kwargs)：按併發方式執行操做

下面先看看這個基類：

我把一些沒用的信息摺疊了，比較值得注意的內容有：

• Group 繼承了 list，因此可以 extend() ，對傳入的服務器分別創建 connection
• 核心的 run() 方法沒有寫實現，用意是留給子類再實現
• 最後的 __enter__() 和 __exit__() 實現了上下文管理器

有了這個基類，接下來就要看 SerialGroup 和 ThreadingGroup 的具體實現了。

SerialGroup 類很簡單，只實現了一個 run() 方法。由於類在初始化時爲全部 host 創建了鏈接並且存了起來，因此這裏只需用 for 循環依次取出，再執行 Connection 的 run() 方法。

這裏能夠看到一種很是實用的開發技巧： 建立類時，讓它繼承內置的數據結構（如 list、dict）， 這樣能夠直接使用 self.append()、self.extend()、self.update() 等方法把關鍵的信息存到「自身」，再到取出時則「for xxx in self」，這樣就免了建立臨時的 list 或 dict，也省得要在參數中傳來傳去。

GroupResult 和 GroupException 是對執行結果和異常的處理，不是咱們關注的重點，這裏略過。

接下來看看 ThreadingGroup，它也只有一個 run() 方法：

ExceptionHandlingThread 是一個繼承了 threading.Thread 的類，這是一種建立多線程的方式。每一個線程執行的方法主要作兩件事：執行 connection 的 run() 方法，以及將執行成功的結果存入隊列中。

接下來再分別把執行成功的結果與出異常的結果都存入到 results 中。

因此，Fabric 是使用了 threading 多線程的方式來實現併發。網絡請求是 IO 密集型的，使用多線程是不錯的方式。

至此，對於咱們在開頭提的問題，就有了一個初步的答案：Fabric 封裝了兩種 Group 來批量管理服務器，其中串行方式就是用了簡單的 for 循環，而併發方式使用了 threading 多線程方式。

可是，經過分析這兩種 Group 的實現代碼（以及使用的實踐），咱們也能夠發現 Fabric 的缺陷：

• Group 只實現了 run() 方法，可是 Connection 的 put()、get()、sudo() 等方法都沒有，這意味着用這種方式管理服務器集羣時，只能在上面執行 shell 命令……
• 每次調用 run() 方法時，它要等全部主機都執行完，纔會返回結果，這意味着先執行完的主機會被阻塞。更爲致命的是，若是其中一臺主機執行時出了異常，整個 run() 方法就拋異常，這意味着每次使用 run() 方法時，都須要做異常捕獲
• run() 方法支持執行單條 shell 命令，可是命令的狀態不會傳遞。假設先在一個 run() 方法中運行 cd 命令切到 A 目錄（非根目錄），再在下一個 run() 方法建立一個文件，最終結果是該文件並不在 A 目錄，而是在默認目錄。解決辦法是用「&&」鏈接起多條命令，略顯麻煩

這幾個問題在 Fabric 的 Github issue 中，被不一樣的人反覆提出，可是尚未獲得很好的迴應……

言歸正傳，本文主要分析了 Fabric 在批量管理服務器時的實現方案，閱讀其源碼，能夠了解到串行/併發典型場景的用法，以及類定義、類繼承、多線程、異常處理等內容，最後，咱們還揭示出了它的幾個特性缺陷。

感謝閱讀。最後，附上 Fabric 教程：https://mp.weixin.qq.com/s/UHtPaxO2ojql5ps4hTn3Vg