（本文同步發表於 Medium）
（Photo by John Schnobrich on Unsplash）
在 playbook 內適當的設立檢查點與中斷點
在小技巧（1）中，主要提及的都是執行指令ansible-playbook 時可以添加的 options，而在本文則分享兩個常用的 modules。善用 debug 檢查
相信有在使用 Ansible 的使用者們都知道，在撰寫 playbook 過程中，經常有一些 Modules 是我們會重複使用的，其中一個即是debug。在 playbook 當中，有時為了讓各個 tasks 能夠順利串連，我們會將部分 tasks 的結果透過
register 註冊為新的 variables，提供後續的 tasks 能以此進行邏輯判斷。而為了確認這些 variables 取得的值或結果是否合乎自己的預期，一般在撰寫 playbook 的過程中，便會直接透過
debug 將其印出，方便自己能夠直接進行除錯與檢查。# 舉例：
command: whoami
register: check_user
debug: msg="{{ check_user }}"
debug 非常單純，即是幫你將 msg 中的資訊印出，因此非常適合適時地安插在 playbook 當中作為檢查點，讓你可以在執行 playbook 之後快速檢查執行成果是否都如你預期。當然如果 playbook 的 tasks 很多，一下子就將 terminal 洗版了，那麼你也可以考慮在 playbook 的最後幾項 tasks 利用
debug 自行拼裝出某種結果報告。
善用 fail 設置中斷點
除了透過debug 將結果印出之外，你也可以利用 fail 設立一些關鍵的「中斷點」。縱然我們知道一個良好的 playbook 或 role 設計，必須要注重「可重複執行而不會搞壞任何東西」，但有時候與其讓自動化腳本具破壞性地一直執行下去，倒不如設置合宜的「中斷點」，避免事情一發不可收拾。
fail 顧名思義它就是一定會 failed 的 task，因此你可以搭配 when 藉此在 playbook 中巧妙地安插中斷點。 - fail: msg="something wrong !!!"
when: check_point is not defined
當然如果你不喜歡
fail + when，可以改用 debug + failed_when，同樣也能做出中斷點。 - debug: msg="something wrong !!!"
failed_when: check_point is not defined
小結
在「軟體工程」中有許多良好的方法能夠幫助我們除錯，甚至是避免程式犯錯，相信本文提及之安插適宜的檢查點及中斷點，對於資深的開發者與工程師而言應該只是一項簡單的基本觀念。「infrastructure as code」或者我們將範圍縮小（放大？）只提「自動化腳本」，其本質依然是一種「Code」，因此我們應該用「軟體工程」的角度來看待它們，如此才能幫助我們更優異的運用它們。
最後，以更長遠的角度來看，為了讓我們能藉由「穩健」的工具來維護「穩健」的 Infrastructure，我們終究避不了要思考「Idempotence」及「Immutable Infrastructure」這兩件事，畢竟就像《SRE》書中所說的，對 SRE 而言「自動化」的最高境界是一個具備「自癒」能力的系統，在那樣的情景之下，能不能安心地重複執行「自動化腳本」，恐怕只是工程師必須煩惱的部分問題而已。
您是否也有一些使用 Ansible 的小技巧呢？歡迎與我分享您的經驗喔！
沒有留言:
張貼留言
不歡迎留言打廣告，所以有進行留言管理，敬請見諒。