Ansible playbooks

Playbook是Ansible的配置，部署和編排語言。 他們能夠描述您但願遠程系統執行的策略，或通常IT流程中的一組步驟。

若是Ansible modules是您workshop的工具，則playbooks是您的說明手冊，您的主機inventory是您的原材料。

在基本層面上，可使用playbooks來管理遠程機器的配置和部署。 在更高級別，他們能夠對涉及滾動更新的多層次推出進行排序，並能夠將操做委派給其餘主機，與監控服務器進行交互，同時加載平衡器。

雖然這裏有不少信息，可是不須要一次就能夠學習全部的東西。 隨着時間的推移，您能夠開始小型化，隨時隨地選擇更多功能。

playbooks旨在讓人可讀，並以基本的文字語言開發。 能夠經過多種方法來組織playbooks和他們包含的文件，咱們將提供一些建議，並充分利用「可複製」。

建議您閱讀「 Playbook 」文檔，同時閱讀「 示例手冊」 。 這些說明了最佳實踐以及如何將許多各類概念集中在一塊兒。

關於Playbooks

Playbook是一種與adhoc任務執行模式徹底不一樣的方式，並且特別強大。

簡單地說，Playbooks是一個很是簡單的配置管理和多機器部署系統的基礎，不像任何已經存在的那樣，並且很是適合部署複雜的應用程序。

Playbook能夠聲明配置，但它們也能夠協調任何手動訂購過程的步驟，即便不一樣的步驟必須在特定訂單的機器組之間來回彈起。 他們能夠同步或異步地啓動任務。

雖然您能夠運行主/usr/bin/ansible程序來進行自組織任務，可是Playbook更有可能被保留在源代碼管理中，並用於推出配置或確保遠程系統的配置符合規範。

還有一些完整的劇本能夠在ansible-examples存儲庫中說明不少這些技術。 咱們建議您在另外一個標籤中查看這些內容。

在學習劇本以後，還有不少跳躍點，因此在完成本節以後，請回到文檔索引。

Playbook Language Example

Playbook以YAML格式（見YAML Syntax ）表示，並具備最少的語法，它有意嘗試不是編程語言或腳本，而是一個配置或進程的模型。

每一個playbook由一個或多個「plays」組成。

一個play的目標是將一組主機映射到一些明肯定義的roles，由事件可調用的任務表明。 在基本層面上，一個任務只不過是對一個能夠粘貼的模塊的調用（參見關於模塊 ）。

經過編寫多個「plays」的playbook，能夠協調多機器部署，在Web服務器組中的全部計算機上運行某些步驟，而後在數據庫服務器組上執行某些步驟，而後在Web服務器組等上再次執行命令。

「plays」或多或少是體育比喻。 你能夠有不少戲劇影響你的系統作不一樣的事情。 它不像你只是定義一個特定的狀態或模型，你能夠在不一樣的時間運行不一樣的play。

對於初學者來講，這是一個僅包含一個play的playbook：

---
- hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf notify: - restart apache - name: ensure apache is running (and enable it at boot) service: name=httpd state=started enabled=yes handlers: - name: restart apache service: name=httpd state=restarted 

當使用具備很長參數的任務或具備許多參數的模塊時，能夠經過多行將任務項目中斷以改進結構。 如下是上述示例的另外一個版本，可是使用YAML字典爲它們的key=value參數提供模塊：

---
- hosts: webservers vars: http_port: 80 max_clients: 200 remote_user: root tasks: - name: ensure apache is at the latest version yum: name: httpd state: latest - name: write the apache config file template: src: /srv/httpd.j2 dest: /etc/httpd.conf notify: - restart apache - name: ensure apache is running service: name: httpd state: started handlers: - name: restart apache service: name: httpd state: restarted

Playbook能夠包含多個play。 您可能有一個Playbook首先定位到Web服務器，而後是數據庫服務器。 例如：

---
- hosts: webservers remote_user: root tasks: - name: ensure apache is at the latest version yum: name=httpd state=latest - name: write the apache config file template: src=/srv/httpd.j2 dest=/etc/httpd.conf - hosts: databases remote_user: root tasks: - name: ensure postgresql is at the latest version yum: name=postgresql state=latest - name: ensure that postgresql is started service: name=postgresql state=started

您可使用此方法在您要定位的主機組，登陸到遠程服務器的用戶名，是否要sudo之間進行切換。 play，像任務同樣，按照playbook中指定的順序運行：從上到下。

Basics

Hosts and Users

對於Playbook中的每一個play，您能夠選擇您的基礎設施中的哪些機器進行定位，以及什麼遠程用戶完成步驟（稱爲任務）。

hosts行是一個或多個組或主機模式的列表，以冒號分隔，如「 模式」文檔中所述。 remote_user只是用戶賬戶的名稱：

---
- hosts: webservers remote_user: root

還能夠爲每一個任務定義遠程用戶：

---
- hosts: webservers remote_user: root tasks: - name: test connection ping: remote_user: yourname

支持做爲其餘用戶來運行（請參閱Become (Privilege Escalation) ）：

---
- hosts: webservers remote_user: yourname become: yes

您也可使用成爲特定任務而不是整個play：

---
- hosts: webservers remote_user: yourname tasks: - service: name=nginx state=started become: yes become_method: sudo

您也能夠登陸，而後成爲與root不一樣的用戶：

---
- hosts: webservers remote_user: yourname become: yes become_user: postgres 

您還可使用其餘權限升級方法，如su：

---
- hosts: webservers remote_user: yourname become: yes become_method: su
若是須要指定sudo的密碼，請使用或使用舊的sudo語法 （  ）運行 。 
若是你運行成爲playbook，而且playbook彷佛掛起，它可能會停留在特權升級提示符下。 只要控制C來殺死它並再次運行，添加相應的密碼。
您還能夠控制運行主機的順序。 默認是按照inventory提供的順序：
--ask-become-pass--ask-sudo-pass-Kansible-playbook

- hosts: all order: sorted gather_facts: False tasks: - debug: var=inventory_hostname

order的可能值爲：

inventory:

  默認值。 該order是由「inventory」提供的

reverse_inventory:

  顧名思義，將inventory提供的順序反過來了

sorted:

主機按名稱的字母順序排列

reverse_sorted:

反向

shuffle:

Hosts are randomly ordered each run 主機每次運行隨機順序

Tasks list

每一個play包含一個任務列表。 任務按順序執行，一次一個地執行與主機模式匹配的全部計算機，而後再轉到下一個任務。 重要的是要明白，在一個playbook中，全部的主機都要獲得相同的任務指令。 play的目的是將選擇的主機映射到任務。

當運行從上到下運行的playbook時，失敗任務的主機將從整個playbook的旋轉中取出。 若是事情失敗，只需更正playbook文件並從新運行。

每一個任務的目標是執行一個很是具體的參數的模塊。 如上所述，變量能夠在模塊的參數中使用。

模塊應該是冪等的，也就是說，按順序運行一個模塊屢次應該具備同樣的運行效果。 實現冪等的一種方法是使模塊檢查其所指望的最終狀態是否已經實現，而且若是該狀態已經實現，
則在不執行任何動做的狀況下退出。 若是一個playbook所使用的全部模塊都是冪等的，那麼這個playbook自己就有多是冪等的，因此從新運行這個playbook應該是安全的。
command和shell模塊一般會從新運行相同的命令，若是命令相似於或等，則徹底能夠。儘管有一個可用於建立這些模塊的標誌也是冪等的。
每一個任務都應該有一個 ，它包含在運行該play的輸出中。 這是人類可讀的輸出，所以提供每一個任務步驟的良好描述是有用的。 若是沒有提供名稱，則將「feed」的字符串用做輸出。
可使用舊版格式聲明任務，但建議您使用更常規的格式。 在整個文檔中使用了這種推薦的格式，可是您可能會在某些playbook中遇到較舊的格式。
這是一個基本的任務。 與大多數模塊同樣，服務模塊採用參數：
chmodsetseboolcreatesnameaction: module optionsmodule: optionskey=value

tasks: - name: make sure apache is running service: name=httpd state=started 

command和shell模塊是惟一獲取參數列表而不使用表單的模塊。 這使得他們按照你所指望的方式工做：key=value

tasks: - name: enable selinux command: /sbin/setenforce 1

command和shell模塊關心返回代碼，因此若是你有一個成功的退出代碼不爲零的命令，你可能但願這樣作：

tasks: - name: run this command and ignore the result shell: /usr/bin/somecommand || /bin/true
或這個：

tasks: - name: run this command and ignore the result shell: /usr/bin/somecommand ignore_errors: True
若是行動線太長了，你能夠在一個空間上打破它，並縮進任何延續線：

tasks: - name: Copy ansible inventory file to client copy: src=/etc/ansible/hosts dest=/etc/ansible/hosts owner=root group=root mode=0644
變量能夠在動做行中使用。 假設您在部分中定義了一個名爲的 ，您能夠這樣作：
varsvhostvars

tasks: - name: create a virtual host file for {{ vhost }} template: src=somefile.j2 dest=/etc/httpd/conf.d/{{ vhost }}

Action Shorthand

可選擇在0.8及更高版本中列出這樣的模塊：

  template ： src = templates / foo.j2 dest = / etc / foo.conf 

您會注意到在早期版本中，這隻能用做：

  action ： template src = templates / foo.j2 dest = / etc / foo.conf 

舊的表單繼續在較新的版本中工做，沒有任何棄用的計劃。

Handlers: Running Operations On Change

如上所述，模塊應該是冪等的，而且能夠在遠程系統上進行更改時進行中繼。 Playbook認識到這一點，並有一個基本的事件系統能夠用來響應變化。

這些「通知」動做在play中每一個任務塊的末尾觸發，只有在多個不一樣任務通知時纔會被觸發一次。

例如，多個資源可能代表apache須要從新啓動，由於它們已經更改了一個配置文件，但apache只會被triggered一次以免沒必要要的從新啓動。

如下是當文件內容更改時從新啓動兩個服務的示例，但僅當文件更改時：

- name: template configuration file template: src=template.j2 dest=/etc/foo.conf notify: - restart memcached - restart apache

任務部分列出的內容稱爲處理程序。
處理程序是由全局惟一名稱引用的任務列表，與常規任務徹底沒有任何區別，並由通知程序通知。 若是沒有通知處理程序，它將不會運行。 不管經過處理程序有多少任務，在全部任務在特定的play中完成後，它將只運行一次。
這是一個示例處理程序部分：
notify

handlers: - name: restart memcached service: name=memcached state=restarted - name: restart apache service: name=apache state=restarted
至於Ansible 2.2，處理程序也能夠「listen」通用主題，任務能夠通知這些主題以下：

handlers: - name: restart memcached service: name=memcached state=restarted listen: "restart web services" - name: restart apache service: name=apache state=restarted listen: "restart web services" tasks: - name: restart everything command: echo "this task will restart the web services" notify: "restart web services"

這種使用能夠更容易地觸發多個處理程序。 它也使處理程序與名稱分離，從而更容易在劇本和角色之間共享處理程序（特別是當使用像Galaxy這樣的共享源的第三方角色時）。

角色將在後面描述，但值得指出的是：

• 在pre_tasks ， tasks和post_tasks部份內通知的處理程序將在通知的部分的末尾自動刷新;
• 在roles部份內通知的處理程序將在roles部分結束時自動刷新，但在任何tasks處理程序以前。

若是您想要當即刷新全部處理程序命令，在1.2及更高版本中，您能夠：

tasks: - shell: some tasks go here - meta: flush_handlers - shell: some other tasks

在上述示例中，任何排隊處理程序將在達到語句時提早處理。 這是一個niche的例子，但能夠不時地派上用場。
meta

Executing A Playbook

如今你已經學會了Playbook的語法，你如何運行一個playbook？ 這很簡單。 讓咱們用10級的並行度來運行一個playbook：

ansible-playbook playbook.yml -f 10

Ansible-Pull

若是你想反轉Ansible的架構，那麼節點就能夠檢查到一箇中央位置，而不是把配置推送給他們，你能夠。

ansible-pull是一個小腳本，能夠從git檢出配置指令的備份，而後針對該內容運行ansible-playbook 。

假設您負載平衡您的checkout位置，基本無限可ansible-pull秤。

運行ansible-pull --help幫助詳細信息。

還有一個clever playbook能夠經過推送模式下的crontab來配置安全性。

Tips and Tricks

要檢查playbook的語法，請使用帶有--syntax-check標誌的--syntax-check ansible-playbook 。 這將經過解析器運行playbook文件，以確保其包含的文件，角色等沒有語法問題。

查看playbook執行的底部以獲取目標節點的總結以及它們的執行狀況。 通常失敗和致命的「不可達到」的通訊嘗試在計數中保持分開。

若是您想查當作功模塊以及不成功模塊的詳細輸出，請使用--verbose標誌。 這在可用0.5和更高版本中可用。

若是安裝了cowsay包，可靠的劇本輸出將大大提高。 嘗試一下！

在運行它以前，要查看playbook會受到哪些主機的影響，您能夠執行如下操做：

  ansible-playbook playbook.yml --list-hosts