iThome Container Summit 2016 Day 2 簡易筆記心得

September 24, 2016 · Cheng Wei Chen

延續上一篇 iThome Container Summit 2016 Day 1 簡易筆記心得，當然繼續補完 Day 2 的內容。

首先再貼一次 iThome 建立的線上聊天區及共筆區，講者簡報也開始陸續提供下載了。

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.12 作為一個分水嶺，相信有關注發展演進的人都知道 Docker 1.12 根本是一個大躍進。

在 1.12 之前用 Swarm + Compose 要稱之為 Orchestration 其實有許多不足的地方要自己想辦法補足。但在 1.12 架構大改並有了 Swarm Mode，Docker 一下子幫使用者解決了許多麻煩的問題（網路、負載平衡），假如只是一個小規模或沒有特殊需求的架構，根本不用搞 k8s 或其他的 Container Orchestration 工具，直接用 1.12 的 Swarm Mode 也許就能滿足需求。

講者花了不少時間在介紹 1.12 的 Swarm Mode，如果想要深入一點認識，這場議程真的不能錯過，希望講者有同意錄影，這樣大家還可以有事後補課的機會，在那之前就先透過已釋出的簡報來望梅止渴吧。

另外講者在分享之中，也透露了一些 1.13 可能會新增的特性（會加強 plugin 的開放性，讓 Docker 成為更好用的平台），看來 Container Orchestration 的戰場激烈，Docker 恐怕短期內改版都會讓人有大躍進的感覺。

Keynote: 大規模公有雲環境下的容器微服務實踐

Day 2 第二場 Keynote 是由來自阿里雲的技術專家姜繼忠帶來的分享。

這場分享的 Agenda 如下：

  • Docker 和容器服務
  • 架構和運維方式的轉變
  • 微服務架構實踐和持續交付

由 Agenda 我們可以預期這場分享中首先也是從 Docker (Container) 開場，先談一談為何我們需要（喜愛） Docker (Container)，以及 Docker (Container) 解決了哪些問題。當然與第一位講者切入的角度有些不同，但也避不了有內容重複之處。另外就是也有談到到「架構」與「運維」的轉變。

講者首先從 IT 核心驅動力切入，點出 IT 企業注重的關鍵為何，分別是以下四項：

  • 效率
  • 成本
  • 質量
  • 安全

這四項大家應該不陌生也能理解，畢竟哪間企業不是追求效率高、低成本、高質量、高安全性。而 Docker 的出現帶來了標準化構建、交付、運維的可能性，也有助於企業滿足以上四項。另外個人的聯想是，近幾年 Agile、Lean、DevOps 越來越熱，其實不正也與這些有關嗎。

講師在過程中也分享了阿里巴巴將 Container 應用在哪些地方及阿里雲的架構是如何實踐的。雖然 Container 帶來了許多優點，但沒有東西是完美的，Container 同時也在架構上帶來更多的複雜性，因此想要妥善運用 Container 避不了的必須對架構、運維模式⋯⋯等做出變化。

具體來說 Container 帶來哪些挑戰呢？包含了監控、日誌、網路、資料存取⋯⋯等。 （不過葉大在他的 twitter 上補充，這不全然是 Container 帶來的變革，而是 pets vs cattle 的必然。）

講師另外分享了一個重點「哪些 Application 適合運行在容器之中？」 答：越是 Stateless 及 Short-Life 的越適合。

可以注意到延續昨天的議程，關鍵字 “Stateless” 又出現了。

本場分享目前似乎沒有釋出簡報，但如果對於講題內容有興趣，也許可以參考下面的連結，應該多少有包含到本場的部分內容。

基於 Container 的大規模私有雲實踐

聽完了阿里雲，接著輪到百度的資深工程師段兵上台分享。這場議程的主軸是百度的私有雲 BOAS (Baidu Open Application Service)，也就是百度建置給自家各種產品使用的 PaaS。

老樣子，開場依然要交代一下時空背景，到底這時代在軟體開發流程與架構上遇到了哪些問題，再由此切入為何要使用 Container。

講師在說明背景因素時，對於研發流程（開發流程）的琢磨比較多，因為這牽扯的角色、事情、流程較多。角色包含了開發、測試、維運人員。事情一樣從開發、測試、維運、監控、業務分析都有關係。總之一言蔽之即是「角色多、事情多、流程慢、研發慢」 （聽到這時，腦中再次浮現了關鍵字 “DevOps”。）

因為前面的背景原因，所以百度在很早就開始打造屬於自己的 PaaS 及 Container 技術，而據講者所述，這裡面可是百度強大技術力的結晶。 （再次展現牆內強大的技術力！）

有了 BOAS 幫助百度解決許多問題，包含各種環境建置（開發、測試、正式）、資源調度、產品部署、監控、數據分析⋯⋯，基本上前面談到「背景因素」時，有關「研發流程」提及的每一個項目全都被 BOAS 搞定了。

關於 BOAS 簡易記錄幾個重點：

  • 自研發
  • 選擇使用 Container 技術的主因是看上了「快速啟動」、「高性能」(相較 VM 性能耗損較少)
  • 雖是自研發，一樣能做到資源調度、隔離。
  • 對於資源控制可以設定「Quota = 應取得資源」及「Limit = 資源上限」
  • 一樣能做到 auto-scaleing，也能設置依排程 scale，可以說在資源調度上具備一定的彈性與靈活度。
  • 自研發的 Container 與 Docker 比較是不相上下，但也不排斥未來也許會遷移改用 Docker。
  • 發佈系統是採用複雜的「分布式 SSH」，因此特別需要注意權限、併發控制與數據正確性。（這點讓人有些驚訝。）
  • 發佈工作的 pipeline 值得參考。（沒拍到照片，好險有釋出簡報。）
  • Container 流量接入有用到 “nginx + lua” 來做轉發。（ nginx + lux 可以處理好多種狀況 ）
  • 監控方面也有著重於「可視化」（讓使用者更方便且容易使用。）
  • 監控同樣有分層，包含 Container 的監控、Application 的監控。
  • 警報系統會做到聯動發布。（強化資訊的橫向串連，這能幫助使用者收到警報後能更快的解決問題。）

最後講者也有提出使用 Container 的經驗分享，其中特別強調了「隔離」這件事情，總之就是提醒大家要注意因為 Container 天性的緣故在「隔離」這一塊需要多加注意。

百度這一場我覺得可以跟 iThome 在其他活動也邀請過的百度相關議程合在一起聽，這樣會對於百度產品背後的整個架構有更深入的認識，可以從不同的角度來切入理解。

不過上述兩場都沒有提供簡報下載與錄影，所以上面的 Link 參考價值不高。

2016-09-30 修正，「貼吧的自動化運維實踐 陈建森 / 百度資深研發工程師 (iThome DevOps Summit 2016)」現在可以看 iThome 提供的錄影了！

不過許立強的那場分享，如不嫌棄就看看我之前寫的筆記文吧。

或者也可以去 InfoQ 中文挖寶。

InfoQ 上還有很多百度的分享，就留給大家自己挖寶了。

題外話，這場分享個人覺得在「用語、用詞」有感受到一些差異，在聽到某些關鍵字時需要花一點時間與腦力才能轉換。

Keynote: Docker 在騰訊遊戲的實踐 (Docker in Tencent Games)

牆內高手三連發，接著輪到騰訊的高級工程師尹燁分享超硬的內容。為何說是超硬的內容呢？你只要回頭看看場內聽眾的臉就知道了，我懷疑到底有多少人聽得懂全部的內容？如果聽得懂，還請各位大大跳出來當個翻譯，或是跳出來當講者吧！ （謎之音：所以說你就是聽不懂的其中一個吧！）

因為能聽懂的範圍有限，就僅做個人比較有印象的重點記錄：

  • 會選用 Docker 的原因之一是與遊戲生命週期有關（遊戲會有大規模增長，然後慢慢衰退的現象。這部分 Day 1 講者台灣卡普空的鮑承佑也有提到，可以對照一下兩場的說法。）
  • 原因之二遊戲對於對於網路延遲敏感。
  • 原因之三遊戲的發佈、變更頻繁。
  • 對遊戲來說，Docker 的價值在於可以幫助資源快速交付及回收。
  • 另外就是利用 Docker 透過調整 cgroup 快速的做到線上擴縮容。
  • 很意外的，他們使用 Docker 的方式是 VM-like，主要是想避免與過去使用 VM 的模式差異過大。
  • VM-like = 可 SSH 登入、有實體 IP、Container 裡裝有 Monitor agent。
  • Orchestration 則是基於 k8s 加上自行修改客制。
  • 因為是自己客制後的 k8s 所以在 Network 上花了很多精力去客制。
  • 監控方面採 lxcfs + agent，一樣也是為了與既有的模式兼容。
  • 數據層（DB 之類的）並沒有用 Container 運行，因為原本的模式已經很完善。
  • 有架設 private registry，同時有擋一層 nginx 做轉發指向 v1 或 v2 的 registry，然後在 private registry 背後底層有使用 Ceph Cluster。
  • 另外有採用 P2P 的方式來快速分發 Image。（這點也很有趣，所以隨手 Google 了一篇《用P2P方法快速分发Docker镜像》）

如果可以真希望有哪位高手可以翻譯一下這場的內容，因為除了內容比較硬，這場也有「用詞差異」的困擾，最後再加上講者感冒了，讓想要理解這場議程的難度拉高了不少。

建構 Container 監控系統的藝術 (The Art of Container Monitoring)

來自趨勢科技資深軟體工程師陳岳澤的優質分享，個人認為這場分享可以當成 Monitoring 的入門教材，搭配去年葉大分享的《Whoscall 的 Realtime Monitoring 經驗分享》兩場一起服用。 （同時段另一個 Track 也是趨勢科技分享 Monitoring 相關題目，兩邊我都想聽，只能等錄影釋出補課了。）

講者開場首先就先吐嘲了一下「AWS 萬萬稅！」，如果你想要完善的監控系統，在 AWS 上你恐怕要繳交不少花費，因此這一場議程要來跟大家分享怎麼來搭建自己的監控系統。

題外話，根據講者自介，可以注意到身為 DevOps Engineer 應該要關注：

  • Agile transformation
  • Micro service and cloud service
  • Docker integration
  • Monitoring system development （當然這只是其中一例，每間公司要求的 DevOps Engineer 技能還是有差異。）

老實說這一場光是看講師的簡報就能學習到不少，不太需要特別筆記，建議有打算建置監控系統的人一定要收下這份簡報，屆時釋出錄影時也一定要收下當成教材或參考資料。

個人覺得最有價值的部分不是講師選用了哪些工具，而是對於監控系統需要事先思考的問題有哪些？像是收集哪些資訊、監控的精細度？Pull or Push mode、視覺化⋯⋯

也因此我前面才會推薦可以與葉大的分享合在一起服用，在實際動手做之前先把一些關鍵的觀念搞清楚，同時也把你對監控系統的需求搞清楚，如此才不會走太多冤枉路。

當然講者推薦的工具也都是常見的選項，包含：

  • Collectd
  • cAdvisor
  • Telegraf
  • InfluxDB
  • Grafana
  • Icinga2
  • EFK

其中個人就被推坑了 Icinga2，看來它比我想像更彈性、易用及多用途。

Docker 導入：障礙與對策

壓軸場，葉秉哲簡稱「葉大」的分享，延續之前在 iThome DevOps Summit 2016 分享的偉大的高德拉特博士，這次葉大在 iThome Container Summit 2016 依然帶來一場應用了 TOC 的議程。

就如議程簡介的說明「以限制理論的思維方式，剖析 Docker 導入的痛點及障礙，並逐一開出藥方，協助你降低導入 Docker 的阻力。」，所以這場分享完全不講工具、技術，而是觀念與思維。

葉大自己已經搶先釋出簡報與錄影，並寫撰寫文章補足時間不足說明的內容，所以針對內容也不多說了，建議大家務必抱持開放的思維然後詳細的服用。

不過在服用之前，個人的建議是先服用葉大在 DevOps Summit 2016 分享的《從限制理論看 DevOps》，一樣已有相關文章、簡報及錄影。先服用完 DevOps Summit 那場分享，有助對 TOC 有更多認識，再接著服用 Container Summit 這場會更容易進入狀況。

個人覺得葉大這一場作為 Container Summit 2016 的壓軸與結論是非常好的一場，特別是在談了一整天的工具、架構之後，你終究要回歸現實捫心自問「這些東西是我們團隊所需要的嗎？」。

炫目的工具及他人的經驗分享，不一定適用於自己的團隊，即便我們還是能從其中獲得學習與助益，但不可避還是需要建立「正確的認知」，進行「正確的學習」、需要「正確的了解現況(需求)」，當然也要學會問「正確的問題」，就像葉大重複提到的「請回到還沒有 Docker 的時代，重新思考你的問題！」

講師群Q&A

最後 iThome 請所有的 Keynote 講者上台接受 Q&A，其中有不少回答值得紀錄，以下就是個人非常混亂的筆記。（可能會有聽錯的部分，請自行分辨內容正確度。）

Q1: 有關 Container Orchestration

  • Orchestration 目前還沒有比較好的抽象，所以使用者從傳統遷移至 Container Orchestration 還有許多挑戰。
  • Orchestration 本身也有很多挑戰，原本大公司們的 Orchestration 差不多，但現在似乎大家都不太一樣了。
  • 大家都在想 network 的 api 怎麼做比較好？例如大家都在想用 overlay 的方式就一定好嗎？
  • Container Orchestration 目前對於真正的大架構，似乎也還需要測試，需要從使用者與開發者的經驗與回饋中學習，目前可以說還在起步的階段。
  • 總體而言 Orchestration 是比較熱的議題，因為大家已經想把 Container 用在正式環境了。
  • 因為各 Orchestration 開發廠商有各自不同的業務驅動，且大家有各自的目標場景，但也都期望能適應更寬廣的場景，所以導致 Orchestration 工具之間，都有一些共通的部分與差異之處。
  • 但可能再過一兩年，就會有更加穩定的 user pattern，到時會更成熟與穩定。
  • 當然現在也已經有一些主流的企業在評估所付出的研發成本及獲得收益，這顯示各企業未來會主動推動 Orchestration 工具。
  • 同意 Container Orchestration 還在起步階段
  • 同意 Orchestration 是趨勢，但真正的企業的需求與類型差異是滿大的。例如百度與其他公司比較起來，在人力、物力、情境上就有很大的差異。
  • 希望大家在走的路程上，能走得踏實一點。仔細評估 Container 帶來的益處，這些是否真正足以支持你做這樣的改變。
  • 百度也是以業務為導向，百度之所以會自己在內部這樣搞一個系統，也是因為 Orchestration 能降低成本、提升資源利用率、提升效率。雖然百度做得很早 2012 年就開始在做，但現在也很難預測未來。

Q2: 現在該往 Orchestration 了嗎？該評估哪些呢？規模要多大才要往 Orchestration 呢？

  • 還是要看你想要透過容器達到什麼目的，例如 mysql 就不一定適合，stateless 的應用就很適合。
  • 百度目前因為有看到成果，所以現在也在嘗試將 stateful 的應用嘗試遷移。所以還是要根據目標與成果來對比，來決定投入程度。
  • 因為這包含了架構變革，可能會影響組織變革，這很可能是一條長遠的路
  • 大陸企業有很多人力物力可以自建構基礎建設，也有企業規模沒有這麼大的，他們關注的是業務需求。這些關注重點比較不在基礎建設的公司，使用 Container Orchestration 就比較合適。
  • 但如果不是互聯網公司，在轉換上就比較會遇到調研期，會選擇比較保守的方式。
  • 所以對於一些容器平台商這是一個機會，可以針對業務需求來滿足，在大陸那邊，容器服務的提供商比較多，競爭激烈。
  • 大陸除了一線公司之外，其他公司在轉換上還是比較保守的。
  • 百度最開始也是從 web 類型 php 開始進入，從 stateless 先開始進入，這樣落地的阻力才會比較小。
  • 回歸根本，Orchestration 需要與否的問題還是你的需求為何。也有看過使用了巨量的容器，但沒有 Orchestration 的案例，因為要巨量其實透過一個 scripts 即可達成，所以問題還是你有沒有 Orchestration 的需求。
  • Orchestration 可以解決你各種依賴關係、資源大小不統一、資源競爭，這些複雜的問題。
  • 但目前各種 Orchestration tools (framework) 通常都會為了解決一些通用的問題，而因此增加了複雜度，所以要評估 Orchestration 能解決你的哪個問題？是資源使用率、使用效率？還是？
  • 另外 Orchestration 的 cost 也要考慮，像是 Orchestration 好不好了解、好不好測試
  • 使不使用 Orchestration 可以從三個層面思考
    • 機器數量，只有一台機器不需要。
    • 人，開發者滿不滿意 ops 的服務、反應速度，如果有 Orchestration 即可縮短時間並加速。
    • 運維，如果有新服務要上線，要加設 monitor 容不容易，那也許 Orchestration 可以幫你快速達成。
    • 如果都沒這些問題，那你可能只需要 containerized 而已
    • 但如果你正在遷移一個大的架構，也許你可以部分遷移，但如果已經很痛了，也許你可考慮一次遷移。

Q3: Container 技術、平台、工具的戰爭？

  • 所以希望各廠商可以有統一 Image 規範
  • Orchestration 還在起步，目前還不完全清楚客戶到底需要啥
  • 每個工具本身的出發點不一樣，所以目標業務有些不同，但當然有共通可以解決的部分，也有不同之處。因為看問題的角度不一樣。所以選擇可以回到自己的需求來挑選。
  • 未來可能是 Container 本身需要有一個共通的規範，讓不同 Orchestration 都可以調度不同的 Container
  • 很難避免有一家獨大某個 format
  • 當 OCI 出現後，現在火藥味沒這麼重了
  • Docker 或 OCI 這些不是大部分使用者在關心的問題，因為底下能做的事情都差不多
  • Orchestration 會跟目前 market 與使用者使用的場景比較有關，例如 mesos 本來沒有 pods，但現在因為場景需要了，現在也有了。
  • 有點類似網路的分層結構，大家在 ip 層，沒有不同，但在物理層是很不一樣。最終會穩定為幾種範本，但這是一個變化的過程，但競爭中有效的好東西還是會被保留繼承下來，這會是一個快速競爭發展的階段。

Q4: 生態系已經起來了，並激發了其他的想像，例如 unikernel，你們怎麼看待？

  • OS 市場會有很大的變化，docker 主要支撐還是 Linux
  • Linux 本身有沒有要這麼臃腫，可否精簡，對於大公司來說是很有吸引力。
  • 精簡版的 OS 一定會在未來誕生，例如 unikernel。但是對於 end user 能否接受，還有好一段路需要走。
  • MS 在整個工具鍊上都會支持 docker for windows (野心大，生態系很大)
  • 例如 CoreOS 支持雙系統升級、可以 rollback
  • 例如 OSv
  • Linux 本身很難被取代，但是會有一些變化，有一些不一樣的 feature，像是 CPU、Storage 的一些底層的資源取用也會有些變化。因為 Container 所誕生一些場景，將導致 Linux 本身往一個更好的方向去發展。
  • 未來會不會有些分布式調度能力或容器能力，直接就包含在 kernel ，這是一個很大的想像。

隨便亂聊的小心得

兩天的 Summit，真是累慘了，因為這一次 iThome 端出的講者與議程陣容浩大，不管錯過哪一場都感到可惜，兩天幾乎每分每秒都是注意力全開，深怕遺漏了哪個「乾貨」沒帶回家。

綜觀兩天的議程幾乎大家都會談到幾件事：

  • 目前正在發生的變化，像是開發流程、產品部署、架構、業務需求、觀念與技術潮流⋯⋯
  • Docker (Container) 解決了哪些問題。
  • 傳統虛擬化技術 (VM) 的資源利用率問題。
  • 回歸根本，要依據你的需求來使用工具。

就如最後講者群 Q&A 時一些講者的意見，如仔細探討各家的擁抱 Container 的背景因素，雖然是不盡相同，但依然有共通與類似之處，每個企業的經驗都有可能成為別人的借鏡。而面對市場上的眾多需求，各個工具廠商正努力的完善工具們，希望能搶佔市場的一席之地。

另外就如在場外與 iThome 副總編輯王宏仁聊天時聽到的，現在有越來越多非 IT、非軟體業對 Container 技術有興趣，Container 後續只會影響更多不同的產業。所以這場 Container 大戰只會更加延燒且越燒越烈。

最後，最近最大的心得就如本文前面的這一段話：

炫目的工具及他人的經驗分享，不一定適用於自己的團隊，即便我們還是能從其中獲得學習與助益，但不可避還是需要建立「正確的認知」，進行「正確的學習」、需要「正確的了解現況(需求)」，當然也要學會問「正確的問題」，就像葉大重複提到的「請回到還沒有 Docker 的時代，重新思考你的問題！」

追逐技術好一陣子之後，現在深刻感受到有許多基礎功夫紮的不夠深，就如「技術債」的概念一樣，「知識債」積欠了不少，想到這裡心中浮現的是「先做對的事，再把事情做對！」，也許這句話也能用這在裡吧。 （「知識債」的梗來自於碼天狗週刊，詳見碼天狗 Issue 60）

轉貼本文時禁止修改，禁止商業使用，並且必須註明來自「艦長，你有事嗎？」原創作者 Cheng Wei Chen，及附上原文連結。

工商服務

更多文章