（本文內容已過期，請參閱最新的 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....
今年（2017）的 COSCUP 採用與過往不同的徵稿方式，而 DevOps Taiwan 社群也共襄盛舉貢獻了三場分享。
縱然我們知道談到 DevOps 時，不該只談論其中的技術層面，更應該要包含文化層面的議題，不過在這種技術力爆表的場子，就請原諒我們還是會以技術為主要的分享內容。
（不過這麼說有失偏頗，因為 COSCUP 2017 還是有像是「如何將女友培養成開源貢獻者」這種軟性的主題，因此只要有心，還是能夠分享非技術主題的。）
DevOps Taiwan 這次由三位講者，分別負責一場分享，首先我們邀請了部落格「小城故事不多-科技部」的蔡宗城（smalltown）為我們分享「Infrastructure As Code」。
第二位講者則是大家從小看到大的部落格「凍仁的筆記」其主人凍仁翔，為我們分享「DevOps 人一定要知道的 Ansible & GitLab CI 持續交付技巧」。
最後，則由小弟我延續凍仁翔的題目，帶來一場簡易的 Workshop 「Ansible & GitLab CI/CD workshop 101」。
Ansible & GitLab CI/CD workshop 101 這場 Workshop 在構思時，預定的難度是 101 的程度，但實際動手設計內容時發現要講多淺才算是 101？要多複雜才算是 201、301 或更高的難度？有一些難以拿捏，總之就請各位保持著一種開開心心的心情來跟著下面的內容操作練習即可，到底是 101、201、或甚至根本只是幼幼班就先拋在腦後吧（逃）。
回到正題，這場 Workshop 希望能幫助大家藉由實際操作，能夠體驗看看 CI / CD、Automation，以及當我們在談到開發流程的規劃，關於 workflow 或 pipeline 的規劃時可能要注意些什麼？
要注意的是，這個 workshop 的案例只是一個簡單的示範，不同的公司、組織或團隊在規劃 pipeline 時會有各自的考量，因此在實際體驗之後，當你回到自己的團隊時，務必要根據你自身的情況進行規劃，如此才能建構出最適合你團隊的 CI / CD pipeline。
所需工具 本次我們會使用的工具如下：
Ansible - 我們會利用 Ansible 撰寫一些簡易的自動化腳本。 Docker Community Edition - 用來運行你自己 CI Runner 與模擬 Web Server。 續上，一台可以跑得動 2-3 個 Container 的主機（可以是你自己的筆電、雲端的 VPS，或其他。），預計會消耗 5 GB 以內的硬碟空間，因為在 Workshop 使用的是個人自建又大又肥的 Container。 GitLab....