本文是借鑑別人的文章,找不到原文在什麼地方了,若是侵權,請聯繫當即刪除...php
大規模的容器技術運用歷來不是一項獨立工程,而是一個聚集虛擬化技術、容器編排、任務調度、操做系統、容器倉庫、跨節點網絡、分佈式存儲、動態擴縮、負載均衡、日誌監控、故障自恢復等系統性難題的複雜有機體。隨着Docker的誕生和Google等互聯網公司的推波助瀾,這個領域出現了一大批優秀的開源項目,它們在簡化容器技術使用成本的同時,也常常使得剛剛接觸容器時間不太長的開發者和企業用戶感到不知所措。linux
將知識分類是梳理零散信息的一種有效方式。對於容器技術的生態圈來講,其中涉及領域衆多,有的項目橫跨多個細分領域,有的項目則是針對特定場景需求定製的,難以對其功能類型作精肯定義。不過,若僅考慮通用領域裏的相關產品和工具,大體來講能夠劃分紅14種主要類別。ios
如下將圍繞容器生態,分別舉例介紹這些類別中的典型開源項目,以及部分雖未開源但比較經常使用的100個周邊產品。git
容器引擎是容器集羣生態圈的核心部分,它是與內核Namespace和CGroup等功能直接交互,並提供相應API使得外部可以與之集成的工具或服務。Docker無疑是目前爲止最成功、普遍最使用的容器引擎之一。實際上從1.12版本之後,Docker的容器化功能已經由獨立的項目RunC來實現,但Docker仍做爲一個開源產品爲用戶提供完整的容器化解決方案。此外,社區中還有許多容器引擎項目,例如:github
這些項目只是衆多支持不一樣平臺和具備不一樣特性的容器引擎的冰山一角。例如Google曾經主導的lmctfy(http://lmctfy.io/)項目也是個十分優秀的容器引擎,然而該項目自2015年之後就再也不被維護了。而最近Google剛剛開源的gVisor則是該領域中的新秀。另外值得一說的是,Hyper採用虛擬機的方式對環境進行隔離,並非一種基於容器的隔離方案,但它能很好地與Docker或Kubernetes等容器集羣技術相結合,取代其環境隔離的功能,所以也歸屬此列。docker
因爲容器基於內核的特殊隔離方式,對容器性能和狀態的監控與虛擬機存在一些差異。傳統的虛擬機監控工具,例如Nagios和Zabbix等,對容器監控的原生支持並不十分易用。而一些新起的開源項目對這種場景具備更友好的體驗,例如:apache
其中的TICK-Stack指的是Influxdata推出的Telegraf、InfluxDB、Chronograf、Kapacitor四款開源工具,不過從1.0之後,這些工具在開源版基礎上提供了企業版本,後者提供了例如高可用、雲端存儲等企業級功能。api
可視化是用戶友好性十分重要的一部分,Shipyard和Decking是Docker早期時十分受歡迎的可視化工具,以後Docker也收購了Kitematic做爲官方的容器管理UI。但隨着容器應用集羣化,早期的UI工具再也不流行,一些針對特定集羣平臺定製的新型管理UI開始出現。例如Kubernetes官方推出了Dashboard項目用於可視化的管理集羣,Cockpit則是紅帽公司推出的Kubernetes集羣管理界面。如下是其中一些開源的容器管理UI項目:安全
DockStation:https://dockstation.io網絡
容器集羣的實施是須要以硬件基礎設施做爲依託的,有些輔助工具可以簡化這個過程。這些項目每每與具體的底層平臺相關,例如:
Nova-docker和Magnum都是在OpenStack集成容器集羣的項目,不過目前OpenStack官方正在嘗試經過讓Kubernetes直接建立虛擬機的方式來統一它在IaaS層和CaaS層的差別,其中的Nova-docker已經被廢棄了。Machine是Docker公司推出的基礎設施管理工具,Boot2Docker曾經是在Windows和Mac上使用Docker的官方方案,但隨着Docker 1.12版本發佈了多種操做系統的發行版後,已經再也不被推薦使用了。
編排和調度是容器集羣的基本功能,所以選擇編排和調度工具實際上就是在選擇容器集羣的方案。如下是一些開源的容器任務編排調度工具:
其中的OpenShift主要是指其3.0以後的發行版,它是紅帽公司基於Kubernetes二次開發的集持續集成和交付於一體的容器集羣方案,具備開源和商業兩個版本。
鏡像倉庫是基於容器的在軟件發佈流程中必要的組成部分,Docker開源了其鏡像倉庫的最小實現,但對於企業級應用來講,它缺乏了高可用、權限控制、管理界面等必要功能。Docker Hub和國內的許多容器雲平臺都提供了公有云的企業級倉庫服務,社區中也有一些容器倉庫的開源或免費的實現,例如:
其中的Nexus是一種通用的軟件包倉庫解決方案,支持包括Maven、NPM、PIP、RPM等許多主流打包格式的分發和管理,它是在3.0之後的版本中開始支持做爲Docker鏡像倉庫的。VMWare推出的Habor是目前相對經常使用的企業級開源Docker倉庫解決方案。Portus和Docker Registry UI是基於官方Repository鏡像倉庫的界面化管理工具。Dragonfly是一款P2P協議的鏡像分發工具,並不是直接提供鏡像存儲功能,但也屬於倉庫輔助類的工具。
服務發現和域名服務其實是微服務架構和容器集羣的調度工具所需的組件,它們在容器集羣中十分常見,也是這個生態圈中舉足輕重的一部分,如下是其中一些在實際工程中被說起較多的工具:
和容器集羣的監控同樣,收集容器中的服務運行日誌與虛擬機中的方式一樣存在許多差別。目前Docker直接經過插件可以支持的日誌收集工具包括Rsyslog、Splunk和Fluentd,雖然FileBeat不在此列,但因爲其小巧便捷的部署機制,也獲得了許多用戶青睞。一些過去用於虛擬機的日誌收集器,好比LogStash或Flume,一樣可以使用與容器中的服務,但它們都再也不是首選的方案。
ElasticStack是Beats、Logstash、ElasticSearch和Kibana四款開源項目的統稱,這是一套十分流行的日誌匯聚、處理、存儲和展現的工具組合。其中的ElasticSearch和Kibana也能夠與Fluentd配合,造成端到端日誌處理方案。另外值得指出的是,Splunk並非開源或免費的,但它在企業級日誌處理方案中的應用十分普遍。
有些Linux發行版是爲容器運行而優化的,Atomic和ClearLinux系統都屬於此類。另外一些Linux發行版在設計之初就充分地將容器機制融入了系統的架構理念,例如CoreOS。有的系統甚至將Docker做爲系統的核心服務來管理其餘用戶進程,例如RancherOS和Hyper容器引擎所使用的操做系統。相似的項目還有許多,它們都是架設容器集羣時十分稱手的基礎設施,例如:
SmartOS:https://www.joyent.com/smartos
容器平臺是大規模容器運用的產物,它一般會與持續集成、持續交付的工具結合,成爲鏈接上層應用服務和底層基礎設施、幫助使用者快速實現從代碼提交到產品上線全過程的端到端交付過程。如下是其中一些相關的開源項目:
除了這些開源的容器平臺服務實現以外,互聯網上還有許多在線按量付費的容器即服務平臺,它們也是整個容器集羣生態的一部分。
容器技術在解決環境隔離和配額問題的同時,也引入了網絡層面的複雜性。因爲使用了Network Namespace,每一個容器均可以得到獨立的IP地址,這對於單個主機的狀況並沒有大礙,但對於容器集羣的狀況,IP地址的分配和互聯就成爲了新的問題。所以在設計容器集羣時,一般須要專門爲網絡的鏈接方式加以考慮。經常使用的開源方案例如:
這些網絡方案大多采用了七層網絡的Overlay Network方式,也就是在容器之間通訊的網絡包上封裝了用於路由尋址的額外包頭,這種方式會致使網絡通訊效率的降低,具體影響程度與所封裝的額外數據大小有關。而Calico採用修改每一個主機節點上的IPtables和路由表規則實現容器間數據路由和訪問控制,屬於三層網絡的方式,這種方案在節點規模不太大(最多幾百個節點)時的效率優點十分明顯,是一種比較受推薦的容器網絡工具。除了這些較經常使用的方案外,一些條件容許的企業也會結合MacVLAN等二層網絡方案實現容器的互聯,以得到更好的網絡性能。
容器安全性問題的根源在於容器和宿主機共用內核,所以受***的面特別大。另外,若是容器裏的應用致使Linux內核崩潰,整個宿主機系統都會崩潰,這一點與虛擬機是不一樣的。此外,鏡像的安全性也是容器安全的一部分,如何保障用戶下載的鏡像是可信的、未被篡改過的,以及如何保證鏡像中不會意外包含具備大量漏洞的老舊軟件都是須要考慮的問題。目前這些安全課題主要在一些企業級應用中引發較多重視,下面是一些相關的開源工具和項目:
容器是一種不可變的基礎設施,容器的數據應該經過Volume的方式保存到外部的介質上,容器持久化存儲本質上就是要解決如何簡便地將外部存儲掛載到容器中使用的問題。Docker在1.9版本後提供了存儲的插件,這也爲許多存儲方案提供了便利,如下列舉幾個例子:
其中Ceph是通用的網絡存儲工具,同時提供塊存儲和對象存儲能力,對容器化場景下的應用數據持久化具備良好的支持。
容器的鏡像能夠被看做一種新型的應用打包方式,所以容器經常與軟件的開發和持續集成、持續交付流程相結合,提供不一樣環境一致性部署能力。如下是一些利用容器改善軟件開發和交付的工具或平臺: