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