容器簡(jiǎn)史：從1979到現(xiàn)在

傅一平

隨著云計(jì)算的發(fā)展，容器的使用越來越廣泛，尤其是近兩年，越來越多企業(yè)機(jī)構(gòu)都開始采用容器作為新的IT基礎(chǔ)設(shè)施?；仡櫼幌職v史，其實(shí)容器在上世紀(jì)的70年代就已經(jīng)出現(xiàn)了雛形。Jails，Zones，VPS，VM和容器都是為了隔離和資源控制，但每種技術(shù)是通過不同的方式實(shí)現(xiàn)，每種方式都有其局限性和優(yōu)勢(shì)。

1979年：Unix V7

在那個(gè)計(jì)算資源匱乏年代，想要通過快速銷毀和重建基礎(chǔ)設(shè)施來解決測(cè)試環(huán)境污染問題幾乎不可能。為了隔離出來可供軟件進(jìn)行構(gòu)建和測(cè)試的環(huán)境，chroot（change root）系統(tǒng)調(diào)用程序橫空出現(xiàn)。

在1979年Unix V7的開發(fā)過程中，正式引入了chroot系統(tǒng)調(diào)用，為每個(gè)進(jìn)程提供一個(gè)獨(dú)立的磁盤空間，將一個(gè)進(jìn)程及其子進(jìn)程的根目錄改變到文件系統(tǒng)中的新位置，讓這些進(jìn)程只能訪問到該目錄。這個(gè)被隔離出來的新環(huán)境被叫做Chroot Jail。這標(biāo)志著進(jìn)程隔離的開始，隔離每個(gè)進(jìn)程的文件訪問權(quán)限。

2000年：FreeBSD Jails

在2000年，F(xiàn)reeBSD操作系統(tǒng)正式發(fā)布FreeBSD Jails隔離環(huán)境，真正意義上實(shí)現(xiàn)了進(jìn)程的沙箱化。這為文件系統(tǒng)、用戶、網(wǎng)絡(luò)等隔離增加了進(jìn)程沙盒功能，實(shí)現(xiàn)了客戶服務(wù)之間的隔離和管理。

這種沙箱的實(shí)現(xiàn)，依靠的是操作系統(tǒng)級(jí)別的隔離與限制能力而非硬件虛擬化技術(shù)。FreeBSD Jails允許管理員將FreeBSD計(jì)算機(jī)系統(tǒng)劃分為幾個(gè)獨(dú)立的、較小的系統(tǒng)，稱為“Jails”，并能夠?yàn)槊總€(gè)系統(tǒng)和配置分配IP地址，可以對(duì)軟件的安裝和配置進(jìn)行定制。

2001年：Linux VServer

與FreeBSD Jails一樣，Linux VServer也是一種類似上述Jails機(jī)制，可以對(duì)計(jì)算機(jī)系統(tǒng)上的資源（文件系統(tǒng)，網(wǎng)絡(luò)地址，內(nèi)存）進(jìn)行分區(qū)。每個(gè)所劃分的分區(qū)叫做一個(gè)安全上下文（security context），在其中的虛擬系統(tǒng)叫做虛擬私有服務(wù)器（virtualprivate server，VPS）。該操作系統(tǒng)虛擬化于2001年推出，通過修補(bǔ)Linux內(nèi)核來實(shí)現(xiàn)，測(cè)試性補(bǔ)丁目前仍然可用，但最后一個(gè)穩(wěn)定的修補(bǔ)程序于2006年發(fā)布。

2004年：Solaris容器

2004年2月，Oracle發(fā)布了Oracle Solaris Containers，這是一個(gè)用于X86和SPARC處理器的Linux-Vserver版本。Solaris Container是由系統(tǒng)資源控制和通過zones提供的邊界分離（boundary separation）組合而成的。zones是一個(gè)單一操作系統(tǒng)實(shí)例中的完全隔離的虛擬服務(wù)器。

2005年：Open VZ（Open Virtuzzo）

這是Linux操作系統(tǒng)級(jí)虛擬化技術(shù)，它通過Linux內(nèi)核補(bǔ)丁形式進(jìn)行虛擬化、隔離、資源管理和狀態(tài)檢查。操作系統(tǒng)級(jí)虛擬化有一些限制，因?yàn)槿萜鞴蚕硐嗤捏w系結(jié)構(gòu)和內(nèi)核版本，當(dāng)客戶需要不同于主機(jī)內(nèi)核版本的情況下，這種缺點(diǎn)就會(huì)顯現(xiàn)出來。該代碼未作為正式Linux內(nèi)核的一部分發(fā)布。每個(gè)OpenVZ容器都有一套隔離的文件系統(tǒng)、用戶及用戶組、進(jìn)程樹、網(wǎng)絡(luò)、設(shè)備和IPC對(duì)象。

2006年：Process Containers

Process Containers由Google在2006年推出，旨在用于限制，計(jì)算和隔離一系列流程的資源使用（CPU、內(nèi)存、磁盤I/O、網(wǎng)絡(luò)）。一年后，為了避免和Linux內(nèi)核上下文中的“容器”一詞混淆而改名為Control Groups簡(jiǎn)稱Cgroups，并最終合并到Linux內(nèi)核2.6.24中。這也可以說明Google很早就參與了容器技術(shù)的開發(fā)。

2008年：LXC

Linux容器（LXC）是第一個(gè)、最完整的Linux容器管理器的實(shí)現(xiàn)方案。2008年時(shí)候，通過將Cgroups的資源管理能力和Linux Namespace的視圖隔離能力組合在一起，LXC完整的容器技術(shù)出現(xiàn)在了Linux內(nèi)核當(dāng)中，并且可以在單個(gè)Linux內(nèi)核上運(yùn)行而無需任何補(bǔ)丁。LXC存在于liblxc庫(kù)中，提供了各種編程語言的API實(shí)現(xiàn)，包括Python3，Python2，Lua，Go，Ruby，Haskell?，F(xiàn)在LXC project是由Canonical公司贊助并托管的。

2011年：Warden

Warden是由Cloud Foundry在2011年成立，這是一個(gè)管理隔離，短暫存在和被資源控制的環(huán)境的API。在其第一個(gè)版本中，Warden使用了LXC，之后替換為他們自己的實(shí)現(xiàn)方案。不像LXC，Warden并不緊密耦合到Linux上，可以為任何系統(tǒng)提供隔離運(yùn)行環(huán)境。Warden以后臺(tái)保護(hù)程序運(yùn)行，而且能夠提供用于容器管理的API。它開發(fā)了一個(gè)CS（客戶端-服務(wù)端）模型來管理跨多個(gè)主機(jī)的容器集群，并且Warden提供用于管理cgroup，名稱空間和進(jìn)程生命周期的相關(guān)服務(wù)。

2013年：LMCTFY

LMCTFY是2013年Google容器技術(shù)開源版本的開始，提供Linux應(yīng)用程序容器，旨在提供性能可保證的、高資源利用率的、資源共享的、可超售的和接近零消耗的容器。

在2015年，Google開始向由Docker發(fā)起的Libcontainer貢獻(xiàn)LMCTFY核心概念之后，LMCTFY在2015年主動(dòng)停止部署，Libcontainer現(xiàn)在是Open Container Foundation（開放容器基金會(huì)）的一部分。

2013年：Docker

隨著2013年Docker的出現(xiàn)，容器開始迅速普及。它最初是一個(gè)叫做dotCloud的PaaS服務(wù)公司的內(nèi)部項(xiàng)目，后來該公司改名為Docker。Docker的增長(zhǎng)并非偶然，它引入了一整套管理容器的生態(tài)系統(tǒng)，包括高效、分層的容器鏡像模型、全局和本地的容器注冊(cè)庫(kù)、清晰的REST API和命令行等。

跟Warden一樣，Docker開始階段使用的也是LXC，后來用自己的庫(kù)進(jìn)行替換。Docker推動(dòng)實(shí)現(xiàn)了一個(gè)叫做Docker Swarm的容器集群管理方案。

2014年：Rocket

Rocket是由CoreOS所啟動(dòng)的項(xiàng)目，非常類似于Docker，但是修復(fù)了一些Docker中發(fā)現(xiàn)的問題。CoreOS初衷是提供一個(gè)比Docker更嚴(yán)格的安全性和產(chǎn)品需求。更重要的是，它是在一個(gè)更加開放的標(biāo)準(zhǔn)AppContainer規(guī)范上實(shí)現(xiàn)的。在Rocket之外，CoreOS也開發(fā)了其他幾個(gè)可以用于Docker和Kubernetes的容器相關(guān)產(chǎn)品，如：CoreOS操作系統(tǒng)、etcd和flannel。

2016年：Windows Containers

2015年，微軟在Windows Server上為基于Windows的應(yīng)用添加了容器支持，稱之為WindowsContainers。它與Windows Server 2016一同發(fā)布，Docker可以原生地在Windows上運(yùn)行Docker容器，而不需要啟動(dòng)虛擬機(jī)來運(yùn)行Docker（Windows上早期運(yùn)行Docker需要使用Linux虛擬機(jī)）。

2017年：容器工具日趨成熟

在2017年以前，市場(chǎng)上已經(jīng)有上百種工具用來管理容器，這些類型的工具已經(jīng)存在多年了，但2017年是其中許多工具脫穎而出的一年。例如Kubernetes，自2016年被納入Cloud Native Computing Foundation以來，VMWare，Azure，AWS甚至Docker都宣布在其基礎(chǔ)架構(gòu)之上提供相關(guān)支持。

隨著容器市場(chǎng)的發(fā)展和增長(zhǎng)，一些工具已經(jīng)開始定義容器的某些功能。Ceph和REX-Ray為容器存儲(chǔ)設(shè)定了標(biāo)準(zhǔn)，在CI/CD中，Jenkins完全改變了構(gòu)建和部署應(yīng)用程序的方式。

2017年，CoreOS和Docker聯(lián)合提議將rkt和containerd作為新項(xiàng)目納入CNCF，這標(biāo)志容器生態(tài)系統(tǒng)初步形成，容器項(xiàng)目之間協(xié)作更加豐富。

從Docker最初宣布將剝離其核心運(yùn)行時(shí)到2017年捐贈(zèng)給CNCF協(xié)會(huì)，“containerd”項(xiàng)目在過去2年經(jīng)歷了顯著的增長(zhǎng)和進(jìn)步。Docker捐贈(zèng)的主要目的是通過提供一個(gè)核心容器運(yùn)行時(shí)來促進(jìn)容器生態(tài)系統(tǒng)的進(jìn)一步創(chuàng)新，容器系統(tǒng)供應(yīng)商和編排項(xiàng)目（如Kubernetes、Swarm等）可以利用這個(gè)核心容器運(yùn)行時(shí)。containerd的一個(gè)重要設(shè)計(jì)原則是可以對(duì)Kubernetes提供一流的支持，但又不完全依賴于Kubernetes，這也為許多容器的用例如developer desktop、CI/CD、單節(jié)點(diǎn)部署、edge和物聯(lián)網(wǎng)打開了新的大門。

2018年：越來越規(guī)范

容器化成為現(xiàn)代軟件基礎(chǔ)架構(gòu)的基礎(chǔ)，而Kubernetes被用于大多數(shù)企業(yè)容器項(xiàng)目。2018年GitHub上的Kubernetes項(xiàng)目有1 500多個(gè)貢獻(xiàn)者，是最重要的開源社區(qū)之一。

Kubernetes的廣泛采用推動(dòng)了諸如AWS云供應(yīng)商提供托管的Kubernetes服務(wù)。此外，VMWare，RedHat，Rancher等領(lǐng)先的軟件供應(yīng)商也開始提供基于Kubernetes的管理平臺(tái)。

2019年：歷史變革

2019年是容器發(fā)生歷史性變革的一年，在這一年發(fā)生了很多歷史性變革事件，包括容器生態(tài)變化、產(chǎn)業(yè)資本并購(gòu)和新技術(shù)解決方案出現(xiàn)等。

在這一年新的運(yùn)行時(shí)引擎開始替代Docker運(yùn)行引擎，其最具代表性新引擎就是CNCF的Containerd和CRI-O（一個(gè)用于Kubernetes的輕量級(jí)運(yùn)行時(shí)）。CRI-O可以讓用戶直接從Kubernetes運(yùn)行容器，而不需要任何不必要的代碼或工具。只要容器符合OCI標(biāo)準(zhǔn)，CRI-O就可以運(yùn)行它。

2019年，產(chǎn)業(yè)方面也發(fā)送了巨大變化，Docker Enterprise賣給了Mirantis（一家專注于OpenStack、Kubernetes的云計(jì)算公司），可以預(yù)見的是Docker Swarm將逐步被淘汰。同時(shí)，也可以看到雖然Rkt已經(jīng)正式成為CNCF一部分但是其普及率正在逐步下降。此外，VMware收購(gòu)了Heptio，Pivotal Software（包括PAS和PKS），此舉可以更好幫助企業(yè)客戶建立并運(yùn)行基于Kubernetes的容器化架構(gòu)。其中Heptio公司是由兩位曾在2014年幫助谷歌聯(lián)合建立Kubernetes項(xiàng)目的主力（當(dāng)時(shí)的項(xiàng)目負(fù)責(zé)人共有3名）共同建立，創(chuàng)始人及其團(tuán)隊(duì)都將一同加盟VMware公司。如此清晰的創(chuàng)始人背景，可能意味著VMware有意在Kubernetes領(lǐng)域發(fā)動(dòng)全面沖擊，甚至預(yù)示VMware已經(jīng)把Kubernetes視為企業(yè)業(yè)務(wù)運(yùn)營(yíng)的根本性基石之一。

2019年容器技術(shù)領(lǐng)域也出現(xiàn)了新的變革，函數(shù)即服務(wù)（函數(shù)或者無服務(wù)器）已經(jīng)成為一種新的抽象趨勢(shì)。其允許開發(fā)人員更輕松地運(yùn)行并部署代碼片段，且這些代碼片段將能夠快速實(shí)現(xiàn)規(guī)模伸縮以響應(yīng)事件需求。例如，企業(yè)只要使用由Google與Pivotal、IBM、紅帽和SAP等企業(yè)共同開發(fā)的跨云Serverless管理平臺(tái)Knative，就能在支持Kubernetes的云平臺(tái)上自由的遷移工作負(fù)載，無論是跨私有云或是公有云及各種混合云架構(gòu)都沒問題。

2019也出現(xiàn)了基于Kubernetes-混合云解決方案，如IBM CloudPaks，Anthos，AWS Outposts，Azure Arc。這些云平臺(tái)模糊了云環(huán)境與本地環(huán)境之間的傳統(tǒng)界限，可以更方便管理本地和供應(yīng)商云服務(wù)。

Kubernetes現(xiàn)在已經(jīng)成為了構(gòu)建容器化平臺(tái)體系的默認(rèn)抽象方案，上述這些新功能的出現(xiàn)也代表著Kubernetes下一步演進(jìn)方向，諸如Anthos，Arc和Outposts之類超抽象。在超抽象中，計(jì)算資源從管理層解耦，類似于Kubernetes的工作方式，它將工作負(fù)載從管理層解耦。

2020年：容器安全亟待解決

容器作為一種輕量級(jí)的虛擬化技術(shù)，使用方便、操作便捷，大大提高了開發(fā)人員的工作效率，得到了業(yè)內(nèi)的廣泛使用。但與此同時(shí)，容器安全事故頻發(fā)，包括不安全的鏡像源、容器入侵事件、運(yùn)行環(huán)境的安全問題等。

不安全的鏡像源，開發(fā)者通常會(huì)在Docker官方的Docker Hub倉(cāng)庫(kù)下載鏡像，這些鏡像一部分來源于開發(fā)鏡像內(nèi)相應(yīng)軟件的官方組織，還有大量鏡像來自第三方組織甚至個(gè)人。在從這些鏡像倉(cāng)庫(kù)中獲取鏡像的同時(shí)，也帶來了潛在的安全風(fēng)險(xiǎn)。例如，下載鏡像內(nèi)軟件本身是否包含漏洞，下載的鏡像是否被惡意的植入后門，鏡像在傳輸過程中是否被篡改。

容器入侵事件，可能是由Docker本身的架構(gòu)與機(jī)制產(chǎn)生的問題，這一攻擊場(chǎng)景主要產(chǎn)生在黑客已經(jīng)控制了宿主機(jī)上的一些容器（或者通過在公有云上建立容器的方式獲得這個(gè)條件），然后對(duì)宿主機(jī)或其他容器發(fā)起攻擊來產(chǎn)生影響。

運(yùn)行環(huán)境的安全除Docker本身存在的問題以外，Docker的運(yùn)行環(huán)境存在的問題，同樣會(huì)給Docker的使用帶來風(fēng)險(xiǎn)。

由于容器是介于基礎(chǔ)設(shè)施和平臺(tái)之間的虛擬化技術(shù)，因此面向基礎(chǔ)設(shè)施虛擬化的傳統(tǒng)云安全解決方案無法完全解決前述安全問題。如以容器為支撐技術(shù)構(gòu)建DevOps環(huán)境，就需要設(shè)計(jì)涵蓋從容器鏡像的創(chuàng)建到投產(chǎn)上線的整個(gè)生命周期的容器安全方案。

目前，市場(chǎng)上涌現(xiàn)了一批容器安全產(chǎn)品安全廠商，如Neuvector，Twistlock，StackRox，Aqua等，國(guó)內(nèi)自研容器安全產(chǎn)品有青藤云安全。從容器安全產(chǎn)品的技術(shù)方案上來看，目前大部分的容器安全廠商均使用了平行容器的方式對(duì)宿主機(jī)上的容器進(jìn)行安全防護(hù)，而青藤云安全則采取了基于宿主機(jī)Agent的方式。

平行容器技術(shù)方案：利用容器的隔離性和良好的資源控制能力，在容器的宿主機(jī)中啟動(dòng)一個(gè)容器，該容器通過掛載宿主機(jī)的所有文件系統(tǒng)，而后在容器內(nèi)部對(duì)這些文件系統(tǒng)進(jìn)行實(shí)時(shí)監(jiān)控和處理響應(yīng)，以實(shí)現(xiàn)對(duì)容器進(jìn)行防護(hù)的作用。

基于宿主機(jī)Agent的技術(shù)方案：即基于青藤Agent的主機(jī)防護(hù)能力，監(jiān)控宿主機(jī)上容器相關(guān)的文件、進(jìn)程、系統(tǒng)調(diào)用等等信息，增加其Agent中對(duì)于容器的清點(diǎn)、監(jiān)控、防護(hù)能力，以便通過一個(gè)Agent即可實(shí)現(xiàn)宿主機(jī)安全和容器安全2種防護(hù)的效果。