延續去年的盛況,今年 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 的內容之前,不如先好好的討論這三個問題。
接著葉大就一一的針對這三項問題以「傳統作法 vs Docker 作法」的方式一一介紹 Docker 所帶來的衝擊,並分別從「機器」、「組態」與「角色」三個項目切入。
但在進入正題之前,葉大立刻就說今天只會談到前兩個問題。因為在 Docker 如此火紅的時代,還沒有任何一間 Monitoring 相關廠商膽敢不支援 Docker。不論是新興廠商或老牌廠商,多多少少都已經支援 Docker ( 或 Container) 的 Monitoring,差別只在於能做到多細緻,所以第三項問題直接 PASS,整場分享只會聚焦在前兩個問題。
首先是「How to recreate your system」,從「機器」開始談起。
傳統作法基本上就是先有一台資源超強的實體機,為了善用它的所有資源,於是實體機上再透過虛擬化技術建立出多個 VM。但 VM 的缺點就是會有資源消耗的問題,畢竟它不是直接取用實體機的資源,中間必須透過 hypervisor 這一層。於是假如應用程式是各自放在不同的 VM 之中,那麼每個 VM 皆會各自在 hypervisor 上有資源消耗。
那 Docker 作法呢?基本上 Container 的出現有一部分原因就是為了解決 VM 在 hypervisor 的資源消耗。將每個應用程式獨立放在各自的 Container 中,所有的 Container 共享一個 hypervisor,如此即能節省這部分的資源。而目前很多應用程式也都已經被 dockerized,方便使用者可以快速建立並使用。
若由此進一步思考 OS 的重要性,會赫然發現 OS 似乎只剩下用來運行 Docker ( 或 Container) 的價值。所以 Container OS 這種新玩意也就此誕生,Container OS 即是專門用來在其上運行 Container 的作業系統,如目前有名的 Core OS、Rancher OS⋯⋯等。
另外,VM 並沒有因為 Container 的出現就被徹底捨棄。如果你非常看重「硬體資源」的隔離,那麼 VM 依然是一個好選擇。在追求「資源隔離」的前提之下,又延伸出另一派的新思維「Container per VM」,例如 Hyper。
順道提一下 Hyper,之前就有注意到這個有趣的專案,就如它網頁的介紹 “Make VM run like Container. Fast as Container, Isolated by VM.”,它嘗試保有 VM 與 Container 兩者的優異之處,也許這是另一條不錯的路線,可以繼續觀察它後續的發展。
在 OS 層面最後一個影響就是「Unikernel」,個人是前一陣子才在 Docker 相關的資訊中看到這個詞,這次能聽到葉大的解說,剛好解答了一些疑惑。
它的重點即是將能拔除的東西全部拔除,連 OS 都嫌太大太多,連 OS 都想拔除。在此思維之下,將環境精簡到只有特定應用程式所需的 “minimal set” 形成所謂的 “library OS” 的概念。
那為何要這麼做呢?我覺得可以先看看葉大在 jcconf 2015 的分享「Immutable infrastructure:觀念與實作 (建議)」及 Boxfuse 的介紹 “Why Immutable Infrastructure ?”,應該能提供一些觀念上的補充。
上面講了這麼多,到底該如何選用哪一條路線?葉大的建議可以參考簡報 P. 30,根據 service consolidation 與 resource isolation 相互的重要性來評估。
接著談到「組態」。
不同的應用程式在環境設定上會有各種不同的組態,如果是傳統的 DevOps 做法,第一個想法應該就是利用 Configuration management tools 來解決它。不過在使用如 Chef、Puppet 或 Ansible 這些工具之前,先決條件是你必須先具備足夠的環境建置、部署及維運能力,同時還要學會這些工具自己的腳本語法、使用情境、操作邏輯⋯⋯,才能有效地運用它。
不過即便有了 Configuration management tools 的輔助,但「組態設定」這件事本身的「複雜度」依然並未減輕多少。
而 Docker 呢?我們可以先回想一下 Docker 官網上重要的三個字 “Build, Ship, Run” 。透過 Dockerfile 與 Docker image 的 Layer 特性,Docker 這個工具可以讓你分層管理、重複利用、快速遷移與部署。
因此你可以將複雜的系統環境或組態切分為數層 Layer 方便管理。build 的 Image 還能存放於自己的 Docker Registry 重複利用,或者也能直接上 DockerHub 尋找優質可用的 Image。只要透過妥善的設計與規劃,不論是在 dev、stg 或 production 的各種複雜環境也能透過簡單的 “Docker pull、Docker run” 再現。
這樣看起來 Configuration management tools 似乎變得不再重要?就如葉大簡報 P. 40 的重點,Configuration management tools 未來將可能只被用來安裝 Docker 及初始化設定。簡報 P. 40 中附註的文章《Containers Vs. Config Management》個人建議也值得一讀。
最後談到「角色」。
這裡葉大要講的是 “Pets or Cattle” 的觀念。因為這觀念已不是第一次聽見,所以就沒有記錄太多細節,如果用 “Pets or Cattle”、 “Pets vs Cattle” 之類的關鍵字去 Google 即可找到許多優質文章與簡報。
葉大也在這段分享中再次提到 12 Factors App,呼應 Docker 在運用上與 Cattle 的觀念及 12 Factors App 有多麼吻合。個人的想法是這一切都與「架構」有關,不管是系統架構、應用程式的軟體架構。假設你期望系統能做到彈性擴展,但你的架構卻缺乏彈性、可移動性,應用程式的資源被高度綁死在一台又一台的 Pets,那怎麼有辦法彈性?
How to safely change your system ?
葉大這場分享主要都是花在觀念說明。因為只要了解這些觀念就不難理解第二個問題「How to safely change your system」在傳統作法與 Docker 作法的差異。
如何安全地改變系統,在傳統作法即是會採用一些如 Rolling upgrade、Blue / Green deployment、Canary deployment 的方法來嘗試安全的更新軟體或改變系統,同時你必須要自己事先注意好所有的細節,避免在系統改變中出錯。
那麼 Docker 作法呢?則延續前面介紹的 “Pets or Cattle” 的觀念,如果你的機器是以 Cattle 的方式管理並且應用程式的架構吻合 12 Factors App,更將應用程式封裝為 Docker image,那麼傳統作法中的某些繁雜細節你就不需擔心了。
例如 Google 的 Kubernates 要做出 Rolling upgrade 即非常容易,只要一行指令即可。很多麻煩的細節 Kubernates 會幫助你處理。至於其他如 Mesos 與 Docker 官方更不用說,也都在這方面有工具可以輔助。
所以說重點依舊是 “Pets or Cattle” 的觀念,若想要獲得 Docker 作法帶來的優點,還是先好好的檢查一下你的「架構」吧!
葉大的分享就到此,結束前會再有一次總結,即是簡報 P. 71~75,基本上看簡報就知內容重點,所以就不再復述了。