Docker容器技術淺析

容器技術出現的背景

服務器時代

在服務器時代，應用直接跑在服務器上。業務部門想要增長一個新的應用服務，IT部門就須要採購新的服務器服務器來知足需求，而IT部門爲了避免讓業務因爲服務器瓶頸而出現問題，就會採購大幅因爲業務需求的服務器。這種作法，致使了公司大量的服務器處於低負荷運行狀態下，浪費了大量的資源和資產。

虛擬機時代

而虛擬機技術解決了如上的問題，經過虛擬機技術，實現了一個服務器安全穩定運行多個應用。虛擬機是一種有劃時代意義的技術，每當業務部門須要增長應用的時候，IT部門直接在空閒的服務器上啓動虛擬機就能夠部署應用了，從而大大增長了服務器的利用率，爲公司節省了大量資金。

虛擬機技術也有本身的缺點，最大缺點爲每一個虛擬機必須擁有本身獨立的完整操做系統，而操做系統自己會佔用額外的cpu，內存和存儲資源。而且，每一個操做系統自己須要許可證，打補丁，監控等，從而增長了運營成本。虛擬機技術也面臨啓動速度慢，跨平臺移植性差的挑戰。

容器時代

容器技術能夠很好的解決虛擬機的缺點，能夠把服務跑在容器中解決虛擬機模型的缺點。對比虛擬機主要區別在於容器運行不須要獨佔一個完整的操做系統。運行在同一主機的容器能夠共享主機上的操做系統，這樣就節省了大量的cpu，內存和存儲資源。容器也不須要許可證和打補丁，下降了運營和資金成本。

現代的容器技術起源於Linux，是不少人長期努力持續貢獻的產 物。對容器發展影響比較大的技術包括內核命名空間 (Kernel Namespace) 、控制組(Control Group) 、聯合文件系統 (Union File System) ，固然更少不了Docker。因爲容器技術的複雜性，阻礙了其大規模發展，而Docker技術的出現，使容器使用變的簡單，促使了容器的廣泛應用。

Docker簡介

Docker是一種運行於Linux和Windows上的容器平臺，用於建立、管理和編排容器。Docker是在GitHub上開發的Moby開源項目的一部分。 Docker公司，位於舊金山，是整個Moby開源項目的維護者。Docker公司還提供包含支持服務的商業版本的Docker。

Kubernetes做爲容器編排領域的老大，已經採用Docker做爲其默認容器運行時 (container runtime)，包括Kubernetes啓動和中止容器，以及鏡像的拉取等。

Docker優點和劣勢

優點

對於開發團隊

1，部署簡單易用，開發團隊能夠獨立輕易的變動基礎環境。
2，測試時的鏡像環境就是最終產品運行的服務端環境，增長了測試可靠性。
3，一旦Docker鏡像構建成功，咱們就會在交付的各個階段都是用這個鏡像，這就提升了交付的可靠性。

對於運維團隊

1，減小維護應用運行環境的工做量。環境是自動建立的，所以更少的人爲操做是有必要的。
2，在多態服務器上手工搭建相同環境是很容易出錯並且讓人崩潰的。使用Docker的話就能夠很輕鬆地建立一個環境的多個實例，由於咱們最終只須要在服務端運行這個實例鏡像。這種方式也能夠很輕鬆將將來的多個節點添加到集羣中進行水平擴展。
3，輕鬆更新現有的應用和環境。

對比puppet等自動化工具

1，當咱們想要持續交付時，咱們須要爲交付的各個階段建立大量的環境實例（提交階段，驗收階段，容量測試，預生產和生產環境），使用物理機器來達到這個目的時不划算的。
2，安裝應用和必要的基礎設施變得至關簡單，由於咱們老是從一個空的image開始配置的，不容易出錯。

對比虛擬機

1，啓動一個Docker容器遠比啓動一個虛擬機快得多，由於不須要啓動一個操做系統，較少了開銷。
2，幾個容器共享主機操做系統的內核，可是有本身的文件系統、用戶、網絡和進程。從主機操做系統角度來看，當咱們運行Docker容器時，咱們就是在運行另外一個進程。這顯著加速了容器的啓動，同時仍然爲各個容器提供了良好的隔離。
3，跨平臺移植性好

劣勢

1，容器技術自己比較複雜，好比容器管理、編排、應用打包、容器間的網絡、數據快照等技術原理是複雜的。
2，同一個主機上跑的全部容器因爲共用一個操做系統，例如kernel出現bug，則影響全部容器。
3，管理大量的容器比較麻煩，咱們須要依賴kubernetes這種編排工具進行管理。

Docker適用場景

1，快速部署或者擴容
2，多租戶管理
3，整合服務器資源，提升利用率
4，提供開發效率，開發測試部署環境徹底同樣
5，簡化了配置。同一個Docker的配置能夠在不通環境中使用，下降了硬件和應用環境之間的耦合性
6，完美支持CI/CD
7，無縫支持微服務架構

Docker核心技術點

Namespace命名空間

內核命名空間屬於容器技術中的核心，該技術可以將操做系統進行拆分，使一個操做系統看起來像多個互相獨立的操做系統同樣。好比能夠實如今相同的操做系統上運行多個Web服務，同時還不存在端口衝突的問題。該技術還容許多個應用運行在相同操做系統上而且不存在競爭，同時還能共享配置文件以及類庫。

Linux Docker如今利用了下列內核命名空間：

進程ID(PID)

Docker使用PID命名空間爲每一個容器提供互相獨立的容器樹。每一個容器都擁有本身的進程樹，意味着每一個容器都有本身的PID爲1的進程。PID命名空間也意味着容器不能看到其餘容器的進程樹，或者其所在主機的進程樹。

網絡(NET)

Docker使用NET命名空間爲每一個容器提供互相隔離的網絡棧。網絡棧中包括接口、IP地址、端口地址以及路由表。例如：每一個容器都有本身的eth0網絡接口，而且有本身獨立的IP和端口地址。

文件系統/掛載(MNT)

每一個容器都有互相隔離的根目錄/。這意味着每一個容器都有本身的/etc 、/var 、/dev 等目錄。容器內的進程不能訪問Linux主機上的目錄，或者其餘容器的目錄，只能訪問本身 容器的獨立掛載命名空間。

進程內通訊(IPC)

IPC全稱 Inter-Process Communication，是Unix/Linux下進程間通訊的一種方式，IPC有共享內存、信號量、消息隊列等方法。因此，爲了隔離，咱們也須要把IPC給隔離開來，這樣，只有在同一個Namespace下的進程才能相互通訊。Docker使用IPC命名空間在容器內提供共享內存，IPC 提供的共享內存在不一樣容器間也是互相獨立的。

用戶(USER)

Docker容許用戶使用USER命名空間將容器內用戶映射到Linux主機不一樣的用戶上。常見的例子就是將容器內的root用戶映射到Linux主機的非root用戶上。用戶命名空間對於Docker來講還屬於新生事物且非必選項。該部份內容在將來可能出現改變。

UTS

UTS全稱UNIX Time-sharing System，Docker使用UTS命名空間爲每一個容器提供本身的主機名稱。

CGroup

CGroup用於限額。因爲再Docker環境中，容器之間是互相隔離的，單卻共享操做系統資源，能夠經過CGroup限制單個容器的cpu，內存，存儲io等資源的使用量。

Capability

Capability機制是在Linux內核2.2以後引入，它將root用戶的權限細分爲多個，能夠分別啓用或者禁用，例如：

CAP_CHOWN :容許用戶修改文件全部權。 
CAP_NET_BIND_SERVICE :容許用戶將socket綁定到系統端口號。 
CAP_SETUID :容許用戶提高進程優先級。
CAP_SYS_BOOT :容許用戶重啓系統。

Docker採用Capability機制來實現用戶在以root身份運行容器的同 時，還能移除非必須的root能力。

Docker存儲驅動

數據主要分爲兩類:持久化和非持久化數據。持久化數據是須要保 存的，而非持久化數據不須要。默認狀況下，全部容器都有與自身聲明週期相同的非持久化存儲——本地存儲，它很是適用於非持久化數據。 可是，若是容器須要建立長期保存的數據，最好將數據存儲到Docker卷中。

非持久化存儲

非持久化存儲就是容器的本地存儲，每一個容器啓動都會自動分配本地存儲，默認狀況這裏存放了所有文件和文件系統。容器使用鏡像來運行，鏡像包含了要運行的服務和須要的基礎組件，鏡像中的東西也要運行在容器本地存儲中，而Docker鏡像由一些鬆耦合的只讀鏡像層組成，因此本地存儲使用的存儲引擎須要能管理使用這些鏡像層。

Docker經過存儲引擎(新版本採用快照機制)的方式來實現鏡像層，並保證多鏡像層對外展現爲統一的文件系統。Linux上可用的存儲引擎有AUFS 、Overlay2 、Device Mapper 、Btrfs以及ZFS。

持久化存儲

持久化存儲的方式通常使用存儲卷，用戶建立卷，而後建立容器，接着將卷掛載到容器上。卷會掛載到容器文件系統的某個目錄之下，任何寫到該目錄下的內容都會寫到卷中。即便容器被刪除，卷與其上面的數據仍然存在。

目前，Docker支持幾十種卷插件，涵蓋了塊存儲，文件存儲，對象存儲等。

Docker網絡驅動

Docker網絡架構源自一種叫做容器網絡模型(CNM)的方案，該 方案是開源的而且支持插接式鏈接。Libnetwork是Docker對CNM的一種實現，提供了Docker核心網絡架構的所有功能。不一樣的驅動能夠經過插拔的方式接入Libnetwork來提供定製化的網絡拓撲。

爲了實現開箱即用的效果，Docker封裝了一系列本地驅動，覆蓋了 大部分常見的網絡需求。其中包括單機橋接網絡(Single-Host Bridge Network)、多機覆蓋網絡(Multi-Host Overlay)，而且支持接入現有VLAN。Docker生態系統中的合做夥伴經過提供驅動的方式，進一步拓展了Docker的網絡功能。

OCI

Open Container initiative（開放容器倡議）是一個旨在對容器基礎架構中的基礎組件進行標準化的管理委員會。

這個標準是怎麼來的呢？因爲CoreOS的公司不喜歡Docker的某些行事方式。所以它就建立了一個新的開源標準，稱做「appc」，該標準涉及諸如鏡像格式和容器運行時等方面。此外它還開發了一個名爲rkt的實現，這讓容器生態處於分裂的危險中。故在相關方溝通下，共同成立了OCI——一個旨在管理容器標準的輕量級的、敏捷型的委員會。OCI已經發布了兩份規範，而Docker的運行時組件runc就是OCI容器運行時標準的參考實現。標準以下:
1，鏡像規範：定義鏡像的組織結構
the Runtime Specification (runtime-spec)[http://www.github.com/opencontainers/runtime-spec]
2，運行時規範：定義容器能接收的命令和對應的行爲，例如容器的create，start，stop，delete等命令規範。
the Image Specification (image-spec)[http://www.github.com/opencontainers/image-spec]

OCI在Linux基金會的支持下運做，對容器生態規範化產生了極大做用，Docker公司和CoreOS公司都是主要貢獻者。

其它容器技術

Rocket(rkt)

CoreOS的開源的容器運行平臺，推出的目的主要是和Dockr作競爭，目前kubernetes內置了Docker和rtk兩種容器運行時環境。Docker和Rocket目前都遵循OCI標準，Rocket在兼容性（例如rkt還支持AppC標準）和容器安全方面作的更好，其它安全使用便利行和社區活躍度方面Docker遙遙領先。

LXC

LXC (Linux Containters)是一種基於內核容器的用戶空間接口，提供了一系列建立、配置、管理的接口，經過這些接口來簡單管理容器。LXC出現遠早於Docker，通常用於一些容器管理工具的底層實現，社區活躍度比較高。

Kubernetes

Kubernetes是Google的一個開源項目，而且開源以後迅速成爲容器編 排領域的領頭羊，使用Docker做爲默認容器運行時。Kubernetes運行在數據中心硬件基礎設施之上，對外暴露的是一個資源池，它讓咱們部署和運行組件應用的時候不用關注底層，實現了容器或者應用的自動調度，配置，管理和故障處理。

Mesos

Mesos是一個遵循Apache協議的開源項目，是一個集羣管理工具，能夠將整個數據中心的資源（包括CPU、內存、存儲、網絡等）進行抽象和調度，使得多個應用同時運行在集羣中分享資源，並沒有需關心資源的物理分佈狀況。

Mesos是以與Linux內核一樣的原則而建立的，不一樣點僅僅是在於抽象的層面。Mesos內核運行在每個機器上，同時經過 API 爲各類應用提供跨數據中心和雲的資源管理調度能力。這些應用包括Hadoop、Spark、Kafka、Elastic Search，Cassandra等。還可配合框架Marathon來管理大規模的Docker等容器化應用。

主要有以下特性：

• 支持數萬個節點的大規模場景（Apple、Twitter、eBay 等公司實踐）；
• 支持多種應用框架，包括 Marathon、Singularity、Aurora 等；
• 支持 HA（基於 ZooKeeper 實現）；
• 支持 Docker、LXC 等容器；
• 提供了多個流行語言的 API，包括 Python、Java、C++ 等；
• 自帶了簡潔易用的 WebUI，方便用戶直接進行操做。