這兩年容器技術及其相關工具，平台異常火爆。在各大技術論壇或雲計算峰會議題中，都會占很大比重，各主流雲計算平台也無一例外地迅速提供了容器服務。

大廠

• 阿裡巴巴
• 京東
• 美團
• 百度
• 騰訊
• 浪潮
• 滴滴

搜索Docker熱度

• docker關鍵字的分布

docker能幹什麼

• 簡化配置
• 這是Docker公司宣傳的Docker的主要使用場景。虛拟機的最大好處是能在你的硬件設施上運行各種配置不一樣的平台（軟件、系統），Docker在降低額外開銷的情況下提供了同樣的功能。它能讓你将運行環境和配置放在代碼中然後部署，同一個Docker的配置可以在不同的環境中使用，這樣就降低了硬件要求和應用環境之間耦合度。
• 代碼流水線（Code Pipeline）
• 管理前一個場景對于管理代碼的流水線起到了很大的幫助。代碼從開發者的機器到最終在生産環境上的部署，需要經過很多的中間環境。而每一個中間環境都有自己微小的差别，Docker給應用提供了一個從開發到上線均一緻的環境，讓代碼的流水線變得簡單不少。
• 提高開發效率
• 這就帶來了一些額外的好處：Docker能提升開發者的開發效率。如果你想看一個詳細一點的例子，可以參考Aater在DevOpsDays Austin 2014 大會或者是DockerCon上的演講。不同的開發環境中，我們都想把兩件事做好。一是我們想讓開發環境盡量貼近生産環境，二是我們想快速搭建開發環境。理想狀态中，要達到第一個目标，我們需要将每一個服務都跑在獨立的虛拟機中以便監控生産環境中服務的運行狀态。然而，我們卻不想每次都需要網絡連接，每次重新編譯的時候遠程連接上去特别麻煩。這就是Docker做的特别好的地方，開發環境的機器通常内存比較小，之前使用虛拟的時候，我們經常需要為開發環境的機器加内存，而現在Docker可以輕易的讓幾十個服務在Docker中跑起來。
• 隔離應用
• 有很多種原因會讓你選擇在一個機器上運行不同的應用，比如之前提到的提高開發效率的場景等。我們經常需要考慮兩點，一是因為要降低成本而進行服務器整合，二是将一個整體式的應用拆分成松耦合的單個服務（譯者注：微服務架構）。如果你想了解為什麼松耦合的應用這麼重要，請參考Steve Yege的這篇論文，文中将Google和亞馬遜做了比較。
• 整合服務器
• 正如通過虛拟機來整合多個應用，Docker隔離應用的能力使得Docker可以整合多個服務器以降低成本。由于沒有多個操作系統的内存占用，以及能在多個實例之間共享沒有使用的内存，Docker可以比虛拟機提供更好的服務器整合解決方案。
• 調試能力Docker
• 提供了很多的工具，這些工具不一定隻是針對容器，但是卻适用于容器。它們提供了很多的功能，包括可以為容器設置檢查點、設置版本和查看兩個容器之間的差别，這些特性可以幫助調試Bug。
• 多租戶環境
• 另外一個Docker有意思的使用場景是在多租戶的應用中，它可以避免關鍵應用的重寫。我們一個特别的關于這個場景的例子是為IoT（譯者注：物聯網）的應用開發一個快速、易用的多租戶環境。這種多租戶的基本代碼非常複雜，很難處理，重新規劃這樣一個應用不但消耗時間，也浪費金錢。使用Docker，可以為每一個租戶的應用層的多個實例創建隔離的環境，這不僅簡單而且成本低廉，當然這一切得益于Docker環境的啟動速度和其高效的diff命令。
• 快速部署
• 在虛拟機之前，引入新的硬件資源需要消耗幾天的時間。Docker的虛拟化技術将這個時間降到了幾分鐘，Docker隻是創建一個容器進程而無需啟動操作系統，這個過程隻需要秒級的時間。這正是Google和Facebook都看重的特性。你可以在數據中心創建銷毀資源而無需擔心重新啟動帶來的開銷。通常數據中心的資源利用率隻有30%，通過使用Docker并進行有效的資源分配可以提高資源的利用率。

容器編排工具

• kubernetes 和 docker swarm

DevOps = 文化 過程 工具

DevOps的出現有其必然性。在軟件開發生命周期中，遇到了兩次瓶頸。第一次瓶頸是在需求階段和開發階段之間，針對不斷變化的需求，對軟件開發者提出了高要求，後來出現了敏捷方法論，強調适應需求、快速疊代、持續交付。第二個瓶頸是在開發階段和構建部署階段之間，大量完成的開發任務可能阻塞在部署階段，影響交付，于是有了DevOps。

DevOps的三大原則：

• 基礎設施即代碼（Infrastructure as Code）
• DeveOps的基礎是将重複的事情使用自動化腳本或軟件來實現，例如Docker（容器化）、Jenkins（持續集成）、Puppet（基礎架構構建）、Vagrant（虛拟化平台）等
• 持續交付（Continuous Delivery）
• 持續交付是在生産環境發布可靠的軟件并交付給用戶使用。而持續部署則不一定交付給用戶使用。涉及到2個時間，TTR（Time to Repair）修複時間，TTM（Time To Marketing）産品上線時間。要做到高效交付可靠的軟件，需要盡可能的減少這2個時間。部署可以有多種方式，比如藍綠部署、金絲雀部署等。
• 協同工作（Culture of Collaboration）
• 開發者和運維人員必須定期進行密切的合作。開發應該把運維角色理解成軟件的另一個用戶群體。協作有幾個的建議：
• 1、自動化（減少不必要的協作）；
• 2、小範圍（每次修改的内容不宜過多，減少發布的風險）；
• 3、統一信息集散地（如wiki，讓雙方能夠共享信息）；
• 4、标準化協作工具（比如jenkins）

看到這裡，點了關注吧！

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部