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

普通下載普通下載

相關(guān)電子資料下載

• 如何在Windows系統(tǒng)上設(shè)置Docker鏡像源 55
• 機(jī)器學(xué)習(xí)需要掌握的九種工具盤點(diǎn) 16
• Docker鏡像國內(nèi)加速的幾種方法 55
• VectorCAST|Docker場景下的代碼白盒測試實(shí)施 402
• 如何用Springboot整合Redis 118
• 如何在macOS系統(tǒng)中用Docker運(yùn)行macOS鏡像呢？ 364
• 什么是Docker容器？為什么需要Docker容器？ 71
• 為什么需要Docker容器？Docker容器和VM有什么區(qū)別？ 323
• 如何使用 Docker容器化技術(shù) 1188
• Dockerfile定義Docker鏡像的構(gòu)建過程 1088