過去十年雲計算的發展，在 IT 領域為共享經濟提供了新的機遇；而過去五年移動互聯網的興起，更是在諸多方面給 IT 架構提出了新的挑戰。新的挑戰，新的機遇，同時也意味著新的活力。一時間，Docker 、微服務、DevOps 以及精益研發等新詞匯，在較短的時間內，即充斥著整個 IT 行業。基礎設施領域，巨頭的壟斷，以及技術壁壘的存在，往往會限制入局者，也讓後來者望而卻步。面對業務需求的不斷演進，軟件提供商的應對能力如何，在機遇面前同樣接受考驗。
往往是時代的領航者，首先嗅探到歷史變革前的醞釀。我們大致看到：對的時機，新的思想總顯得有些俏皮，同時還不失冒進。思想背後，我們也總能發現：有些公司進行著那些驚為天人的嘗試，他們激進，他們開拓，他們從 0 到 1 。Docker 這家公司在這其中不可謂是濃墨重彩的一筆。
目前為止，歷史給了 Docker 三年多的時間。這三年中，Docker 自始至終將" Build , Ship , Run "當作公司的宗旨，也就是幫助用戶完成任意應用的構建、發布與運行。
通過總結 Docker 的三年，我們不難發現 Docker 的步伐：
- 第一年，專注軟件構建，對接構建下游，營造鏡像生態
- 第二年，服務容器管理，發布調度平台，打造交付流程
- 第三年，整合企業資源，完善平台功能，著手應用編排
如今，在這第四年過半之際，再去解讀 Docker，我們會發現，Docker 的發展似乎除了重視應用的 " Build , Ship , Run " 之外，另外還在兩個領域的努力有點“欲蓋彌彰”：
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 作為目前全球最炙手可熱的創業公司，百般眼光以及多樣的揣測，都會聚集於這條不乏趣味的鯨魚身上。未來如何，我們拭目以待。
原文來自：http://blog.daocloud.io/dockercevopsos/
轉載地址：http://www.linuxprobe.com/docker-devops-os.html
http://xxxxxx/Linuxjc/1155962.html TechArticle
