讓您安心執行 Ansible playbook 的小技巧(2)
(2021/12/25 註記:左思右想,決定棄用 Medium,未來更多文章請參閱 https://chengweichen.com)
(本文的 Canonical URL —https://chengweichen.com/2018/02/ansible-playbook-2.html)
延續小技巧(1),本文繼續分享兩個與 Ansible playbook 有關的小技巧,希望大家都能安安心心地執行自己所撰寫的 playbook。
在 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 的小技巧呢?歡迎與我分享您的經驗喔!