ansible的handlers的用法

本身的理解：handlers用來用來解決觸發時間的，也就是當一個tasks真正的執行後，結果發生了變化。會去觸發另外一個task。

現實中的應用場景：

        當咱們修改了某些程序的配置文件之後，有可能須要重啓應用程序，以便可以使新的配置生效，那麼，物品，麼如何使用playbook？

例子：加入咱們要修改server的端口從80改爲8080，而且在修改配置以後重啓nginx。劇本以下：

那麼想一想若是咱們不加上handlers的效果，不加handlers，修改配置的task和重啓服務的task並無邏輯性，依賴性。第一次執行這個playbook不會有什麼問題，當第二次執行時，會發現根據冪等性特性修改配置文件的task並無執行，而重啓服務的task仍是會執行，顯然這是不合理的，咱們要求是隻有配置文件發生變化以後再重啓服務。

針對handlers的理解：

handlers能夠理解成另外一種tasks，handlers是另外一種’任務列表‘，handlers的任務會被tasks中的任務進行」調用「，可是，被」調用「並不意味着必定會執行，只有當tasks中的任務」真正執行「之後，handlers中被調用的任務纔會執行，若是tasks中的任務並無作出任何實際的操做，那麼handlers中的任務即便被’調用‘，也並不會執行。

如上所說，handlers是另外一種任務列表，能夠理解handlers和tasks是’平級關係‘，因此他們的縮進相同，上面的handlers中只有一個任務，任務的名稱爲restart nginx，這個名詞被tasks中的modify the configuration這個任務調用了，notify字段就是調用handlers任務，當modify the configuration這個任務執行以後併發生了改變，就會去執行handlers中的相應的任務。

handlers是另外一種任務列表，因此handlers中能夠有多個任務，被tasks中不一樣的任務notify，以下：

如上所示，tasks和handlers都是任務列表，只是handlers中的人物被tasks中的任務notify罷了，那麼咱們來執行一下上述playbook，以下圖因此：

從上圖看出，handlers執行的順序與handlers在playbook中定義的順序是相同的，與handlers被notify的順序無關，默認狀況下，全部的task執行完畢後，纔會執行各個handles，並非執行完某個task後，當即執行相應的handler，若是想要在執行完某些task之後當即執行對應的handlre，那麼須要使用meta模塊。

結果顯示順序： task1--->task2--->handler1--->handler2--->task3--->handler3.