上次給大家介紹了ansible的基礎命令，一些基本的常用模塊，今天就給大家帶來ansible的進階版本，playbook，以及roles的使用。
首先我們要知道我們的ansible的playbook是什麼？playbook就是劇本的意思，用於配置，部署，和管理被控節點，劇本怎麼寫，操作怎麼執行，很容易理解。
通過playbook的詳細描述，執行其中的一系列tasks，可以讓遠端主機達到預期的狀態。playbook就像Ansible控制器給被控節點列出的的一系列to-do-list，而被控節點
必須要完成。
首先我們先介紹一下ansible playbook的格式。
1 YMAL格式是類似於JSON的文件格式，
2 文件的第一行應該以 "---" (三個連字符)開始表明YMAL文件的開始;
3 在同一行中，#之後的內容表示註釋，類似於shell，python和ruby;
4 YMAL中的列表元素以”-”開頭然後緊跟着一個空格，後面爲元素內容;
5 同一個列表中的元素應該保持相同的縮進。否則會被當做錯誤處理。
既然是YMAL格式的文件，後綴就理所當然的爲yml，所以在yml文件中，主要有三個部分組成：hosts、remote_user、tasks。
hosts：使用hosts指示使用哪個主機或主機組來運行下面的tasks
remote_user：指定遠端主機中的哪個用戶來登錄遠端系統
tasks：指定遠端主機將要執行的一系列動作，tasks的核心爲ansible的模塊，前面已經提到模塊的用法。tasks包含name和要執行的模塊，name是可選的，只是爲了便於用戶閱讀，不過還是建議加上去，模塊是必須的，同時也要給予模塊相應的參數
除上面一些主要之外，還有tags和notify、handlers，tags是打標籤，而後可在ansible-playbook命令上使用-t指定進行調用，tags在哪，劇本從哪裏開始；某任務的狀態在運行後爲changed時，可通過“notify”通知給相應的handlers。
這樣以介紹是不是感覺對playbook的格式有了大致的瞭解了呢？
下面我們來介紹一下，關於playbook執行後得到的輸出信息，可以用來幫我們判斷成功與否。
一般而言
l 綠色代表執行成功，系統保持原樣
l ×××代表系統代表系統狀態發生改變
l 紅色代表執行失敗，顯示錯誤輸出。
執行有三個步驟：1、收集facts 2、執行tasks 3、報告結果
之後是關於變量的一些定義和使用，和shell一樣，有系統變量和自定義變量，但當我們使用變量是可以使用{{ VAR }},記得要在兩邊有空格，定義的方式有4中。
(1) facts：可直接調用；注意：可使用setup模塊直接獲取目標主機的facters；
(2) 用戶自定義變量：
(a) ansible-playbook命令的命令行中的
-e VARS, --extra-vars=VARS
(b) 在playbook中定義變量的方法：
vars:
- var1: value1
(3) 通過roles傳遞變量；
(4) Host Inventory
(i) 向不同的主機傳遞不同的變量；
IP/HOSTNAME varaiable=value var2=value2
(ii) 向組中的主機傳遞相同的變量；
[groupname:vars]
variable=value
運行playbook的方式：
(1) 測試
ansible-playbook --check 只檢測可能會發生的改變，但不真正執行操作；
ansible-playbook --list-hosts 列出運行任務的主機；
(2) 直接運行
下面我們做一下playbook的小實驗，給兩臺下屬主機，安裝nginx，並且，當檢測到nginx配置文件更改後，重啓服務，此實驗共三臺主機，只需要一臺安裝ansible即可。
首先要定義兩個主機爲一個web組內，vim /etc/ansible/hosts
[web]
172.17.254.112
172.17.254.113
其次，生成密鑰，發送給其他兩個主機，實現無密登錄(具體操作可以瞅瞅我的ansible的基本知識詳解。
然後我們就要做一個yml的劇本了，內容如下：
新版博客的縮進不是很方便，我就直接放了一張圖，這是從安裝，到啓動，到拷貝本機的修改文件到其他機器，然後根據notify觸發handlers，重啓nginx服務。
然後聽過ansible-playbook test.yml執行，結果應該如下：
至此我們的playbook的編輯到結束已經完成，只要我們制定好hosts，然後定義一下，方便我們以後看的name，再之後就是我們的動作，利用各個模塊，來做好一件大任務！
playbook雖然看起來挺方便的，但是有個弊端就是無法實現複用假設在同時
部署Web、db、ha 時或不同服務器組合不同的應用就需要寫多個yml文件。很難實現靈活的調用。
roles應運而生，roles 用於層次性、結構化地組織playbook。roles 能夠根據層次型結構自動裝載變量文件、tasks以及handlers等。
與其說playbook把所有的模塊功能，集合一起做事情，對於相同的事件，或者不復雜任務，可以勝任，roles就是把模塊又拆了出來，哪一塊都可以隨時替換，應對各種複雜情況。
文件目錄結構：
roles/nginx/
├── default
├── files
├── handlers
│ └── main.yml
├── meta
├── tasks
│ └── main.yml
├── templates
└── vars
└── main.yml
這是我把剛纔那個實驗用roles來做的目錄結構圖，vars明顯是變量，我們定義了一個變量，tasks是任務，handlers，是當notify觸發時的一些任務，當然我們還要有yml劇本，這個劇本里可以寫入我們的角色。
nginx.yml
roles/nginx/handlers/main.yml
roles/nginx/tasks/main.yml
roles/nginx/vars/main.yml
上面就是我們的定義的文件，當我們使用nginx.yml啓動時，發現和剛纔一樣的效果，不過當我們的變量需要改變，或者tasks改變時，我們就直接找到對應的文件，直接修改，而不是一行行的去找整個劇本，還要通讀一遍。