如同程式需要測試，Ansible Playbook 或 Roles 其實也是某種 Code，因此最好也能為其撰寫適當的測試。本文就讓我們向 Ansible 圈內的大神 geerlingguy 求教，學習 geerlingguy 大神測試 Roles 的方式。
（本文同步發表於 Medium）
本文的內容也正是我在 DevOps Taiwan Meetup #13 - Ansible User 小聚所分享的閃電秀，當時的簡報在此：
「跟著 geerlingguy 大神一起測試 Ansible Roles」 建立你的 Roles 並透過 Travis CI 測試 要學習 geerlingguy 大神的測試方式之前，當然請先準備好你的 Roles，將其推上 GitHub。關於 Roles、Ansible Galaxy 及 GitHub 三者的關係，這邊就不再重複說明了，請直接參閱凍仁翔的文章「怎麼在 Ansible Galaxy 分享 Roles？」（上、下）。
推上 GitHub 之後，接著要將 Repository 與 Travis CI 建立串連，這部分也同樣可以參閱凍仁翔的文章「怎麼用 Travis CI 測試 Roles？」。
接下來就讓我們一窺 geerlingguy 大神是如何測試的。
geerlingguy 大神的測試妙招 Ansible 的使用者們應該或多或少都曾使用或參考過 geerlingguy 大神所撰寫的 Roles，如此大量高品質的 Roles，全部都有通過 Travis CI 測試，到底是如何做到的？關鍵在於 geerlingguy 充分利用了 Travis CI 的特性，並且撰寫一支專門協助測試的 shell script。...
（本文內容已過期，請參閱最新的 ansible-container 官方文件。）
自從上次（2016年）試用 ansible-container 遭遇慘痛的踩雷經驗之後，如今 ansible-container 的版本號已進入 0.9.2，據說文件及穩定度皆已有所改善，因此決定趁著放假撥一點空檔再次試用它，希望這次的試用過程不會像上次一樣地慘痛。
（本文同步發表於 Medium）

以乾淨的 Ubuntu 16.04 環境試用 根據官方文件，ansible-container 的 Prerequisites 為
Python 2.7 or Python 3.5 pip setuptools 20.0.0+ 因此決定直接以乾淨的 ubuntu 16.04 環境挑戰，避免遇到 python 版本或相依套件的問題。首先透過 Vagrant 建立乾淨的 ubuntu 16.04，並在 VM 內安裝 Docker。接著以下面指令安裝 pip。 apt-get update
apt-get install python-pip
pip install --upgrade pip 接著按官方文件安裝 ansible-container。
pip install ansible-container[docker] （[] 內除了可以填 docker 之外，也可填寫另外兩種 engines，分別是 k8s 及 openshift。） 順利安裝後即可執行 ansible-container -h，查看 help。
試用 ansible-container 開始簡易地試用 ansible-container...
延續小技巧（1），本文繼續分享兩個與 Ansible playbook 有關的小技巧，希望大家都能安安心心地執行自己所的撰寫 playbook。
（本文同步發表於 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 之後快速檢查執行成果是否都如你預期。...
在剛開始接觸組態管理工具（Configure Management Tool，或常見譯為配置管理工具）的時候，應該都會經歷過一段日子，就是擔心自己寫的自動化腳本會不會有問題，特別是當腳本要使用在 Production 環境時，總是會再三的確認，深怕自己一個不小心，不但沒省事，反而把 Production 環境搞壞了。
本文簡單地談談在 Ansible 中有哪些小技巧可以幫助你降低這些憂慮，放膽執行您的 playbook。
（本文同步發表於 Medium）
 （Photo by John Schnobrich on Unsplash）
在實際執行 playbook 之前的三個基本 Options 先從 ansible-playbook 指令內建的 Options 開始說起，有三個 Options 是最基本的檢查，分別是：
--syntax-check --list-tasks --list-hosts –syntax-check 首先是 --syntax-check，它可以用來幫你檢查 playbook 有沒有格式或語法錯誤，不過其實我們不用手動執行它，因為當你執行 ansible-playbook 時，就已預設會先進行語法檢查了。 所以在 --help 中也是這麼說明的。
--syntax-check perform a syntax check on the playbook, but do not execute it （謎之音：那你還浪費篇幅介紹它。）
對於現代的開發者而言，「語法檢查」通常會跟工程師使用的編輯器、IDE 綁在一起，讓語法檢查能夠自動完成，以 ATOM 為例就有 pacakage - linter-ansible-syntax 可以幫助我們在撰寫 playbook 時即能完成語法檢查。
–list-tasks 第二個 Option 是 --list-tasks，它可以幫你列出在即將要執行的 playbook 中有哪一些 tasks 會被執行。建議在執行重要的 playbook 之前可以先跑一次 --list-tasks，複閱是否會執行的皆是你所預期的 tasks。...
在休養生息的倒數日，找來電影《薩利機長：哈德遜奇蹟》一起度過。雖然不是好萊塢動作爽片，但劇中包含感人、激勵人心的劇情，以及關於心理健康、創傷的演出，還有最重要的面對危機事故的正確態度。這些內容反而令人想要再次細細回味這部電影。
（有部分劇透，請慎入）
（本文同步發表於 Medium ）
 （Photo by Smit Patel on Unsplash）
劇情主軸為全美航空的一架班機剛起飛沒多久即遭遇鳥擊，因而導致失去動力，在此狀況之下，薩利機長判斷必須水面迫降於哈德遜河上，成功迫降的機長被眾人視為是英雄角色，但負責事故調查的「國家運輸安全委員會」，則質疑機長的這項決定，認為這可能是錯誤的決策，並且在事故當時亦可能有人為疏失。而最終電影的高潮即是在最後的聽證會上，薩利機長反敗為勝證明自己的判斷是正確的。
「若你想要找出其中的人為疏失，那麼你便不能將人性從中抽離。」 （憑印象記憶的劇中台詞）
在空難之後的事故調查，透過黑盒子及收集到的數據進行電腦模擬及真人駕駛測試。最初呈現在聽證會上的真人駕駛測試顯示在當時的情況下，機長擁有足夠的時間能夠安全返航，無需進行高風險的水上迫降。但薩利機長卻在聽證會中一針見血的點出這些模擬測試所欠缺的關鍵因素——人性。
從來沒有機長受過訓練，學習過「如何在低空遭遇鳥擊且動力全失時該如何因應。」，但負責擔任真人駕駛測試的駕駛員在聽證會之前，卻早已被清楚告知情景，並已練習過該情境 17 次，因此才能臨危不亂的做出完美的因應動作，將飛機返航降落於跑道上。這正是模擬測試與真實情境的最大差異，在有限時間、高度壓力的情境中，當事人是否依然能夠迅速、理智地做出正確的決策與判斷。
雖然這是一部關於航空業飛機事故的電影，但其中關於事故處理的態度卻值得借鏡。事實上也確實是如此，航空領域因為關係到人的性命，一架飛機若發生事故，很可能影響到超過百人的生命安危，因此為了避免發生意外及減少人為疏失，在航空領域中已經年累積出許多的方法、原則，而這些經驗也經常被借鏡至其他領域，例如劇中遭遇事故之後機長與副機長的互動即是其一，在事故當下，飛機操控權轉回由機長主控，同時副機長負責開始實施標準應急動作，而副機長即將進行的所有操作皆會口述，並由機長再次覆述或確認，這樣的互動其實在醫療領域中也經常能見到。
而劇中最令人敬佩的是薩利機長在事故當下所保持的沈穩、不慌亂、冷靜、理智的態度。這正是任何人都該學習的地方，因為唯有如此，才能正確、迅速的分析現況，在可行方案中找出最大的生機。
如將場景換成 IT、軟體業，試想在公司新產品的上線時刻，伺服器卻立即出現異狀，導致使用者的不良回饋開始大量湧入，身為工程師的我們該如何因應此種狀況？我們也有辦法保持冷靜嗎？恐怕這並不是一件容易的事情，能夠令人保持冷靜的因素，除了個人擁有的個性、性格的特質之外，還有另一項關鍵因素——「經驗」。
經驗可以分為兩個層面，一個即是如薩利機長一樣，駕駛飛機的年資已超過 40 年，充分累積該領域足夠的經驗及敏感度。另一個是特別針對事故所進行的案例分析與事故演練。事故分析、災難還原演練，每個人都知道這些是重要的動作，但有多少人能夠確實的實施？而在電影中即有一段劇情是薩利機長表示自己會定期閱讀其他班機的事故報告作為學習。
而在 Google 的《SRE》這本書中我們也能看見，原來 Google 的 SRE 們被要求、也被給予足夠的時間完成事故分析報告，並且報告必須由資深者及跨部門、跨領域者協助複閱以求完整。除此之外也會定期以模擬劇的方式，將經典的事故報告拿出來作為情境演練。
這些動作都有助於我們累積經驗。甚至更進一步，我們應該要擁抱事故，將其視為是正常任務的一環，因為事故隨時都有可能發生。這也正是現在逐漸被人提及的概念「Chaos Engineering」。
除了前述的內容之外，在這部電影中還有其他值得討論的內容，例如：
如何區分你在事故當下的判斷是來自深厚經驗的累積，或僅是毫無根據的直覺？ 如何建立因應事故的標準程序，同時接納其他的可行備案？ 專業人士應該擁有之不獨自邀功、不咎責（對事不對人）、當責（accountability）的態度。 你的團隊是建立於一兩位英雄角色，或你建造的是一組能互信、互助、值得信賴的團隊。 機器（Monitoring）可能會出錯、人也可能誤判，如何避免？ 航空、醫療領域還有哪些優良的實踐是值得我們借鏡的？ 您也有觀賞這部電影嗎？也歡迎與我分享您從電影當中獲得了哪些想法。
感謝台灣微軟的 R 姐邀請，上週五晚上有幸能參加微軟 MVP 的活動。活動安排的行程前半部為「講者分享」，而後半段則為「分組討論」，在四個分組主題之中，其中一組的討論主題即為「DevOps」。 （本文同步發表於 Medium ）
在當晚的分組討論中，眾多 MVP 及與會者針對 DevOps 及 Scrum 交流了許多經驗，很有趣的是在「DevOps」這一組，首個被提出討論的問題依然是「What is DevOps？」
到底什麼是 DevOps？這真是一個難以回答的問題，特別是當你看見越來越多的資料及聽見不同專家的見解之後，個人越是深深覺得 DevOps 這個字難以用幾個字簡單的說明。
DevOps 是一場 IT 及軟體界的轉型運動、DevOps 是一種文化、DevOps 是一種精神、DevOps 是一種方法論、DevOps 是一大堆串聯在一起的技術解決方案、DevOps 是商人用來⋯⋯
在活動結束、返家的路途之中，自己再一次地咀嚼於活動中交流及獲得的各種經驗，並且反思如果下次再遇到「What is DevOps？」，到底應該要談些什麼？於是心中浮現了以下幾個問題。
組織內外是否有溝通層面的問題？ 組織內外有穀倉效應的問題嗎？ 目前團隊的生產力如何？ 目前從開發直到維運整個流程的順暢度如何？ 組織是否擁抱「持續改善」的文化？ 組織是否擁抱「不咎責」的文化？ 組織是否擁抱「學習型組織」？ 成員是否具備「當責」的心態？ 同時也想起在 Agile Tour HsinChu 2017 活動當天，一早遇見 Titansoft 的老闆 Yves 時的情景。在當時與 Yves 的閒聊中，對於 DevOps 自己似乎說過這樣的一句話——「我覺得 DevOps 這個字可能會漸漸消失，真正會留下的是其他這些相關的重要觀念與實踐方法⋯⋯」
就用一篇部落格文章來紀念本次參與籌辦 DevOpsDays Taipei 2017。

約莫在今年二月底的時候，注意到了北京將會舉辦 DevOpsDays Beijing 的消息，看著網路上傳來的資訊，當時心裡並未多想，只是想著：「哇，沒想到北京在今年加入響應舉辦 DevOpsDays，去年亞洲區好像只有新加坡舉辦的樣子？北京辦得如此盛大，不知道會不會有哪個好心人願意舉辦一場屬於台北的 DevOpsDays。」
接下來的日子陸續傳出北京的各種消息，包含注意到 Ruddy 老師在臉書上貼出了北京的照片，因為老師受邀擔任北京的其中一位講者，老師還秀出他與 DevOps 之父 Patrick debois 的合影。接著在 2017/3/22 當晚，Ruddy 老師便主動傳訊息給我，鼓勵可以嘗試舉辦屬於台灣的 DevOpsDays，並且告知要與 DevOpsDays 官方搭上線並沒有想像中的困難。

雖然 Ruddy 老師推了一把，但其實在當時我自己心中的想法是：「想要辦這樣的大活動，必定要動用不少的資源，包含資金、人力、人脈與熱情。今年就先調查一下狀況，也許明年 2018 再來看看有沒有機會號召眾人一起來舉辦。」
不過萬萬沒有想到，雖然自己在心中是這樣許願，但現實世界卻默默之間急速運轉了起來。

接下來急速運轉了哪些事情呢？
首先是 iThome 主動地表示希望能與社群有更多的合作機會，而我隨口一提的意見「那就一起來辦 DevOpsDays Taipei 吧？」，卻獲得 iThome 谷社長與吳總編輯一致表示有高度的興趣。
接著向 DevOps Taiwan 社群的志工們詢問意見，志工們也一致贊成。
最後，因為談到 DevOps 時，其主題與 Lean、Agile 密不可分，因此我嘗試邀約 Agile Community Taiwan 的前輩柯仁傑一起參與首次的籌辦會議，結果會議一次就順利談妥三方共同主辦 DevOpsDays Taipei。（其實那時還稱不上是正式的籌辦會議，比較像是先試著確認彼此有沒有共識，有沒有機會合作。）
原本我自己還想著明年才來考慮要不要籌辦的想法，在數週的時間內就被替換成「木已成舟，今年非辦不可」。
於是各式各樣的籌備工作就這麼迅速展開：
與 DevOpsDays 官方聯繫，取得官方 Guilde，遵照官方 Guilde 籌辦活動。 與官方進行線上會議，確認彼此沒有任何異議。 尋找評估合適的場地與日期。 請設計師設計 Logo。 公開徵稿與私下邀稿。 尋求贊助商。 送 PR 至官方網站，讓 DevOpsDays Taipei 的資訊可以刊登上 devopsdays....