如何理解LXC與Docker之間的主要區別

這篇文章從兩個部分來探討LXC,LXC和Docker的容器託管,以及輕便的容器技術將取代虛擬技術的可能性。sql

LXC有可能會改變咱們如何運行和縮放應用程序。Dr.Rami Rosen 作過一個很棒的演示文稿,是關於LXC的前世此生,其中還不乏有趣的觀點和內容。docker

二者的概述

容器技術獨立運行而且從主機系統上封裝應用程序工做量。把容器想象成能夠安裝和運行應用程序的主機操做系統裏面的操做系統,從實用目的來說,它就像一個虛擬機。shell

LXC項目給不一樣配置和用戶空間應用提供最小的容器操做樣原本管理容器生命週期, LXC項目的這個特性和Linux內核使模仿機制可以正常啓用。數據庫

便攜性

容器技術將應用從主機操做系統上解耦下來,摘錄該程序而且使之在任意支持LXC的系統上都實現輕便化。低調的說法就是:很是好用。用戶在這樣一個原始和最小庫的Linux操做系統上能夠在容器裏運行任何程序(就像是在容器裏運行LAMP堆棧)。安全

由於應用程序和工做量是相對獨立的,因此用戶能夠運行多版本的語言,好比PHP,Python,Ruby,Apache,這些語言均可以共存,隱藏在容器裏。實現雲計算,就比如是這些例子和工做量均可以靈活的被移動到別的系統,複製,以及快速配置。bash

難道虛擬技術就作不到嗎?

不不不,虛擬技術也能夠作到,可是會有必定程度的性能損失,靈活度也會降低。容器技術不是模仿硬件層次,而是在Linux內核裏使用cgroup和namespaces來打造輕便的、將近裸機速度的虛擬技術操做系統環境。由於不是虛擬化存儲,因此容器技術不會管底層存儲或者文件系統,而是你放哪裏,它操做哪裏。網絡

這從根本上改變了咱們如何虛擬化工做負載和應用程序,由於容器速度比硬件虛擬化技術更快,更加便捷,彈性擴容的更加高效,只是它的工做負載要求操做系統,而不是Linux或特定的Linux內核版本。架構

那VMWare就這樣玩完了?

沒那麼快!虛擬技術相對成熟,又有普遍的工具,還有生態系統來支持它在不一樣環境下的配置。至於工做負載,它要求非Linux操做系統,或者只能使用特定的核心虛擬化技術。app

LXC

LXC起源於cgroup和namespaces在Linux內核方面的發展,它支持輕便的虛擬技術操做系統環境(容器技術),Daniel Lezcano和Serge Hallyn作了一些它的早期工做,這個能夠追溯到2009年在IBM的時候。LXC系統提供工具來管理容器,先進的網絡和存儲支持,還有最小容器操做系統模板的普遍選擇。它目前由一個兩人的團隊領導:來自Ubuntu的Stephane Graber和Serge Hallyn。LXC是由Ubuntu支持的。ssh

如何區分他們

生產Docker的目的是爲了儘量減小容器中運營的程序,減小到只運營單個程序,而且經過Docker來管理這個程序。有了Docker,能夠從底層應用程序經過Docker來配置,網絡,存儲和編排。LXC用正常操做系統環境迴避那個問題,而且所以能夠快速兼容全部應用程序和工具,以及任意管理和編制層次,來替代虛擬機。除此以外,Docker使用層次,禁用存儲持久性。LXC支持AUFS層次和覆蓋,對COW克隆和用brtfs、ZFS、LVM Thin快照普遍支持,而且將選擇留給用戶。LXC容器技術裏的分散存儲是綁定安裝的,來爲用戶達到主機或者另外一個容器。Docker和LXC都設置了一個默認的NAT網絡。另外,Docker設置一個端口轉發到主機上,就會有一個-p標記,好比「-p80:80」就是80從主機轉發到容器。有NAT,本地主機就能夠直接經過IP訪問容器,外部服務須要的時候能夠經過IPtable規則來簡單完成,當外部服務被消耗的時候,只須要端口轉發就能夠。至於爲何須要這麼作,緣由目前還不是很明確。要把事項複合起來,Docker只給了不多的IP和主機文件控制權,因此不能給容器設置靜態IP,這對於IP的分配任務來講有點讓人疑惑。咱們須要使用「--Links」標記來鏈接容器,這個容器中要在被鏈接的容器中加一個入口在/etc/主機上。有了LXC,分配靜態IP,動態IP,使用多網絡設備就簡單多了,可使用/etc/hosts文件,基本上使用Linux網絡全棧是沒有限制的。您但願在主機上鍊接容器嗎?用戶使用GRE,L2TPV3或者VXLAN來快速設置層次,或者是任意的在使用的網絡技術。LXC容器技術能夠無縫運行虛擬機運行的一切。

Docker

Docker是dotcloud也就是如今的Docker公司在2013年3月發佈的,一開始是基於LXC項目來建立單個應用程序容器。Docker如今已經開發了他們本身的直接使用核心namespaces和cgroup的工具:lib container。

分層容器

Docker最開始是基於LXC對Aufs的支持來創建分層容器,由於Aufs可能沒法被合併到核心中,因此如今對Brtfs、設備映射和覆蓋也添加支持,Docker容器技術是由基底鏡像構成,當提交變成Docker鏡像的時候會再加上一個分層面板。當運行一個鏡像的時候,它的複本就做爲容器被啓動了,在提交以前,它的任何數據都只是暫時的。每個提交都是一個獨立的鏡像,因此能夠從鏡像開始。咱們在《如何用LXC覆蓋》裏有一個指導說明,它給用戶描述了分層結構是如何工做的。有了像Aufs或者覆蓋(他們在實施上、性能上有區別,並且支持必定數量的低一點的層次)這樣的文件系統的聯合,較低一點的層次是隻讀的,而較高一點的層次是在運行的時候是可讀可寫的。在容器內容中一般是基底操做系統,可是也不是很必要,而上層的圖層面板則是由你來修改。雖然圖層面板的想法聽起來很不錯,可是分層文件系統在技術上仍然是不成熟的,在使用圖層面板的時候,還有有一個固有的複雜性和性能的損失。《陷入圖層面板》是一個真實的冒險實例,你們不妨看看。

單個應用程序容器

Docker將容器技術限制到只能運行單個進程。Docker的底層鏡像操做系統模版不是爲運行多個應用程序,進程設計,也不是爲像init,cron,syslog,ssh等服務而設計。咱們來看早期的東西,它介紹了日復一日的用戶場景有必定的複雜性。由於目前的架構,應用程序和服務是爲正常的多程序操做系統環境設計的,因此須要去尋找一種以Docker的方式來工做或使用工具來支持Docker。拿一個簡單的應用程序舉個例子,好比WordPress。你可能須要創建3個容器來互相消耗服務。PHP容器,Nginx容器和MySQL容器加上2個分別用來放MysqlDB和WordPress文件持久性數據的容器。而後經過適當的權限將WordPress文件安裝成PHP-FPM和Nginx兩種語言均可用,而後爲了把東西弄得更加讓人興奮,找出一種可以讓容器在本地網絡上能夠互相交流的方法,不須要對網絡不定時的控制,也不須要Docker後臺程序設置IP!可是咱們尚未計算WordPress帳戶管理的cron和Email。哎!爲了在Docker裏運行多個程序,你須要shell 腳本,或者是一個分開的程序管理,好比runit或者管理器。可是Docker生態系統會將之視爲「反模式「,並且Docker的整個架構是創建在運行單個程序的容器上的。

代碼庫

Docker爲用戶提供公共或者我的push和pull鏡像的數據庫。這個跟Flockport app Store爲用戶使用容器作好準備有點類似。這樣作,對用戶來講,分享和分佈應用程序就很簡單了。

Dockerfile

Dockerfile是一個告訴Docker如何從鏡像用特定的應用程序來建立容器的腳本。跟使用特定的安裝好的應用程序經過bash腳原本建立一個LXC容器類似。

跟LXC拉開距離

LXC的特色須要經過Docker團隊來重載實現,使之在Docker中可用,好比LXC如今支持讓非根用戶建立和配置容器的未經受權容器,LXC如今還致力於實時遷移和多主機管理。這些對容器來講都是很大的進步,也爲更好的安全性,多租戶工做量以及虛擬平價鋪平了道路。Docker還不支持這些。隨運行容器的方法沒有對錯之分,容器怎麼用主要取決於用戶,docker方法是獨特的,並且還將在每一個階段自定義途徑成爲必須途徑,並以此來找到Docker的方法從安裝和運行應用程序來完成任務,完成彈性擴容。

前景

虛擬技術經過操做系統和應用程序被凍結在一個狀態,使雲計算成爲可能,並將之轉化爲能夠從硬件和操做系統上輕易轉移。操做系統添加了不少:速度,靈活性以及可移動性,擴大了潛在價值。Docker擅長用dockerfile和提交將容器和覆蓋文件系統包裝到一個友好的開發者模型中。只有當你在一臺單獨的筆記本上操做的時候,像託管,監視,存儲和網絡這樣的彈性擴容問題纔會讓這個模型複雜脆弱。另外一方面,操做系統容器在操做系統性能上跟虛擬機的類似,這使得運用目前的工具,來集成到正常和分佈式系統更加簡單,不須要開發任何單獨的工具。Docker公司受到風投支持,積極投入市場。衆多用戶在Docker的內容中據說到容器技術,可是並不清楚操做系統容器技術以及本身所熟悉使用的。能夠看到,用戶單純但願運行容器,就好像運行一個輕量級的虛擬機同樣,他們拼命的想作到運用單個應用程序的容器技術,分層結構和持久存儲。若是將工做量從虛擬機轉移須要額外的工程工做量,那麼不少大規模用戶和企業根本不會考慮,並且轉移以後,將跟他們其餘基礎設施的網絡,存儲和託管都不兼容。LXC就是這樣得到認可的,不是執拗己見,它有容器技術全部平行計算的優勢——從虛擬機無縫過渡到LXC,而不須要架構師從新架構,這真是一個難以想象的價值主張。

(若是須要轉載,請聯繫咱們哦,尊重知識產權人人有責)

相關文章
相關標籤/搜索