Fabric中怎么批量管理遠(yuǎn)程服務(wù)器

• SerialGroup(*hosts, **kwargs)：按串行方式執(zhí)行操作
• ThreadingGroup(*hosts, **kwargs)：按并發(fā)方式執(zhí)行操作

下面先看看這個(gè)基類：

 

• Group 繼承了 list，所以能夠 extend() ，對(duì)傳入的服務(wù)器分別建立 connection
• 核心的 run() 方法沒有寫實(shí)現(xiàn)，用意是留給子類再實(shí)現(xiàn)
• 最后的 __enter__() 和 __exit__() 實(shí)現(xiàn)了上下文管理器

有了這個(gè)基類，接下來就要看 SerialGroup 和 ThreadingGroup 的具體實(shí)現(xiàn)了。

 

SerialGroup 類很簡(jiǎn)單，只實(shí)現(xiàn)了一個(gè) run() 方法。因?yàn)轭愒诔跏蓟瘯r(shí)為所有 host 建立了連接而且存了起來，所以這里只需用 for 循環(huán)依次取出，再執(zhí)行 Connection 的 run() 方法。

這里可以看到一種非常實(shí)用的開發(fā)技巧：創(chuàng)建類時(shí)，讓它繼承內(nèi)置的數(shù)據(jù)結(jié)構(gòu)（如 list、dict）， 這樣可以直接使用  self.append()、self.extend()、self.update() 等方法把關(guān)鍵的信息存到“自身”，再到取出時(shí)則“for xxx in self”，這樣就免了創(chuàng)建臨時(shí)的 list 或 dict，也免得要在參數(shù)中傳來傳去。

GroupResult 和 GroupException 是對(duì)執(zhí)行結(jié)果和異常的處理，不是我們關(guān)注的重點(diǎn)，這里略過。

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

 

ExceptionHandlingThread 是一個(gè)繼承了 threading.Thread 的類，這是一種創(chuàng)建多線程的方式。每個(gè)線程執(zhí)行的方法主要做兩件事：執(zhí)行 connection 的 run() 方法，以及將執(zhí)行成功的結(jié)果存入隊(duì)列中。

 

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

所以，F(xiàn)abric 是使用了 threading 多線程的方式來實(shí)現(xiàn)并發(fā)。網(wǎng)絡(luò)請(qǐng)求是 IO 密集型的，使用多線程是不錯(cuò)的方式。

至此，對(duì)于我們?cè)陂_頭提的問題，就有了一個(gè)初步的答案：Fabric 封裝了兩種 Group 來批量管理服務(wù)器，其中串行方式就是用了簡(jiǎn)單的 for 循環(huán)，而并發(fā)方式使用了 threading 多線程方式。

• Group 只實(shí)現(xiàn)了 run() 方法，但是 Connection 的 put()、get()、sudo() 等方法都沒有，這意味著用這種方式管理服務(wù)器集群時(shí)，只能在上面執(zhí)行 shell 命令……
• 每次調(diào)用 run() 方法時(shí)，它要等所有主機(jī)都執(zhí)行完，才會(huì)返回結(jié)果，這意味著先執(zhí)行完的主機(jī)會(huì)被阻塞。更為致命的是，如果其中一臺(tái)主機(jī)執(zhí)行時(shí)出了異常，整個(gè) run() 方法就拋異常，這意味著每次使用 run() 方法時(shí)，都需要作異常捕獲
• run() 方法支持執(zhí)行單條 shell 命令，但是命令的狀態(tài)不會(huì)傳遞。假設(shè)先在一個(gè) run() 方法中運(yùn)行 cd 命令切到 A 目錄（非根目錄），再在下一個(gè) run() 方法創(chuàng)建一個(gè)文件，最終結(jié)果是該文件并不在 A 目錄，而是在默認(rèn)目錄。解決辦法是用“&&”連接起多條命令，略顯麻煩