Docker發展計劃推進DevOps與OS化
大小：0.6 MB 人氣： 2017-10-10 需要積分：1
往往是時代的領航者，首先嗅探到歷史變革前的醞釀。我們大致看到：對的時機，新的思想總顯得有些俏皮，同時還不失冒進。思想背后，我們也總能發現：有些公司進行著那些驚為天人的嘗試，他們激進，他們開拓，他們從0到1。其中，Docker 這家公司的發展，我認為不得不濃墨重筆。
目前為止，歷史給了 Docker 三年多的時間。這三年中， Docker 自始至終將 ” Build， Ship， Run ” 當作公司的宗旨，也就是幫助用戶完成任意應用的構建、發布與運行。
通過總結 Docker 的三年，我們不難發現 Docker 的步伐：
第一年，專注軟件構建，對接構建下游，營造鏡像生態
第二年，服務容器管理，發布調度平臺，打造交付流程
第三年，整合企業資源，完善平臺功能，著手應用編排
如今，在這第四年過半之際，再去解讀 Docker ，我們會發現， Docker 的發展似乎除了重視應用的 “ Build， Ship， Run ” 之外，另外還在兩個領域的努力有點“欲蓋彌彰”：
推進 DevOps 進程
管理能力邁向 OS 化
Docker 推進 DevOps
DevOps 在 IT 領域是一種強調開發團隊、運維團隊以及其他團隊之間增強協作與溝通，以達到軟件產品快速成熟以及安全可控的文化。從 Docker 的宗旨來看， DevOps 的理念似乎非常匹配， Docker 完全有能力來加速、保障軟件的生命周期。而從這幾年的行業發展來看， Docker 作為一款工具，的確在幫助企業踐行 DevOps 理念，同時也借助這款工具的打磨，通過可視價值在更大的群體中推廣 DevOps 。
如果說依舊以軟件構建、 CI / CD 等來介紹 Docker 帶來的 DevOps 價值，那未免有些老生常談。如果關注 Docker 最新動態，你不會錯過 Docker 原生集成編排的爆炸性新聞。當時 DockerCon 2016 發布此消息之后，坊間關于編排之爭、容器生態分裂等傳言與猜測甚囂塵上。而在我看來，編排只是一種形式， Docker 所期望的 DevOps 程度遠不止如此，目前的動作實際上也不止于此。
原生集成編排
Docker 推出 Swarmkit ，原生集成編排能力的新聞，我相信對其他以容器編排為目標的分布式平臺（比如 Kubernetes ， Mesos ＋ Marathon 等）而言，是一個不太友好的消息。一個工具，一個廠商，憑借在容器生態中擁有大量的用戶群體，釜底抽薪，攔截了北向生態。乍一看，的確如此，但如果從 DevOps 的角度重新看待這個問題，也許大家會有不一樣的收獲。
DevOps 是一種新的文化理念，在其驅使之下，踐行 DevOps 帶來價值的大與小，世人一般很難衡量，往往只是與現有固化流程作簡單對比。 PaaS 領域，人們習慣于將 DevOps 聯系進來，而且從效果來看， PaaS 的存在的確大大簡化了傳統運維人員對于應用發布后的管理，因此類似于 Kubernetes 等平臺也確確實實受到傳統運維人員的追捧，釋放運維似乎看到曙光。
然而，回到 DevOps ，這一詞的存在，受益者可絕不止是“運維人員”。對于開發人員而言，同樣存在價值。或許有人言：那豈不是意味著開發人員會承擔更多的活，去涉及運維的臟活、苦活、累活呢？如果是傳統的 IT 架構，缺乏足夠的工具輔佐，恐怕是如此，或者 DevOps 寸步難行。
而如今，在 Docker 的世界中，很多事情似乎變的足夠簡單。在解決了網絡、存儲、安全等問題之后， Docker 的 Swarmkit 幫助 Docker 大大降低了用戶使用容器，踐行 DevOps 的門檻。至今為止，大部分企業內部的軟件交付，往往會涉及三個部門：開發、測試、運維，三者缺一不可。
Docker 的思路比想象中的要簡單很多，力求在工具層面做到最簡約，僅僅通過 Docker 一款工具就可以完成開發、測試、運維等絕大部分工作。如果僅僅在開發者占用的僅有資源中， Docker 即可以提供完備的“ End-to-End ”的工具鏈，那工程師完全可以輕松勝任 DevOps 角色。開發工程師，在開發過程中融入運維的理念，借助 Docker 工具的威力，走通軟件生命周期的全流程。 Docker 帶來的開發部署等環節的環境一致性、編排功能的完備性，勢必大大降低團隊內部的溝通成本和資源開銷。我想企業內部在做 IT 決策時，如此明顯的價值導向不可能視而不見。
DevOps 自始至終都沒有局限在 PaaS 的運行時，相比運維龐大的 PaaS 平臺來解放應用運維的能力，是否會存在本末倒置，一切都還在未可知，至少 Docker 這種輕量級，最便利的一體化方式給 DevOps 提供了一種新的思路。
開發驅動監控
Docker 以輕巧的方式，實現了用戶對于編排的需求。表象似乎很光鮮，但是我們不妨對目前普遍的編排進一步的思考。是否會發現，類似于 Kubernetes 與 Swarmkit 的編排著重于應用的運行時管理，如果僅限于運行時，僅限于應用運維，缺乏開發端源頭的輸入，開發與運維的鴻溝依然赫然在目，一分不少，絲毫無改觀。
傳統的 PaaS 平臺，比如 Cloud Foundry ， OpenShift ，可以基本做到管理應用的運行。然而，應用的生命周期往往比這更復雜，隨后的監控、協調、調度、故障恢復等都是需要克服的難題。而這些在傳統企業內部，毫無疑問都是運維的差事，出了問題還毫無避免的追溯開發人員。如果此時，在擁有傳統 PaaS 的背景下，一款軟件的生命周期中，可以更多的受 DevOps 文化影響，那可以大大減少很多成本。舉一個簡單的例子，在傳統 PaaS 以及容器編排平臺中，對于應用的監控往往很難做到放之四海皆準。對于一些應用而言，平臺通用的監控不是粒度太大，猶如隔靴搔癢，就是提供的細粒度監控并不針對用戶的痛點，顯得南轅北轍。運維人員在設計監控的時候，根本無法通過通用的方式完成應用的“個性化”需求，因此，權衡誕生，取舍難免。
如果關注最新的 Docker 1.12 ，細心的人可能會發現：
Dockerfile 開始支持新命令 HEALTHCHECK ，完成用戶指定的應用健康檢查
Docker 的此舉，看似不經意，實則平地見驚雷，一舉彌合了開發與運維的鴻溝，至少在應用監控領域。 Docker 大大釋放了運維人員的壓力，但是企業切入 Docker 的第一步還是 Docker 化，也就是 Dockerfile ，這一環節自然是開發者的范疇。另外，對于應用的個性化監控，我想沒人比應用的開發者更清楚，如果由應用開發者來承擔，來完成這部分的定義，完全是件皆大歡喜的事。從此，開發環節即完成應用自定義監控的定義， 通過 Docker 提供的統一的架構完成監控，運維環節的監控將不再那么捉襟見肘。
可以說， Docker 1.12 開始，它為應用監控提供了新的契機，彌合開發與運維的鴻溝，打通了兩者的任督二脈，這往往是傳統的 PaaS 平臺，容器編排平臺無法企及的。
Docker 邁向 OS 化
Kubernetes 、 Mesos 等平臺誕生之后，回顧過去的一到兩年，仿佛整個生態的潛意識都有著一個潛意識：容器生態分為兩層，容器引擎的 Docker 作為管理工具，作為底層，單純服務于容器；編排平臺的 Kubernetes 或者 Mesos ，作為上層，滿足應用編排的各種需求。筆者也一度認為 Docker 勢必將往上層走，臥榻之側，豈容他人鼾睡。 然而， Docker 的舉動卻令人大吃一驚，采取的策略則是： Docker 邁向 OS 化。
自從 libnetwork 誕生， Docker 似乎就傳遞著一種信息：無心借力第三方工具，借助內核借力打力。
Docker 風靡至今，面對傳統的資源管理方式，至今仍有未解之謎。如果說， Docker 暫且借助內核的 VxLan 能力，緩解或解決了 Docker 容器世界的網絡難題，那么企業內部架構中仍有問題存在，比如存儲，比如負載均衡等。問題固然要解決，不過反觀近年來企業應用的發展史，在選擇底層軟硬基礎設施時，往往較信任更為基礎的操作系統（ Operating System ， OS ），在與上層云平臺的磨合過程中，多多少少存在水土不服。因此， Docker 管理能力邁向 OS 化，也不難理解。容器未來的方向很有可能打破傳統 IaaS 與 PaaS 的界限，回到廣義云 OS 層面的變革中。
全局存儲
對于應用而言，數據的重要性不言而喻。計算與存儲分離，一直是 Docker 最希望的數據管理方式，而對于存儲的統一化管理， Docker 一直沒有給出令人信服的解決方案，反而是生態中類似于 ClusterHQ ， HedVig 等公司一致在該領域深耕。不過，這也不能苛責 Docker ，這畢竟不是 Docker 的強項與主營業務。
Docker 不可能封閉容器生態的存儲市場，這方面的努力，我們從 Docker 抽象存儲概念即可看出（ Docker 誕生，只存在容器和鏡像這兩個一級概念，而隨著時間的發展， Docker 另外抽象出存儲卷（ Volume ）以及網絡，作為一級概念，并行管理）。
經歷了過去 3 年多單機化的存儲卷，如今 Docker 1.12 推出全局的存儲卷，原生支持集群環境中的數據卷共享。在加上 DockerCon 2016 上， Docker 官方演示借助 NFS ，集群環境中管理分布式數據。容器生態有理由推測， Docker 在存儲領域并非視而不見，而是非常有可能借助操作系統 OS 的能力，切入存儲生態。
IPVS 負載均衡
如今，大多數企業級的應用，不再是僅擁有單個實例。多實例的現狀常常可以避免很多問題，比如單點問題，負載的均衡問題等。而 Docker 的世界中，容器的擴展一直以來不是一個新話題。對于擴展出來的應用容器，服務的注冊以及發現由誰來完成，一直沒有一個定論。而 Kubernetes 等平臺則是為此專門引入一個平臺路由組件完成這部分工作。由于 Docker 的網絡模式與平臺路由組件在協作時，或多或少會存在水土不服，性能等方面的損耗，因此很難達到 ” 1 + 1 》 2 ” 的效果。
新版本的 Docker 1.12 ，編排應用時，可以直接使用 Linux IPVS 完成服務的注冊以及負載均衡。或許，這一舉措直接帶來的好處將是：
借助內核能力，無需額外配置、部署及管理
大幅提高負載均衡的性能
原生支持多種傳輸協議的負載均衡能力（ TCP ， SCTP， UDP 等）
大道至簡，如果諸如 Linux 內核等底層技術棧，本身可以提供負載均衡的管理能力，運維人員沒有理由再去額外安裝一個負載均衡模塊，昂貴的配置、管理、運營成本是團隊決策者不得不考慮的點。另外，比起 Nginx / HAProxy， IPVS 還在多個層面存在優勢：比如 UDP 的支持，多樣的負載均衡策略，以及健康檢查等。
總結
全新的領域，用“探索”來形容現在的 Docker ，我認為最合適不過。著眼全球的軟件交付， Docker 對于 DevOps 理念的貢獻，可謂不可小覷。而面對云計算領域的基礎設施以及平臺架構， Docker 的思路也許會更傾向于 OS 化，逐漸走向 Cloud OS 。然而， Docker 作為目前全球最炙手可熱的創業公司，百般眼光以及多樣的揣測，都會聚集于這條不乏趣味的鯨魚身上，未來如何，我們拭目以待。
作者介紹：孫宏亮， DaoCloud 技術合伙人，主要負責 DaoCloud 企業級容器云平臺的研發。對系統 Docker 化與微服務架構有豐富的經驗，目前已出版《 Docker 源碼分析》一書。本文由DaoCloud授權轉載。
想了解更多關于Docker的內容，請掃描Docker 知識庫二維碼：
內容轉載自公眾號
DaoCloud
?
非常好我支持^.^
(0) 0%
不好我反對
(0) 0%