延續小技巧(1),本文繼續分享兩個與 Ansible playbook 有關的小技巧,希望大家都能安安心心地執行自己所撰寫的 playbook。


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 的小技巧呢?歡迎與我分享您的經驗喔!


Like what you read? Give Chengwei Chen a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.