DevOps

延續前文，這一系列的文章是將我之前在 C.C. Agile #37 分享的簡報《DevOps: 建造開發維運的跨界之橋》轉換成文章的形式，一方面讓簡報內容能更完整地被分享，另一方面也讓我有地方可以補充一些後續又吸收到的新內容。 本文繼續來談談到底 “What is DevOps”，關於「什麼是 DevOps」目前我看到最多的標準答案是「這個問題目前沒有標準答案。」（2016/9/3 補充更多內容） 於是你就會看到有人開玩笑說「你問十個軟體、資訊領域的專家，什麼是 DevOps，那你會得到十個不一樣的答案。」（來自葉秉哲的演講「Docker 對傳統 DevOps 工具鏈的衝擊」） 而目前的情況也似乎就是如此，你可以在 wiki 上找到 DevOps 的條目，你可以在 Gartner 的報告中看到 DevOps 的相關趨勢，你也能找到各廠商宣稱自己的產品是 DevOps 必備的工具。  但若仔細比較它們對於 “What is DevOps ?” 的描述，你只會得到許多十分類似但卻有些不同的答案。於是又有另一個玩笑出現了「DevOps 是一種 92 共識，認真你就輸了」。  我個人最近在看 DevOps 的新聞與文章，發現了一個現象，早期談 DevOps 的文章，當談到什麼是 DevOps 時，都會直接給一個答案 DevOps 就是 ooxx ⋯⋯；但現在的文章則比較模糊一點，不再那麼斬釘截鐵，甚至有看到文章直接補一句「關於什麼是 DevOps，目前還有許多爭議⋯⋯各家都有自己的意見與詮釋⋯⋯ 」。 所以我才會開玩笑的說「什麼是 DevOps」，標準答案就是「這個問題目前沒有標準答案。」 但各家的定義依然值得我們參考，例如前面提到 Gartner，他們的定義即是 “Gartner defines DevOps as a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach....

除了 Jenkins 之外，個人排行第二感興趣的 CI Tool 是 GitLab（GitLab CI 在 GitLab 8.0 之後合併至 GitLab CE/EE）。個人目前被 GitLab 所吸引的地方是它的「單純與便捷」，如同有些人說 Jenkins 太囉唆了，Jenkins 在使用上可以設定的細節超級多（雖然你不一定每一項都會用到）；相較之下 GitLab 單純且便捷，彷彿只要在程式碼中多加一個 yaml 檔即可設定完所有 CI 流程與動作。 但，真的有這麼簡單嗎？ 所以當然要實際架設來玩玩看，才能做出更多的判斷。 2016.11.4 補充，確實就是這麼簡單，GitLab 確實是目前熱門的 CI Tool，功能越趨完整，雖然難免開始肥大化，但是未來發展不容小覷。 另外此文已經有部分過期了，建議各位閱讀之餘，還要對照最新的文件，避免有誤！ 用 Docker 架設 GitLab 現在 Docker 如此盛行，要架設服務最簡單的做法就是先上 Docker Hub 搜尋現成的 Docker Image。GitLab 這種熱門專案當然不意外，一定會有現成的 Image 可以直接取用。在社群朋友的推薦之下，即找到下面這個優質的 Docker Image。 https://hub.docker.com/r/sameersbn/gitlab/ 印象中這個 Docker Image 的作者 sameersbn 是 Docker 圈內的大神之一，除了 GitLab 之外，他也做了其他很多優質的 image，大神出品，品質保證，選用他的 image 准沒錯！ 大神做出來的 Docker Image 備有非常完整的使用說明，根據 Quick Start 的說明，可以直接使用作者貼心的準備的 docker-compose....

經過了去年一整年的宣傳，雖然熱度可能比不上目前正熱的 Growth Hack，但相信應該多數的人都已聽過 DevOps 這個詞。個人在去年也做了三個與 DevOps 相關的簡報，內容大約都是「Intro to DevOps」的等級，相信對於推廣 DevOps 一詞應該也有提供一些助力吧？ 新年新計劃，首先打算將簡報《DevOps: 建造開發維運的跨界之橋》的內容轉換成文章的形式，一方面讓簡報內容能更完整地被分享，另一方面也讓我有地方可以補充後續又吸收到的新內容。 DevOps：建造開發維運的跨界之橋 (@ C.C. Agile #37) 疑問？ 在開始聊聊 DevOps 之前，我們先來自問幾個問題： 你目前的職務範圍是 Dev、Ops 或你根本是跨職能，甚至是全端？ 你對 Agile、Lean 的熟悉程度？ 你看過《Continuous Delivery》這本書嗎？同時也問你對 Continuous Delivery 的熟悉程度？ 為什麼要問這些問題？其實答案很簡單，因為這些問題都與 DevOps 息息相關。 DevOps 這個詞的出現 What is DevOps？這個問題實在很難用三言兩語回答，既然如此，不如我們先從 DevOps 這個「詞」是從何處出現開始著手，也許了解了「詞」的來龍去脈就能替我們解答 “What is DevOps ?” 這個問題。 詳細的歷史淵源可以參考 iThome 的這篇報導《為什麼會出現DevOps？》，在正體中文的資料中，iThome 這一份內容整理的很詳盡。 簡易版的歷史淵源就如下圖所列，有幾個比較重要的事件： Agile 2008 conference, Andrew Clay Shafer and Patrick Debois discussed “Agile Infrastructure” 這可能是 “Agile Infrastructure” 被開始廣為推廣的開始，同時這也意味著在當時即有許多的人們在思考著如何讓 Dev 與 Ops 更密切的合作。 2009/06/23, O’Reilly Velocity, “10+ Deploys per Day：Dev and Ops Cooperation at Flickr” 延續 “Agile Infrastructure” ，究竟如何讓 Dev 與 Ops 能更密切的合作？想不到 Flickr 在 2009 年就做到了，Flickr 的經驗分享可以說是 DevOps 公開的第一先例。這場簡報撼動了許多人，包括上面那位來自比利時的大大 Patrick Debois，在他的中心種下了舉辦 DevOpsDays 的種子。 2009 - DevOpsDays Ghent in Belgium 於是同一年 Patrick Debois 舉辦了第一場 DevOpsDays，而活動後續的討論在 Twitter 上延燒，為了簡省字數，刪去了 Days，於是 DevOps 一詞正式出現。 2010 - Book《Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation》 延續讓 Dev 與 Ops 更密切合作的概念，接著《Continuous Delivery》也出版，讓這樣的想法更加被傳播也被印證這是確實可行的。 2013 - Book《The Phoenix Project》 最後著名的《The Phoenix Project》出版了。如果你覺得沒有實例無法說服你相信 DevOps，那麼看看《The Phoenix Project》也許是一個好選擇，雖然它只是一個虛構的故事，但卻很真實的呈現了一間企業的導入過程。 由上面的歷史淵源可以看見，DevOps 的出現並不是一個單一事件，同時也隱約能感覺到 DevOps 並不是一個全新的概念，反而是與許多我們已熟知的概念是息息相關。所以也有人說 DevOps 根本是新瓶舊酒，只是將許多舊觀念全部打包再套上一個新詞而已。...

延續去年的盛況，今年 iThome 再次舉辦了 Container Summit。當舉辦的消息剛釋出時，本來是沒有太多興趣的，是一直等到議程公佈，發現有邀請了數位國外講師，包含 Mesos、Rancher 及 DaoCloud⋯⋯等，才改變心意，立馬向公司申請公差決定要來好好朝聖一番。 這次的議程我覺得可以分成三種類型，分別是「大師推坑」、「觀念分享」及「就是來賣產品」。因此並非每一場都需要做詳細的筆記，有些場次只有幾個重點需要記錄，剩下的時間都是在欣賞講者的推坑功力，看看能不能順利讓聽眾們買單。 這次「小城故事不多-科技部」以團體戰術在第一時間就釋出了各場重點筆記，有興趣者可以直接參閱他們的兩篇筆記文，內含每一場的重點筆記。 https://smalltowntechblog.com/2015/12/10/ithome-container-summit-day-1/ https://smalltowntechblog.com/2015/12/11/ithome-container-summit-day-2/ 在這一次的 Container Summit 2015，iThome 依然邀請了葉秉哲（以下簡稱：葉大）為大家分享議程，這次葉大同樣帶來一場屬於「觀念分享」的題目「擁抱或對抗？談 Docker 對傳統 DevOps 工具鏈的衝擊」。 簡報已釋出，可直接線上瀏覽。 開場葉大先用幾則笑話調侃了一下 DevOps 的現況，基本上就是 DevOps 的定義問題、DevOps 涵括太多的領域及 DevOps 的工具種類與數量多而繁雜。 有鑒於 DevOps 目前的現況，因此若想要在一場分享中介紹這麼多 DevOps 相關的內容是不可能的，必須換個角度思考，只能針對有限的關鍵問題分享。 那麼到底在實際面上 DevOps 切身相關的問題是什麼？ 於是葉大借用了 Brian Brazil 在文章中提出的三個嚴肅的問題來回答。這三個問題分別是： How to recreate your system（如何重建你的系統 ） How to safely change your system（如何安全地改變你的系統） When something has gone wrong（你有辦法知道系統出狀況並解決它） 相信 Ops 一定會立刻認同這三個問題的重要性，因為不論是重新打造或修復重建系統，系統建立是 Ops 最基本的關鍵工作。 而系統建立之後，還會遇到需求變更或軟體升級⋯⋯等原因導致系統必須被改變。 最後即便放了綠色乖乖也不代表系統永遠不會出問題，因此系統監測絕對是第三項不可缺少的關鍵項目。 可以說對 Ops 而言若想要提供一個穩定的系統，這三項是絕對逃不了的關鍵問題。所以在談更多 DevOps 的內容之前，不如先好好的討論這三個問題。...

第二天的心得與筆記做得比較少，一方面是連續兩天的大會實在很累，另一方面則是因為下午輪到自己要上場，很難一邊聽講的同時一邊思考並修改簡報，例如我的簡報最前面 DevOpsTaiwan 社群的介紹其實就是現場才新增進去，另外也現場增減了一些簡報內容。 DevOps：IT人的新技能、新文化 - 王宏仁 / iThome 新聞主編 第二天開場的重點就是 2014 State of DevOps Report，所以直接去看報告吧！另一個重點就是選對工具很重要！(但別忘了 DevOps 的重點是人與文化！) DevOps in the Cloud - Ian Lewis / Google 雲端平臺Developer Advocate 基本上整場的內容就是在推銷 Google Cloud Platform，其中有聽到幾個功能稍微有一點興趣，有機會可以研究一下與其他雲端平台有何不同。 instance group manager Cloud Monitoring dashboard 與 Metrics 廚師與伺服器 - 蔡宗城 / 趨勢科技 資深工程師 感想就是講者應該是 Chef 大師，但實在可惜因為場地的網路問題，導致無法順利的 Live Demo。 Yahoo 行動 App 開發在持續整合與持續交付的經驗分享 - 李卿澄 / Yahoo 亞太區產品研發工程部 軟體工程師 講者提到重點在於「workflow of tasks」，另外兩個重點則是要： 過程全部自動化 盡可能將東西放進版本控制之中 在流程上則有以下幾個步驟： Before Commit (要先做 Code Review) Commit (人工 code review 有時候還是會有錯誤，所以還是要透過 CI 自動化的測試再一次把關，然後才能 Merge) Commit stage (同時會檢驗一些指標，例如：測試覆蓋率…) testing (會做 smoke test 、functional test) non-functional testing ( 效能、穩定性 stability test, Monkey test, performance test…) 中間有時候還會有人工測試 (少數案例，例如：結賬與金流相關功能。) production release (如果上線之後還發現問題，就要修改 testing 流程，增加新的測試項目避免再次發生同樣的問題。) 另外講者也有稍微提到 APP 與一般軟體在 CI / CD 上的差異。 Ansible 實戰：Top-down 觀點 - 葉秉哲 / Gogolook 架構師 又是葉大的場，果然一樣精彩，對於 Ansible 又更認識了一些，再加上葉大的實戰講題都會附上簡報與 github，因此聽完之後還可以自己回家慢慢練一次，實在是太好心了！...

約在今年 6 月中的時候，iThome 即宣布將在 9 月 1 日 ~ 2 日舉辦 DevOps 2015 研討會，並且開始廣邀徵稿至 7 月 6 日。雖然上次投稿 ModernWeb 2015 沒被選上，但不灰心本次再接再厲再次投稿，想不到還真的有幸被選上，所以除了要上台當講師的時間之外，其他時間則可以免費入場聆聽這兩日的 DevOps 2015 研討會。 網路上似乎已經有一些評論與心得文，所以就不打算重述太多細節，以下就只簡單的記錄個人的幾個心得，針對每一場講題簡短的記錄： 開場致詞 - 吳其勳 / iThome電腦報 總編輯 吳總編輯提到今天的現場約有 300 多人，數量比我個人預期的少？稍微查了一下台大集思的國際會議廳座位有 368 人，首日觀察覺得約 9 成滿，所以人數應該確實是 300 多沒錯，第二天的觀察是約 8 成滿，不知是否大家對於第二日的講題比較沒興趣？ DevOps 運動的全球大趨勢 - 王宏仁 / iThome 新聞主編 王主編再次講了 iThome 網站上已經刊登過的非洲銀行導入 DevOps 的案例，這個案例之所以重要的原因是想要強調就連傳統的銀行業都已經導入 DevOps，那麼身處在軟體、網路、資訊產業你還能不知道什麼是 DevOps 嗎？ CI 伺服器全制霸！活用自動化技術重建「最強」團隊 - 直井 和久 / 樂天 旅遊業務開發維運部 旅遊網站團隊經理 iThome 最近的幾次活動都有找樂天來擔任講者，幾次下來可以理解到樂天的背後確實有強大的技術力，這次來的 直井 和久 先生也是，感覺上在 CI、Jenkins 上的經驗豐富，但實在很可惜因為語言表達的問題，導致這次沒辦法與聽眾們有更多深入的 Q&A 互動，看到他在回答時默默地自言自語說了 How to say 還真是為他捏一把冷汗。不過自己也在自我省察，因為個人在英文的「說」這一方面也是很需要加強，若是在台上遇到英文問題我恐怕也是要冒冷汗了。...

八月初的時候，DevOps Taiwan 社團舉辦了第一次的 Meetup，並邀請了三位講者來分享講題。我有幸能擔任其中一位講者並分享《摩登開發團隊的 DevOps 之道》這個講題。 講題乍看之下似乎太過故弄玄虛了一點，因為這題目原本是用來投稿 iThome 與 Taiwan WebConf 主辦的 Modern Web 2015 所準備的，因此故意在題目命名上誇張了一些，其實講題內容很單純，就是想跟大家聊一聊「什麼是 DevOps？」。 當然很可惜當時投稿沒上，因此在這次 Meetup 就可以直接厚臉皮地拿出來講，反正從來也沒人聽過我講，再者「什麼是 DevOps？」這樣的內容用來作為 DevOps Taiwan 社團第一次 Meetup 的開場講題其實是相當合適的。 摩登開發團隊的DevOps之道 (@DevOpsTaiwan) DevOps 之瞎子摸象 DevOps 到底是什麼？我覺得這實在很難用簡單的一句話來解釋，因此我們會看到有人說 DevOps 就是敏捷開發，也有人說 DevOps 就是持續交付 (Continuous Delivery)，事實上這些說法也不能說它錯，但好像有一點不夠完全，無法完整的描繪出 DevOps 的整體面貌，似乎大家就像是「瞎子摸象」一樣，嘗試勾勒出 DevOps 這隻大象，但是會不會 DevOps 根本不是一隻大象？搞不好其實是一隻恐龍或是其他種類的生物？ 毋庸置疑 DevOps 就是潮 但不論 DevOps 到底是什麼，有一件事可以肯定，那就是它絕對是目前非常「潮」的一個詞，因為你隨便 Google 你可以找到一堆文章、報導、教學、報告、服務、工具或職務…等，全都掛上了 DevOps，即便你都還不真正的認識它，但你已經無法阻止自己看到它出現在各個地方。 What is DevOps 延續前面提到的，DevOps 很難很簡單的被解釋，那麼有沒有比較複雜又完整的定義或解釋呢？ 答案是有的，除了 Wiki 之外，只要 Google 「What is DevOps」就可以找到一堆，而若你真的去 Google，你很可能會發現目前有滿多人是用 CAMS 來解釋 What is DevOps。...