1. 程式人生 > >如日中天的Docker解決了什麼問題?

如日中天的Docker解決了什麼問題?

      毫無疑問,DocKer成了近些年來最火熱,甚至最具顛覆性的技術之一。國際上,所有泛雲端計算相關的公司,幾乎都在某種程度上宣佈支援並整合Docker。在2014年6月的DockerCon中,很多公司都分享了他們自己如何和Docker整合的故事。雖然每家公司用著各自不同方式實現著不同程度的同Docker的整合,但他們都一致認識到了Docker可能會為他們帶來的潛在收益。Microsoft,Amazon,IBM,Google,Facebook,Twitter,Red Hat,Rackspace和Salesforce等諸多公司共聚一堂,共同支援某一技術的場面似乎也不是我們經常能看到的。同時,國內眾多泛雲端計算公司,網際網路公司,甚至相對傳統的IT廠商也對Docker多有關注。

► 為什麼像Microsoft或者Amazon這樣的巨頭會支援Docker?
► 為什麼像之前的PaaS玩家,如Heroku和Google,也在Docker身後,搖旗吶喊?
► Docker的出現,是不是為所有的這些廠家提供了一個新的領域,新的競技場?
► Docker真的能融合IaaS和PaaS麼?
► 我們又真的能相信上面的提到的廠家會持續的無條件的支援Docker麼?

這一系列的問題,在已經過去的2014年並沒能給出答案,但在2015,相信一切會逐漸明朗。

似曾相識的歷史

     如果說在這之前,還有哪項技術獲得了類似的業界的廣泛支援,我想是Java。當Java在上世紀90年代釋出的時候,每一家公司都表示了極大的興趣,直到他們意識到Java實際上對他們自有的平臺其實是一種巨大威脅。Java的願景是“Write Once,Run Anywhere”, 而Docker提出了“Build once,Run anywhere,Configure once,Run anything”。很大程度上,二者都對某些公司形成了潛在的威脅。儘管我們目前還看不到具體的一些公司針對可能的威脅採取的應對措施,但未來是誰也無法保證類似Java或VMware的歷史不會重演。

目前,實際上泛雲端計算領域一些重量級廠家,無論是IaaS廠家, VM廠家還是SaaS廠家,無論是國際公司,還是國內企業,都在持續密切關注Docker,並評估Docker對自身業務的影響。

Docker的架構


  從上圖,我們可以看到,容器由於省去了作業系統,整個層級更簡化,可以在單臺伺服器上執行更多的應用,而這正是IaaS所需要的,可能5G右的空間,對你來說不是什麼大事,但是如果你需要對外提供成千上萬的主機,那就是不得了。
普通虛擬機器將整個作業系統執行在虛擬的硬體平臺上
,進而提供完整的執行環境供應用程式執行,Docker則直接在宿主平臺上載入執行應用程式.本質上他在底層使用LXC

啟動一個Linux Container,通過cgroup等機制對不同的container內執行的應用程式進行隔離,許可權管理和quota分配等每個container擁有自己獨立的各種名稱空間(亦即資源)包括:PID程序, MNT檔案系統, NET網路, IPC, UTS主機名等。


傳統虛擬化

  若干年前,當VMwae剛剛開始提供工作站虛擬化服務的時候,也許很少有人能想到它現在能成為企業IT服務中的主要力量,能取得現在的成就。隨後的幾年內,VMware已經將虛擬化擴充套件到伺服器,而現在更是已經擴充套件到雲端計算領域。對於Docker及其生態系統而言,借鑑傳統虛擬化的經驗,最終提供更安全,更健壯的生產環境的服務也應是Docker的目標之一。事實上,目前在裸機上直接執行Docker也成了傳統VM之外的另一種選擇。

     坦率的講,相較傳統虛擬化而言,Docker的一系列的問題仍亟待解決,如缺乏成熟的管理工具,生態系統雖大但仍不完善。但我們仍然認為,Docker或者說容器虛擬化技術仍有很大機會能夠解決這些問題,並最終取得相當的成功。

CaaS:容器即服務

  目前,已經有一些新興公司,以有些類似IaaS的方式,提供容器服務(Containers as a Service)。長遠來看,也許CaaS的這種模式的出現,會使跨IaaS平臺的動態排程容器、移動容器成為可能。就像IaaS的客戶不需要關心其虛擬機器的實際品牌一樣,CaaS的客戶也不需要關心他的容器到底是執行在AWS還是阿里雲上。客戶將會自己選擇期望的地理位置,以及他們想要的容器執行,然後CaaS服務商將提供自動化的程式幫助進行資源調配,幫助客戶選擇最便宜的或最合適的公有云平臺。

     儘管這種在IaaS之上提供Docker容器的商業模式仍待討論和觀察,但Docker已經取得了巨大的影響力,如果Docker今後能在更多的企業,特別是企業的實際生產環境中發揮作用,我們認為CaaS同樣是可以期待的。

對IaaS廠家的影響

  從創業公司到IT巨頭,每一家公司都已經意識到或者逐漸意識到基於硬體的虛擬化的所為企業帶來的益處。公有云廠商,如AWS、Azure所提供的IaaS服務更多越來越像水、電、煤等公共服務。而Docker的出現,則便於這些IaaS廠商提供更細粒度計算資源,進一步提高資源利用率,縮短資源開通時間,進而為進一步壓縮公共雲服務的成本提供了可能。對於如負載平衡、快取和防火牆這些其他的IAAS的提供的服務而言,也可通過將其遷移到容器中,以提供更好的可移植性。

     同時,對於混合雲而言,VMware vCHS(vCloud Hybrid Service)和微軟 Azure都在各種強調自身VM的可遷移性。而事實上,由於容器相比傳統的VM更輕量,Docker容器可以動態地設定和遷移。從資源的利用率和可用性的而言,Docker是非常適合部署在混合雲中,並能夠更好的發揮混合雲的能力。

對PaaS廠家的影響

  相比於IaaS,PaaS實際上起步更早。PaaS的初衷最是為了幫助開發人員實現夠資源的自動調整,而不必面對IT基礎設施管理的問題。早些時候,人們曾經預計PaaS將超越 IaaS,成為雲端計算領域中增長最快的市場。但幾年後,由於Amazon在IaaS領域的巨大成功,使得早期的PaaS玩家,如Microsoft和Google意識到,IaaS相比PaaS而言,壁壘較低,更容易取得市場的認可。所以現在Microsoft和Google除了在原有的PaaS領域外,在IaaS領域也和Amazon展開了激烈競爭。

  就PaaS而言,PaaS廠商希望提供規範、一致的環境,而企業應用,無論是從開發、管理還是運維上都有各種個性化的需求。二者之間這種很難克服的衝突阻礙了市場的對PaaS的認可和接受。另外,每一PaaS廠商都在為應用提供各自的服務和API,這就造成了應用在PaaS廠商之間的移植是很困難的。一些組織在PaaS的遷移方面做了積極嘗試,甚至希望能實現跨雲服務提供商的遷移。但是由於沒能得到類似Google App Engine和Microsoft Azure這樣的廠家支援,目前這些工作還還很難成為事實上的行業標準。

  Docker的出現使PaaS以更簡潔的方式為開發者提供服務成為了可能,Cloud Foundry目前也開始支援並整合Docker容器。有了Docker,開發人員不再需要為處理各種開發、 測試、生產環境的差異而花費大量精力,他們可以將一個乾淨的開發環境直接遷移到生產環境,而不必擔心各種依賴和配置問題。這有效的解決了開發者經常面臨的“依賴陷阱”。開發者不再需要為了使應用能夠在PaaS中執行而學習額外的程式設計方式,他們的應用不需任何調整就可執行在Docker容器中。同時,Docker出現之後,開發者越來越多的考慮以Micro Service(微服務)的方式來實現他們的應用。長遠來看,Docker將會使PaaS更易管理,更快地提供服務。

  總體上說,Docker已經對仍在不斷變化、演進的PaaS市場產生了影響。但這種影響究竟會加速PaaS的演進,打亂PaaS的演進,還是兼而有之,目前言之尚早。儘管目前還不是非常成熟,但Docker通過容器級虛擬化的方式,仍為樂於嘗試的企業提供了一個解決環境依賴和可移植性問題的方案。

跨雲的管理工具

  多雲管理軟體通常被稱為雲端計算管理平臺 (CMP)。CMP通過對底層雲平臺的抽象, 幫助客戶來定義應用部署的拓撲結構。這種拓撲結構是獨立於具體的雲提供商或者雲平臺的。客戶可以通過CMP來選擇的具體的某一雲平臺來部署自己服務。通過CMP,客戶永遠不必處理具體某一雲平臺的特定的使用者介面或API。這樣,通過CPM,會把所有的雲平臺置於一個相同的公平競爭環境。

  為避免被具體的雲平臺繫結,CMP一般只使用雲平臺提供的基礎的計算單元,資料塊儲存,物件儲存網路服務。一些CMP還將將自己的負載均衡、 資料庫服務和應用服務部署到每個雲平臺。這樣會進一步避免將應用繫結到具體某一雲平臺。舉例來講,當客戶在AWS上進行災難恢復的時候,通過CMP,他們也可以選擇在自己的基於傳統VM的私有云環境中執行他們的應用。

  在很多方面,Docker提供了類似CMP的跨平臺移植能力。客戶可以通過Dockerfile宣告一個Docker映象和相關的拓撲結構,並把映象build到具體的雲平臺中。與CMP類似,通過Docker,也可以將額外管理所需的網路、資料庫等服務以容器的方式部署,進而滿足各種具體的需要。

  同時,一些新的基於Docker的管理工具也提供了多雲平臺的容器管理功能。事實上,這同CMP的功能有所重疊,而一些CMP廠家也正在評估Docker的影響。

  像PaaS一樣,我們不確認Docker到底會增加對CMP的需求,抑或反之?

  同時,Docker的出現會不會讓應用的故障追蹤以及處理變得更復雜?而云計算管理平臺會不會整合對Docker的管理?

對傳統ISV的影響

  對於傳統ISV而言,在整個SDLC(Systems Development Life Cycle)環節中引入Docker,可能會成為一種趨勢。Docker的引入,除了在ISV內部的開發、測試中會極大的解決配置依賴等問題,進而提升整體效率。 我們認為,以容器為核心的持續整合和持續交付,最終將容器作為ISV向客戶、向客戶的雲平臺交付的實體,對於ISV及其客戶而言,都會有很大的效率提升。

  雖然目前,我們不清楚究竟是更多的ISV向其客戶推薦了Docker,還是更多客戶要求ISV基於Docker進行開發,還是兩種可能都會有。但我們相信,Docker在企業應用市場,類似之前的VMware,會得到廣泛應用。

對DevOps的影響

  目前市場上雖然有很多各種各樣的DevOps工具,希望幫助解決開發人員和運維人員之間的Gap。但Docker的出現,事實上提供了一種同Devops理念非常契合的框架。基於Docker:

► 開發人員可以更專注於他們的程式碼,而不用擔心如何在生產環境中執行他們;
► 運維團隊在部署的時候,可以視容器為一個獨立的完整的模組;
► Docker分層的檔案系統,使環境配置易於管理、維護;
► 像Git工作流一樣,通過Dockerfile,即便是複雜、異構的開發、測試環境,仍然可以高效的管理;
► 即便在同一個VM中,多個容器仍能執行多種不同的環境;
► …..

  我們認為Doker很有可能會對Devops的生態系統產生重要影響,甚至很有可能從根本上改變開發、運維的協作方式,並對市場上已有的持續整合,持續部署的解決方案造成重大影響。

這段時間Docker實在是如日中天,到處都是它的資訊,它是什麼?你認為它解決了什麼問題?有哪些應用場景?

我們先來了解一下傳統上的程式開發流程,這樣有助於更清晰地瞭解Docker.



  而對於Docker,簡單的說Docker是一個構建在LXC之上的,基於程序容器(Processcontainer)的輕量級VM解決方案拿現實世界中貨物的運輸作類比,為了解決各種型號規格尺寸的貨物在各種運輸工具上進行運輸的問題,我們發明了集裝箱。


Docker的初衷也就是將各種應用程式和他們所依賴的執行環境打包成標準的container/image,進而釋出到不同的平臺上執行。



  從理論上說這一Dockercontainer概念並不新鮮,各種虛擬機器Image也起著類似的作用。Docker container和普通的虛擬機器Image相比,最大的區別是它並不包含作業系統核心

  Docker到底做了什麼,這個問題顯然沒有標準答案,面試官只是想看看你是否有自己的想法,是否對新技術保持敏感,如果你的觀點跟面試官不謀而合,絕對加分)。

   關於docker解決的問題,下面都是筆者個人看法:

1、程式在我這跑得好好的,在你那怎麼就不行呢?!

     這是一個典型的應用場景,Docker image中包含了程式需要的所有的執行時依賴,比如java的程式,肯定要在image中包含jdk;比如Python的程式,肯定要在image中包含對應版本的Python直譯器。程式在我這跑得好好的,去你那就不行了,顯然是環境問題。Docker把整個執行時環境打包放到image中,所以搞定了環境依賴問題

     這點很重要麼?真的很重要!如果你做過部署或釋出系統將會對此感觸頗深。

     我們知道,一個程式要跑起來,需要這麼幾部分:程式碼 + 執行環境 + 配置 + 依賴的服務。程式碼當然就是同一份程式碼,不同的環境都一樣,通常不會有問題,Docker image中包含了執行環境+配置,這對部署相當友好。如果你沒有做過這種系統(其實大部分人都沒有做過啦),但是你肯定裝過軟體,裝一些複雜的軟體的時候有沒有因為版本依賴或者編譯引數等讓你抓狂?用了Docker再也沒有這種問題了:

  1. docker pull xxx;   
  2. docker run xxx;   
  3. done:) 

     所以總結起來就是:Docker解決了執行環境和配置問題,方便釋出,也就方便做持續整合

2、系統好卡,肯定是又有哪個哥們的程式在作孽了

     現在的伺服器都牛的很,動不動128G記憶體,24個CPU,Linux本身就是個多租戶的作業系統,可以多人共用,但是如果某個程式狂吃記憶體和CPU,佔用了太多系統資源,這就會影響其他程式的執行。

     一個公司的幾個同事共用一臺機器出現這種問題可以通過內部協調溝通解決。但是雲主機提供商呢?不同的使用者之間不認識,共用一臺強大的計算機,結果某個程式耗盡了資源,使用者肯定不樂意了。

     所以虛擬機器出現了,良好了做了資源隔離,不同使用者之間彼此老死不相往來,不會相互影響,世界一下子清靜了。但是,虛擬機器有缺點:建立速度慢,遷移起來麻煩,因為中間加了一層guest os,有了效能損耗,一個牛逼的機器也就建立十幾個虛擬機器,太浪費了……

     相對虛擬機器的重量級虛擬化方案,Linux核心級的一些隔離方案讓人們看到了希望,cgroups、namespace、tc、quota、chroot、lxc,終於,Docker出現了,Docker利用這些成熟的技術,讓虛擬化變得輕量了起來,建立一個container瞬間完成,秒級!cpu指令集不再被翻譯執行,效能損耗非常少,雖說隔離性沒有虛擬機器那麼徹底,安全性上稍差一些,但也基本可以用,不用太擔心:)

所以總結起來就是:更輕量的虛擬化,節省了虛擬機器的效能損耗

上面兩點是Docker解決的問題,那它有哪些應用場景呢?

其實從上面的描述中也基本可以窺其一二了

1、程式分發,gitlab的安裝很噁心吧,所以有人做了gitlab的image

2、部署釋出,這點對運維的同學很有幫助

3、PaaS,tsuru、flynn都是基於Docker的,CloudFoundry也要從warden遷移到Docker,不解釋

寫在後面的話

Docker正在面臨Java之前所面臨過的類似的挑戰。鑑於Docker很可能打亂甚至顛覆現有市場,目前很多公司正在密切關注並且評估Docker對自身業務的影響,如果需要,我們相信這些公司會以不同方式向Docker公司施加影響。Docker公司在未來也許會變得更加謹慎。

但我們更願意從另外一個角度來看,我們相信,以Docker為代表的這一類容器虛擬化技術已經取得長足進步,無論Docker公司本身未來如何,容器虛擬化技術的進步以及推廣,必將帶來深刻的產業影響。