(本文同步發表於 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 的小技巧呢?歡迎與我分享您的經驗喔!
沒有留言:
張貼留言
不歡迎留言打廣告,所以有進行留言管理,敬請見諒。