
籌備多時的 DevOps Taiwan Meetup #3 順利在 2016/11/23 夜間舉辦。感謝極客窩 (Geek Cave) 贊助場地，感謝四位講者黃俊宏、蔡宗城、Mose、Wayne Lin 為本次活動的付出，感謝志工群的幫忙。最後也感謝社群朋友對本次活動的熱情參與！
就以此文簡短紀錄一下本次活動的林林總總。
（封面背景圖片來源 https://unsplash.com/search/fight?photo=1iHpSdiZyFA）
籌備
其實原本 Meetup #2 的活動主題就是「配置管理工具大亂鬥」(CM Tools 大亂鬥) ，但因為 Meetup #2 一直遲遲未能順利籌辦，而當時正逢 DevOps Summit 2016 剛結束，葉秉哲 (葉大) 也有意再分享一次 TOC 的講題，於是在天時地利人和的情況下，就先以「思維引導、持續改善，引發團隊改變新契機」為題舉辦了 Meetup #2。
那到底什麼原因讓「CM Tools 大亂鬥」難以籌辦呢？
主要有兩個原因：
- 講者邀請 想要一次湊齊四種工具、四位講者實在是一件辛苦的事情，尤其是 Puppet 與 SaltStack 這兩個工具的講者。如果你去 Google 搜尋 Ansible 或 Chef，大概都能找到幾位己經浮出水面的講者。但是 Puppet 與 SaltStack 能找到的則相當有限。
如果不能用 Google 搜尋來找講者，就只好透過人脈來間接尋找了，於是在志工群動員了各自的人脈暗地詢問之後，最終我們才湊齊了四位講者。
而且講者還不是找到即可，還要與對方確認意願、約定日期時間，其中 SaltStack 的講者一度流標，因為時間上無法配合，最後是又再透過 Chef 的講者蔡宗城的人脈才順利邀約到 Wayne 來擔任講者。
- 規劃活動內容 CM Tools 大亂鬥，到底要怎麼鬥？這也讓志工們苦惱許久。
最後志工們討論出了一個很棒的想法，即是分為上下半場的活動。
上半場為「設定幾種常見的 CM Tools 使用情境，讓四位講者輪流展示各自的 CM Tools 會如何解決這些情境。」，如此一來應該可以讓參加者們快速的比較四種工具在實際使用上的差異。
於是為了煩惱情境題的難度、複雜度與題目數量等等，又耗費了志工們許多腦力。
下半場為「綜合座談 Q & A」，針對 CM Tools 事先準備一些共通的題目，以解答大家對於 CM Tools 的一些常見的疑問。
綜合座談 Q & A 活動的困難在於「提問」。有參加過類似活動的人都知道，完全不能期待現場提問時間會有人舉手發問，同時也不能期待講者一定會回答問題。
為了避免上述的窘境，我們打算事先準備好問題集，並提前告知講者們我們會詢問這些問題。讓講者可以先做好心理準備，甚至可以事先準備答案。
為了準備這些「問題集」，也是讓志工們燒了不少腦力。不過這份辛苦是值得的，因為我們在活動開始前一天有公開徵求問題，而社群朋友們所提供的問題與志工們準備的問題有多項吻合，代表我們準備的問題有打中使用者的普遍心聲，並且從活動回饋問卷中也得知有不少參加者對於下半場活動的順暢度感到滿意。
最終，我們搞定講者、場地與活動規劃，順利的在 2016/11/23 舉辦了 Meetup #3。
上半場活動
續上，首先這次提供給講者們的情境題，請參考這個 gist 或 hackmd （目前還在想這種社群共用的紀錄應該要存放在哪裡比較好，歡迎提供意見給我們參考！）
因為上半場的內容多數為 DEMO，大家展示的內容則圍繞在前面的情境題，因此就不多做描述。下面僅列出各講者釋出的簡報與檔案。
- Ansible - 黃俊宏 sakana / Max - 簡報
- Chef - 蔡宗城 (Tom Tsai) - 簡報
- Puppet - Mose - 簡報
- SaltStack - Wayne Lin - DEMO 範例檔
下半場活動
下半場活動，事先提供給講者們的問題集，請參考這個 gist 或 hackmd
以下憑記憶與筆記紀錄每個題目的回答概況： （歡迎講者與參加者幫忙協力補充。）
為何你會選擇目前的 CM Tools？
Max: Ansible 不需安裝 agent、使用起來非常簡單。
Mose 則表示應該要根據實際的使用情境選用合適的工具。
蔡宗城: 因為當年首次接觸到 CM Tools 是 Chef，之後才發現有其他的可以選，但因為這些工具都在彼此學習，所以其實選哪一個的差異已經不大了。
Wayne: 因為效能與速度而選 SaltStack，因為 SaltStack 是用 ZeroMQ 溝通，而非 SSH，因此效率會比較好。當管理的機器很多時，即便每台 Server 省一點時間，累積起來也很可觀。
針對仿間對此工具的刻板印象，有沒有想要反駁或提出不同的看法？
四位講者都沒特別的意見，因為這四個工具非常競爭，都在彼此學習，所以工具進步很快，導致這種工具比較文很容易就會跟不上現況。以現在來說，在大部分的使用情境之下，這四種工具皆能合用，彼此在功能方面的差異並不大。
目前該工具對於 Windows 的支援度如何？
四位講者都沒什麼用來管理 Windows Server，因此無法分享個人經驗。不過以這四個 CM Tools 來說，Puppet 與 Chef 比較老牌，目前都能找到真實的 Windows 使用案例，官方也都有特別宣稱能用來管理 Windows Server。因此如果你要管理的環境比較多是 Windows，建議可以先嘗試研究這兩個 CM Tools。
針對 Container (Docker) 的熱門，似乎對於 CM Tools 帶來了一些影響，就你所知目前所使用的 CM Tools 有因此產生什麼變化嗎？你個人又有什麼看法？
四位講者都同意 Docker 確實對 CM Tools 的應用情境產生了影響。如果一個團隊採用的是全 Container 的架構，那麼 CM Tools 確實可能只會被用來安裝 Docker。因為其他的管理動作會被 k8s、docker swarm，這些 Container Orchestration Tools 取代。
但若使用情境並非全 Container 的架構，那麼這其中就仍有 CM Tools 可以使力的地方。另外就是相較於 Dockerfile，對有些工程師而言，CM Tools 的檔案比較易讀且容易管理，因此有些使用者則是將 CM Tools 用於建立 Docker Images，而這四種工具的官方也都有往這方向努力，盡量讓工程師能不改變使用習慣，使用相同的 CM Tools 操作方式來建立 Docker Images。
另外，這四個工具也依然在強化管理與操控 Docker 的功能，總之現在廠商都不得不往擁抱 Container (Docker) 的方向前進。
針對你所使用的 CM Tools ，官方未來將推出的新功能與特色，或相關專案中，有沒有比較令人眼睛一亮的項目？
其實一般人都是用多少看多少，不見得會一直去追新功能。Chef 則有兩個新 Project，分別是 Habitat 及 InSpec。（其實我不記得其他人講了啥，但 Chef 這兩個新 Project 個人也有注意到，因此特別有印象。）
你在學習與導入 CM Tools 時，有沒有遇到什麼問題是覺得比較困難克服？或有沒有什麼經驗談可以與大家分享？
工具改版速度快，官方文件常常來不及更新，在取得正確資訊上會有困擾。
人是最大的問題。
新舊版軟體的相容度問題。
請問學習 CM Tools 有什麼建議先點的前置技能？
對 OS 的掌握度、shell scripts、ssh key 相關、與人溝通合作、對整體架構與流程的認知。
如果遇到多 AP 連結多 DB 架構，再配上多種環境 ( dev / staging / prod )，在佈暑時，你會如何處理機敏性資料？
其實在上半場時，講者大多有講到相關內容，因此本題跳過。
請問使用 CM Tools 做大量部署、安裝、更新套件時，是否有遇到什麼瓶頸？或是其他地雷？
因為時間關係，這題也與前面的經驗談有一點重複，因此跳過。
請問如何驗証自已寫的 CM Tools 的腳本？
在每個步驟的前後，再插入另外的 debug 動作驗證它。
跑了腳本，然後沒人打電話來代表沒問題！
Chef 的 Kitchen
Code Review、先在測試環境跑看看。
請問如何結合 CM Tools 來管理網路設備？
因為時間關係，本題跳過。另外就是這一類的設備也不是每個人都會碰到，但各 CM Tools 也有看到這方面的需求，因此也有在適度的擴充這方面的功能。
現場提問：當初為何會選此 CM Tools 抉擇點是？
答案與第一題類似。（因為題目與第一題類似。）
其中一個抉擇點是需不需要在目標 Server 上安裝 Agent 或其他軟體。
現場提問：Ansible 如何管理 dynamic 增減的 Server？
對於 AWS EC2 目前已有相關的 Module 及 Dynamic Inventory 可以使用。或者你也可以另外想辦法處理，Ansible 在使用上很自由的！
線上共筆 Q & A 問題收集
在活動前幾天建立了 hackmd 線上共筆，收集更多 Q & A 問題，雖然最後沒能詢問其中問題（因為時間不足，且多數與既有問題重複），有興趣知道別人也想問哪些問題，可以前往此 hackmd 觀看。
如果你是提問者，覺得問題沒有被回答很可惜，建議可以嘗試再次於社群中詢問，應該也能釣出一些有經驗者協助回答。
其他紀錄
這次活動還做了幾個新的嘗試，分別是：
宣導主動退票
為了提升到場率，讓每張票都能發揮價值，因此在倒數幾天有一再的宣導主動退票。還真的有不少社群朋友是臨時無法到場而退票，也因此讓幾位沒能搶到的人能夠順利補位。
附帶提一下，本次報名人數 70，到場人數 48，報到率約 68.5%，還有努力空間，希望下次能座無虛席。
紙本簽到表
有鑒於上次直接用 KKTIX 線上簽到有些不便，本次改紙本簽到，據志工表示有比較方便。
會前自動輪播投影片
覺得在活動開始之前，投影螢幕只是打上活動標題也太冷清了，不如利用時間播放一點工商服務的資訊。不知道大家覺得效果如何？
大字報貼紙互動
這是從 Agile 社群中學習到的，在全開的紙張上寫下問題，讓參加者使用「小圓點」貼紙回答。不過有一點可惜，因為本次黏貼的位置不佳，也沒有足夠的宣導與時間讓全部的參加者都參與。因此回收到的票數有一點少，下次再想想如何改進。
活動大合照
辦活動怎麼可以沒有大合照，這次硬是邀請所有參加者一起合照一張照片留念。
意見回饋的線上問卷
一樣是從其他的活動中學習的經驗，想要讓活動越辦越好，那麼一定要收集參加者的回饋，再說 DevOps 的精神可是「持續改善」，當然要想辦法取得本次活動的意見回饋，然後持續改善，讓下次的 Meetup 能辦得更棒！
為了提升問卷的回收率，鼓勵參加者多多填寫，因此事前有宣告會有一個簡單的小抽獎，只是目前社群沒有經費與贊助，因此拿不出厲害的獎品，就先嘗試用「下次 Meetup 的優先購票權」當作獎品。
問卷已回收數量為 22，這個⋯⋯回收率我就不算了。

失物招領
如果有哪位參加者遺失下面這個水壺，請與我聯繫。

再次感謝
本次 Meetup 能成功舉辦真的要感謝的太多了，再次感謝極客窩 (Geek Cave) 、感謝四位講者黃俊宏、蔡宗城、Mose、Wayne Lin、感謝志工群。
最後再次宣傳
如果對 DevOps Taiwan 社群有任何好的想法，歡迎提供給志工們參考，我們會認真看待大家的回饋，希望能讓社群越辦越好。
如果你有意願擔任講者，歡迎與志工聯繫！如果擔心自己的經驗不足，或覺得有些經驗想要分享，但是卻不知該如何組織出一個完整的題目，沒問題，請與志工們聯繫，我們可以協助你釐清思緒！說一句實在話，除了在台下聽講之外，上台分享經驗也是一種很棒的成長機會，分享對於個人成長絕對是有助益的！
如果貴單位、貴公司有意願贊助 DevOps Taiwan 社群，也歡迎與志工聯繫喔！
