如何維護大型的 Playbooks？
Last updated
Last updated
在學時，凍仁曾藉由大型程式來撰寫複雜的 C 語言。如今當 Ansible Playbooks 寫久之後，其架構也會變得複雜，這時該怎麼寫才好維護呢？就讓凍仁娓娓道來吧！
▲ 圖片來源：https://goo.gl/jBL5i3 。
官方早在 Playbooks Best Practices 文件中列了 12 條最佳實踐 (Best Practices)，底下將以凍仁認為最重要的部份進行介紹。
來自維基百科的解釋：
最佳實踐，是一個管理學概念，認為存在某種技術、方法、過程、活動或機制可以使生產或管理實踐的結果達到最優，並減少出錯的可能性。(more)
凍仁認為，Best Practices 就如同 80/20 法則，只要掌握了 Best Practices，就可以用 20% 的投入獲得 80% 的成效。
在許多技術文件裡 (如 Android, AWS 和 Vue.js) 也會有這個特別的章節，甚至還有前輩向凍仁提到，剛接觸一門新技術時，應該要先從 Best Practices 開始看起呢！
以下修改至官方建議的目錄結構 (Directory Layout) 範例，凍仁只留下較常用的部份。
production, staging：藉由 inventory file 來切換環境。我們在「14. 怎麼使用 Ansible 的 Template 系統？」一章時已提過，在 Best Practices 裡就有特別說明此手法。
site.yml：主要的 playbook。
webservers.yml：網頁伺服器一層的 playbook。
dbservers.yml：資料庫伺服器一層的 playbook。
底下將以某個用 django 開發的 API web server 專案為例。
Vagrantfile：在本機主要使用 Vagrant 搭配 group_vars/local 進行開發。
ansible.cfg：依各專案客製 Ansible 相關環境。
files/：集中管理要使用 files module 複製到 Managed node 的檔案。
group_vars/：設定 staging, production 等不同群組 (環境) 變數的好物 ；若有共用變數的部份可寫在 all 檔案裡。
setup.yml：include 各種 tasks 的主要 playbook。
tasks/：將各種不同任務獨立出來的 tasks，在裡分別為 restart_api.yml, setting_nginx.yml 和 setup.yml。
templates/：集中管理要使用 templates module 複製到 Managed node 的檔案。
大家可以先照著官方的規劃練習，寫久了再依個人風格調整即可，畢竟要讓大型的 Playbooks 變得好維護，不外乎為以下原則：
透過 inventory 和 group_vars 來定義 local, staging 和 production 等各環境的主機和變數。
儘可能的把重複的 tasks 獨立出來，然後讓 playbook 依不同需求 include 進來用。在這個例子裡，凍仁把 setup.yml 和 update_config.yml 兩個 playbook 中重複的 tasks 獨立成 tasks/setting_api.yml，並透過 include 重複使用。
時間允許的話，把重複的 tasks 改寫成，Roles 吧！
我們可以藉由 Roles 讓大型的 Playbooks 更易於維護，在此文中也一直提到它的重要性，這部份就讓凍仁留到下一章介紹了。