籌備多時的 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 大亂鬥，到底要怎麼鬥？這也讓志工們苦惱許久。 最後志工們討論出了一個很棒的想法，即是分為上下半場的活動。...

（本文於 2018-06-14 21:56:01 更新。） 在某次機緣之下，與尊敬的 Ruddy 老師針對「 DevOps 推薦書籍」有一些簡單的交流。那時整理了手上的筆記，將收集到的 DevOps 書單整理在本文之中。如果你也有推薦的 DevOps 書單，歡迎與我交流！（本文將持續更新，歡迎推薦 DevOps 好書。） （本文同步發表於 Medium） DevOps 不只涉及觀念，也與許多的工具相關，但因為技術工具書，例如：Ansible、Docker、K8S 這一類著重於工具操作與使用的書籍，通常隨著工具更新的緣故，書籍的壽命都比較短。同時並非每一種工具都適用於所有的團隊，因此這類書籍就不收錄在此書單中。 這份書單會以保存期限較為長久的觀念型書籍為主。 Effective DevOps - Building a Culture of Collaboration, Affinity, and Tooling at Scale 這是一本由技術人撰寫的非技術書籍，本書主要在談 DevOps 文化，圍繞在書名副標的那四個項目 Collaboration、Affinity、Tool、Scale，以文化與組織發展為主軸貫穿全書。另外書籍的前面幾章也針對 DevOps 及 DevOps 相關的關鍵字提供了基本簡介，某種程度可以當成一本 DevOps 入門書，可由此再延伸閱讀更多的書籍。（繁中、簡中） Continuous Integration: Improving Software Quality and Reducing Risk 關於持續整合（CI，Continuous Integration）的經典必讀書籍，缺點是目前沒中譯本。 Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 關於持續交付（CD，Continuous Delivery）的經典必讀書籍，比較要注意的是因為英文版是 2010 年出版的書籍，因此書中範例提到的軟體會比較老牌一點。另外，在社群中也有前輩表示現今 Microservices、Serverless 等新觀念抬頭，這本書的部分內容應該可以配合這些觀念而有所更新。（繁中） The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win 知名的 DevOps 小說，如果當工具書來讀會大失所望，按其他前輩的說法，此書就是要當成小說與實際案例來看，請細細品味書中的劇情及小說人物遇到的困境，並且對照自己的經歷而有所反思，同時嘗試換位思考如果你是小說內的主角你會怎麼面對問題，如此一來才能體會書中的醍醐味。本書也是讓玄妙的 DevOps「三步工作法」首次面世的書籍。（繁中、簡中） The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations 由目前世界知名的 DevOps 顧問 Gene Kim 與他的好朋友們延續《The Phoenix Project》而撰寫的另一本書。如果覺得看完《The Phoenix Project》之後，對於玄妙的三步工作法依然不得要領，那麼這本《DevOps Handbook》就是你的救星。這本書透過案例與說明幫助你一步步實踐「三步工作法」，這些案例不乏許多知名的公司，像是 Google、Netflix、Etsy⋯⋯。（簡中） The Nature of Software Development: Keep It Simple, Make It Valuable, Build It Piece by Piece 另一本值得列為 DevOps 必讀書籍的輕薄好書。本書簡短、輕快且直擊紅心的點出軟體開發的核心關鍵—交付價值，這也正是藏在 DevOps 背後的重要關鍵。若希望讓你的團隊順利踏上 DevOps 之旅，那麼最好讓組織、團隊及個人皆能共同意識到「交付價值」的重要性。（簡中） Site Reliability Engineering - How Google Runs Production Systems 有些人是這麼評論的 “SRE is Google’s version of DevOps”，在《SRE》書中也自己寫到「SRE 是 DevOps 模型在 Google 的具體實踐」。另外在 Gartner 所推出的 Gartner DevOps Model 中，也可以看見 SRE 有被列入其中。這是一本兼具觀念與技術實務的書籍，內容包含很硬的技術實踐與很軟的團隊文化，對於 SRE 有興趣者非讀不可，另外若對你而言 DevOps 與 Cloud Architect 的關係密不可分，那這也是非讀不可的好書。 The DevOps 2....

自從參加幾次 Agile 相關的活動之後，切身體會到「玩遊戲」真的是一種很棒的體驗與學習方式，特別是當你對於某些觀念與情境還沒有足夠的「實務經驗」時，遊戲其實是一個很好的情境模擬方式，讓人在短暫的遊戲中，可以稍稍體會到實務現場中的某些狀況。 因此這次看到 C.C. Agile #51 將透過「翻硬幣遊戲」來與大家聊聊 WIP Limits 及 Lead Time，二話不說，立刻向太座大人請示可否外出放風。 本文就簡單的紀錄這個有趣的遊戲及簡短的心得。  翻硬幣遊戲 本次活動將參加者分成兩組，每組 12 人，各別代表一間公司。 每間公司皆有五個部門（經理、員工各一人）、一位老闆及一位客戶。 遊戲的流程大致如下： 客戶將「硬幣」交給公司，「硬幣」會經過這五個部門，最後完工的「硬幣」再傳回給客戶。 每個角色要做的事情都很簡單： 員工 = 將每一枚硬幣翻面，然後傳遞給下一個部門。最後一個部門則是傳給客戶。 經理 = 幫員工計時，看看他完成工作需要花費多少時間。 客戶 = 從交付硬幣開始計時，當收到傳回來的第一枚硬幣時結束計時。 老闆 = 從交付硬幣開始計時，當客戶收到傳回來的最後枚硬幣時結束計時。 那麼在遊戲中間要怎麼體驗 WIP 與 Lead Time 呢？ 這就看遊戲規劃者如何設計每一回合的詳細規則，例如： 第一回合：只能用單手翻，而且必須要翻完 15 個硬幣，才能將硬幣傳給下一個部門。 第二回合：只能用單手翻，只要翻完 5 個硬幣，就能將硬幣傳給下一個部門。 諸如此類 因此透過遊戲規則的設計，就可以讓參與者體驗到不同的 WIP 的限制下，對於 Lead Time 會產生什麼影響，以及不同的 WIP 對於整體 Flow 流動順暢度的影響。 簡短心得 這次遊戲玩得相當激烈，兩組人馬的競爭心非常強烈！我個人在遊戲中選擇擔任員工的角色，玩到最後，翻硬幣翻到手指流血，你就知道大家都是卯起來玩！這就彷彿現實生活，企業之間競爭激烈，如果不能「持續改善」的公司，終將在競爭中敗陣，所以非要拼得你死我活不可 XD。 如前面對遊戲的說明，在主辦者 Erica 精心設計的詳細規則之下，讓人能體驗到不同 WIP 限制對於整體 Flow 的影響，並且透過比較不同回合的計時數據，可以很明顯看出 WIP 限制對於 Lead Time 的影響，當 WIP 從較大數字縮小到一個合適的數字時，可以發現有非常明顯的改善效果。...

這次受邀擔任 PHPConf 2016 的工作坊講師，負責一場「自動化與持續整合」的實作工作坊，除了有事先預備了 Local VM 提供參與者事先安裝設置之外，要特別感謝微軟贊助本工作坊，每位學員都會擁有一組 Azure Pass 一個月內有限額的 Azure 試用，讓學員可以直接在 Azure 上建立工作坊的實作環境。 此文即是紀錄在 Azure 上要如何建立實作環境。 （2017/8/5 註記：此文的一些資訊已經過期，你也知道工具是會不斷更新的。） 環境描述 再重複一次我們會需要用到下面四種 Server： CI Server：這次工作坊會以 GitLab 作為主要的 CI Server。 CI Worker：即是 GitLab Runner。 Web Server：標準的 Nginx + Php-fpm，而且要開放可以 SSH Login。 Selenium Server：測試案例中會用到 Selenium。 在 Azure 上，其實有各種方式可以組合出實作環境，但既然我們有 Azure 免費試用，當然可以選一種相對簡單，但又很奢侈的建置方式，即是「建立多台 VM 並安裝好 Docker，讓每台 VM 都只用 Docker 建立 1~2 種 Service。」 如此一來由多台 VM 各自負擔工作，不用擔心資源不足，也不用煩惱 IP 的問題。 所以讓我們再次感謝微軟的大力贊助！ 不過我想 Azure 專家們應該會跳出來說，Azure 明明就有很多好作法，所以我只好維持一樣的回答，此文不是 Azure 教學文啊，只是想用最簡單的方式建構出本次工作坊的實作環境，就請專家們睜一隻眼閉一隻眼嘍。 當然，你也可以開一台超大超強的 VM，然後和上一篇文章的 Local VM 一樣，在一個 VM 內用 Container 提供多種服務的方式建置環境，做起來也不難，但這就留給有心人自己去嘗試了。...

這次受邀擔任 PHPConf 2016 的工作坊講師，負責一場「自動化與持續整合」的實作工作坊，因為希望工作坊的過程中能將網路與實作環境的問題減少到最少，所以事先預備了 Local VM 提供參與者事先安裝設置。 此文即是紀錄這個 Loacl VM 是如何建立的。 （2017/8/5 註記：此文的一些資訊已經過期，你也知道工具是會不斷更新的。） 環境描述 因為考慮到不是每個人都會有頂規的電腦設備，同時也為了方便設置，因此在 Local VM 的規劃上，不打算實際建立多台 VM，而是以單一 VM 並在其中透過多個 docker container 的方式來模擬多 VM 的情況。 我們會需要用到下面四個 Server： CI Server：這次工作坊會以 GitLab 作為主要的 CI Server。 CI Worker：即是 GitLab Runner。 Web Server：標準的 Nginx + Php-fpm，而且要開放可以 SSH Login。 Selenium Server：測試案例中會用到 Selenium。 基於以上四項都要放在同一台 虛擬 VM 裡，並用多個 Container 來實現，在經過實驗之後建議運行此 VM 的電腦或筆電(host機)至少需要： 超過 2GB 的記憶體。因為 GitLab 與 Selenium 都滿吃 Ram，因此分配給 VM 的 Ram 至少要 2GB， 預留 10 ~ 20 GB 硬碟空間。因為運行 Docker 環境其實也滿吃硬碟空間的，硬碟空間能留越多是越好啦！ VM 與 host 機將對映幾個 port 分別是 80、2222、10122、10180 為了簡化環境建置的難度，作為此 VM 的 OS 我們即選用 ubuntu 14....

延續上一篇 iThome Container Summit 2016 Day 1 簡易筆記心得，當然繼續補完 Day 2 的內容。 首先再貼一次 iThome 建立的線上聊天區及共筆區，講者簡報也開始陸續提供下載了。 Gitter 線上聊天區 共筆區 Container Summit 官網下載簡報 2016.10.14 補充：Container Summit 官方已釋出錄影 Keynote: Docker 集群編排方案 這場是由真正來自 Docker 公司的講者陳東洛（去年加入的）為大家分享「Docker 集群編排方案」。說真的我一開始也不知道這個中文「編排」所指的是？聽了一段之後才知道是指很難翻譯成中文的 “Orchestration”。 本場的重點即是 Docker 的 Container Orchestration，所以在開場講者先快速的說明了一些背景因素，像是這幾年的軟體開發架構變化，與 Docker 解決了哪些問題及沒解決哪些問題。由此點出為何 Docker 也要推出他們家的 Container Orchestration 工具。 其中我覺得說得很好的一點是「Orchestration 並不是一個新的議題」，在沒有 Docker 之前就已有 Orchestration 需求，只是既有的 Orchestration 工具並不是這麼適合 Docker (Container)，畢竟 Docker 也不過是這幾年才出現並熱門。也因此 Docker 當然要做自己的 Orchestration 工具，而且其實 Docker 一直有從開源社群、用戶那得到回饋，也一直有在研究 Orchestration 這方面。 接著就進入正題 Docker 的 Orchestration 工具，這可用 Docker 1....

今天參加了 iThome 舉辦的 Container Summit 2016，以下是 Day 1 的簡易心得筆記。 iThome 這次也有建立線上聊天區及共筆區，簡報也開始陸續提供下載了。 Gitter 線上聊天區 共筆區 Container Summit 官網下載簡報 2016.10.14 補充：Container Summit 官方已釋出錄影 Keynote: The Kubernetes API & Next Generation Automation Tools 又是來自 Google 的 Ian Matthew Lewis，今年到底見過這位講者幾次呢？我想至少有三次以上吧。當然這次依然是講 k8s 的相關主題，前半場依然有些 k8s 的基礎介紹，像是 k8s 到底幫你解決了建立 Container Cluster 需要處理哪些麻煩的細節。 雖然說是基礎但卻是不得不介紹的內容，因為必須要先理解 k8s 的基本運作及 k8s 的 controller 是如何運作，接著才能理解後半場有關 k8s API 及 Custom Controllers 的 DEMO。 再看講師 後半 DEMO 時，一開始有些閃神（這就是一邊偷看共筆與聊天的缺點），沒搞懂為何忽然開始寫 Go，接著才理解這邊可是火力展示！DEMO 與前面的說明相呼應，讓你理解 k8s API 及 controller。 G 社的講師向來都是不開放簡報下載與錄影，所以閃神沒仔細聽的部分就沒辦法補課，有些可惜，但總之因為 k8s API 讓我對於 k8s 的好感又加了數分。...