Docker 的步伐：DevOps 與 OS 化

摘要: 過去十年雲計算的發展，在 IT 領域爲共享經濟提供了新的機遇；而過去五年移動互聯網的興起，更是在諸多方面給 IT 架構提出了新的挑戰。新的挑戰，新的機遇，同時也意味着新的活力。一時間，Docker 、微服務、DevOps 以及精益研發等新詞彙，在較短的時間內，即充斥着整個 IT 行業。

過去十年雲計算的發展，在 IT 領域爲共享經濟提供了新的機遇；而過去五年移動互聯網的興起，更是在諸多方面給 IT 架構提出了新的挑戰。新的挑戰，新的機遇，同時也意味着新的活力。一時間，Docker 、微服務、DevOps 以及精益研發等新詞彙，在較短的時間內，即充斥着整個 IT 行業。基礎設施領域，巨頭的壟斷，以及技術壁壘的存在，每每會限制入局者，也讓後來者望而卻步。面對業務需求的不斷演進，軟件提供商的應對能力如何，在機遇面前一樣接受考驗。

每每是時代的領航者，首先嗅探到歷史變革前的醞釀。咱們大體看到：對的時機，新的思想總顯得有些俏皮，同時還不失冒進。思想背後，咱們也總能發現：有些公司進行着那些驚爲天人的嘗試，他們激進，他們開拓，他們從 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 做爲目前全球最煊赫一時的創業公司，百般眼光以及多樣的揣測，都會彙集於這條不乏趣味的鯨魚身上。將來如何，咱們拭目以待。

免費提供最新Linux技術教程書籍，爲開源技術愛好者努力作得更多更好：http://www.linuxprobe.com/