Docker與Vagrant之間的特色比較

　　如下內容均出自Vagrant做者(Mitchell Hashimoto)與Docker做者(Solomon Hykes)在stackoverflow上面一個問題討論。在這個問題中，雙方闡述了vagrant和docker的特色和使用範圍，對於深刻理解vagrant和docker頗有意義，所以筆者翻譯出來，以供你們討論學習。

　　Mitchell做爲vagrant的做者，其在DevOps的世界裏面沉浸多年，接觸了不少相似docker的虛擬化軟件。他目前接觸了不少使用vagrant和docker的場景，因此看到了二者是如何相互搭配發生做用的。

　　他認爲若是單單是開發人員一我的單獨使用主機，使用docker能夠簡化不少事情，這種場景下使用docker和vagrant都沒有什麼區別。因此他更多的討論了一些複雜場景，在這些複雜場景中，docker和vagrant就有一些區別了。

　　如下是他原文：

　　不分場景而直接比對vagrant和docker是不恰當的！在一些簡單場景中，它們兩款產品做用是重複的，但在更多場景中，它們兩款產品沒法相互替代。事實上，vagrant抽象度比docker更高，所以直接用vagrant同docker相比較是不恰當的。而把vagrant同Boot2Docker(一款運行docker最小的內核) 進行比較彷佛更加恰當。

　　vagrant爲了支持開發，在啓動虛擬機環境時啓動了不少的應用和服務。vagrant能夠在VirtualBox, VMware上面運行(docker沒法執行)。vagrant也能夠在AWS, OpenStack這些雲環境中運行。即使你使用了docker的容器，vagrant一樣也沒問題。vagrant能夠自動install, pull down, build,  run Docker containers。

　　好比在vagrant V1.6版本中，vagrant集成了docker-based development environments,所以Vagrant能夠在windows，mac和linux上面提供docker服務。

　　vagrant沒有想替代docker的想法，相反它還包含了docker的一些特性。

　　若是咱們從邏輯層面來比較vagrant和docker的話，那麼：

　　一、docker只能執行docker所定義的容器。

　　二、docker缺少靈活的隔離方案(docker只能運行在Linux主機環境中)。

　　若是咱們從Production和CI層面來比較，那麼docker就沒法與vagrant相比了：Vagrant沒有上面的約束條件，而docker必須依賴它們。

　　若是你的項目必須使用Docker的容器，同時只能部署在Linux主機中。這個時候Docker的確是一個不錯的選擇。除此以外，我就看不到使用docker的優點了，相反你還浪費了vagrant不少的優勢：

• 
  

• vagrant能夠支持多種虛擬環境，例如 VirtualBox, VMware, AWS, OpenStack等等。不管你使用何種虛擬環境，vagrant均可以順利執行起來。若是你使用了Docker，也能夠在vagrant中順利安裝docker。

• vagrant能夠下降項目複雜度。或者換個說法：你只須要考慮如何執行你的項目就能夠，而不論這個項目是用的docker仍是什麼別的。在將來，若是出現了docker的競爭者，那麼vagrant也能夠順利執行它。

• vagrant能夠運行在多個主機環境中，windows(XP以上)，MAC(10.5以上)，Linux(2.6內核版本以上)。若是你使用了docker，那麼vagrant也能夠在上面三種操做系統之上運行你的docker。

• vagrant能夠更好的配置網絡和文件共享。好比：vagrant能夠給一個VM配置靜態IP和端口數據轉發。不論你使用的VirtualBox仍是VMware，vagrant均可以很好的完成配置。對於文件共享來講，vagrant提供了多種文件掛載方案供你考慮。若是你使用了docker，那麼這些事情就都須要你親自動手來作了。

• vagrant 1.6中集成了docker-based development environments。因此在MAC和Windows環境中，vagrant會自動啓動一個虛擬機來執行docker，這樣就達到了docker的跨平臺化。而背後例如網絡，文件等等操做都是vagrant默默完成的。

　　下面兩點是我聽到docker能夠替代vagrant的聲音：

• 
  

• "Docker須要移動的數據不多"的確，Docker有這個特色(應該指的是Docker採用的UFS，致使docker每次變更所需的數據不多--筆者猜想)。可是當你在每一個項目都使用docker，或者在每一個項目的如今，未來都使用docker時，你就會發現docker所產生的數據並很多。而若是你使用vagrant，那麼只須要移動一次就能夠完成。(原文:"It is less moving parts" - Yes, it can be, if you use Docker exclusively for every project. Even then, it is sacrificing flexibility for Docker lock-in. If you ever decide to not use Docker for any project, past, present, or future, then you'll have more moving parts. If you had used Vagrant, you have that one moving part that supports the rest).

• "Docker啓動很是快"，當使用docker啓動容器時，它比其餘虛擬機啓動的都快。可是我要說的是，目前從產品化角度分析全部vagrant主機基本都是啓動一次，而後再也不停機。若是從快速部署開發環境來講，docker這個特性真的是很是好。

 　　因此，咱們如今能夠得知vagrant和docker是有很大區別的，直接比較這兩個是不正確的。對於開發環境來講，vagrant是一種更爲抽象，更爲通用的解決方案。Docker所能提供的場景只是vagrant所支持的特殊場景之一。

　　在一些極端案例場景下，docker徹底能夠替代vagrant。但在更多的場景下，這是錯誤的。同時vagrant也不會封鎖你使用docker。

　　針對Mitchell的這些解釋，Hykes寫出了下述的論點：

　　若是你僅僅是想管理虛擬機，那麼你應該使用vagrant。若是你想快速開發和部署應用，那麼應該使用docker。

　　vagrant是一款管理虛擬機的工具，而docker是一款經過將應用打包到輕量級容器，而實現構建和部署的工具。二者適用範圍不一樣。一個容器就是一個包含了應用執行所依賴的數據(包括lib，配置文件等等)。它能夠保證應用在一個可重複的環境中隨時執行。

　　有了這個容器，就能夠很簡單的構建你的容器也能夠隨時隨地的進行部署。

　　Docker只能在Linux上面執行是一個很大的誤區！事實上，Docker能夠在MAC和Windows上面安裝。若是你在MAC上面安裝Docker，那麼會有一個大概25MB的精簡Linux VM來充當MAC和docker直接的交流者。一旦Docker安裝完成後，就可使用一樣的命令進行操做了。這樣，世界一下就美好了：你經過輕量級的容器能夠更好的測試和開發你的應用，而且很容易的將這些應用進行分發(好比經過 https://index.docker.io)。而你不須要了解如何管理這些虛擬機，而僅僅把虛擬機當作完成事情中的一個環節而已。

　　理論上，vagrant能夠做爲docker一個抽象數據層。理由以下：

• 
  

• 首先，vagrant不是對docker更好的抽象。vagrant設計使用來管理虛擬機的，而docker設計是用來管理應用的。這就意味着docker在設計之初就是爲了能夠經過多種方式來相互組合應用。在docker中processes, log streams, environment variables ,network links between components是最底層的原型。在vagrant中machines, block devices, and ssh keys是最底層的原型。vagrant工做在系統底層，它同另一個vagrant容器交互的方式只有把它當作一個能夠"boot"和"log into"的機器。所以，你能夠在docker上面安裝插件後，執行"vagrant up"命令後等待美好的事情發生。

• 其次，可鎖定的環境參數(the lock-in argument)。""If you use Vagrant as an abstraction, you will not be locked into Docker!"站在管理虛擬機的vagrant角度上面看，這句說沒有錯：Docker不是另一個獨立的容器。像EC2和VMware同樣，咱們要避免創造一個和其它工具相捆綁的東西。Docker對宿主機沒有任何要求，它容許你經過輕量級的容器在任意地方進行部署。在你部署應用時，不須要考慮應該部署到什麼環境中。好比說：你能夠在其餘人提供的主機(極可能上面已經部署了EC2或者vagrant)上面部署應用。

　　因此最後能夠說：Vagrant 適合用來管理虛擬機，而docker適合用來管理應用環境。

若是您認爲此文章對您有所幫助，請您點擊推薦。進步來源於思想的碰撞，因此歡迎你們踊躍留言評論。