關于容器的歷史、發展以及技術本質，在互聯網上已經有非常多的文章了。這里旨在結合自身的工作經驗和理解，通過一系列的文章，講清楚這項技術。

容器的歷史和發展

前世

講到容器，就不得不提LXC(Linux Container)，他是Docker的前生，或者說Docker是LXC的使用者。完整的LXC能力在2008年合入Linux主線，所以容器的概念在2008年就基本定型了，并不是后面Docker造出來的。關于LXC的介紹很多，大體都會說“LXC是Linux內核提供的容器技術，能提供輕量級的虛擬化能力，能隔離進程和資源”，但總結起來，無外乎就兩大知識點Cgroups(Linux Control Group)和Linux Namespace。搞清楚他倆，容器技術就基本掌握了。

• Cgroups：重點在“限制”。限制資源的使用，包括CPU、內存、磁盤的使用，體現出對資源的管理能力。
• Namespace：重點在“隔離”。隔離進程看到的Linux視圖。說大白話就是，容器和容器之間不要相互影響，容器和宿主機之間不要相互影響。

少年期起步艱難

2009年，Cloud Foundry基于LXC實現了對容器的操作，該項目取名為Warden。2010年，dotCloud公司同樣基于LXC技術，使用Go語言實現了一款容器引擎，也就是現在的Docker。那時，dotCloud公司還是個小公司，出生卑微的Docker沒什么熱度，活得相當艱難。

成長為巨無霸

2013年，dotCloud公司決定將Docker開源。開源后，項目突然就火了。從大的說，火的原因就是Docker的這句口號“Build once，Run AnyWhere”。呵呵，是不是似曾相識?對的，和Java的Write Once，Run AnyWhere一個道理。對于一個程序員來說，程序寫完后打包成鏡像就可以隨處部署和運行，開發、測試和生產環境完全一致，這是多么大一個誘惑。程序員再也不用去定位因環境差異導致的各種坑爹問題。

Docker開源項目的異常火爆，直接驅動dotCloud公司在2013年更名為Docker公司。Docker也快速成長，干掉了CoreOS公司的rkt容器和Google的lmctfy容器，直接變成了容器的事實標準。也就有了后來人一提到容器就認為是Docker。

總結起來，Docker為什么火，靠的就是Docker鏡像。他打包了應用程序的所有依賴，徹底解決了環境的一致性問題，重新定義了軟件的交付方式，提高了生產效率。

被列強蠶食

Docker在容器領域快速成長，野心自然也變大了。2014年推出了容器云產品Swarm(Kubenetes的同類產品)，想擴張事業版圖。同時Docker在開源社區擁有絕對話語權，相當強勢。這種走自己的路，讓別人無路可走的行為，讓容器領域的其他大廠玩家很是不爽，為了不讓Docker一家獨大，決定要干他。

2015年6月，在Google、Redhat等大廠的“運作”下，Linux基金會成立了OCI(Open Container Initiative)組織，旨在圍繞容器格式和運行時制定一個開放的工業化標準，也就是我們常說的OCI標準。同時，Docker公司將Libcontainer模塊捐給CNCF社區，作為OCI標準的實現，這就是現在的RunC項目。說白了，就是現在這塊兒有個標準了，大家一起玩兒，不被某個特定項目的綁定。

講到Docker，就得說說Google家的Kubernetes，他作為容器云平臺的事實標準，如今已被廣泛使用，儼然已成為大廠標配。Kubernetes原生支持Docker，讓Docker的市場占有率一直居高不下。如圖是2019年容器運行時的市場占有率。

但在2020年，Kubernetes突然宣布在1.20版本以后，也就是2021年以后，不再支持Docker作為默認的容器運行時，將在代碼主干中去除dockershim。

如圖所示，Kubenetes自身定義了標準的容器運行時接口CRI(Container Runtime Interface)，目的是能對接任何實現了CRI接口的容器運行時。在初期，Docker是容器運行時不容置疑的王者，Kubenetes便內置了對Docker的支持，通過dockershim來實現標準CRI接口到Docker接口的適配，以此獲得更多的用戶。隨著開源的容器運行時Containerd(實現了CRI接口，同樣由Docker捐給CNCF)的成熟，Kubenetes不再維護dockershim，僅負責維護標準的CRI，解除與某特定容器運行時的綁定。當然，也不是Kubenetes不支持Docker了，只是dockershim誰維護的問題。 隨著Kubenetes態度的變化，預計將會有越來越多的開發者選擇直接與開源的Containerd對接，Docker公司和Docker開源項目(現已改名為Moby)未來將會發生什么樣的變化，誰也說不好。

講到這里，不知道大家有沒有注意到，Docker公司其實是捐獻了Containerd和runC。這倆到底是啥東西。簡單的說，runC是OCI標準的實現，也叫OCI運行時，是真正負責操作容器的。Containerd對外提供接口，管理、控制著runC。所以上面的圖，真正應該長這樣。

Docker公司是一個典型的小公司因一個爆款項目火起來的案例，不管是技術層面、公司經營層面以及如何跟大廠纏斗，不管是好的方面還是壞的方面，都值得我們去學習和了解其背后的故事。

什么是容器

按國際慣例，在介紹一個新概念的時候，都得從大家熟悉的東西說起。幸好容器這個概念還算好理解，喝水的杯子，洗腳的桶，養魚的缸都是容器。容器技術里面的“容器”也是類似概念，只是裝的東西不同罷了，他裝的是應用軟件本身以及軟件運行起來需要的依賴。用魚缸來類比，魚缸這個容器里面裝的應用軟件就是魚，裝的依賴就是魚食和水。這樣大家就能理解Docker的Logo了。大海就是宿主機，Docker就是那條鯨魚，鯨魚背上的集裝箱就是容器，我們的應用程序就裝在集裝箱里面。

在講容器的時候一定繞不開容器鏡像，這里先簡單的把容器鏡像理解為是一個壓縮包，后續再詳細講解。壓縮包里包含應用的可執行程序以及程序依賴的文件(例如：配置文件和需要調用的動態庫等)，接下來通過實際操作來看看容器到底是個啥。

宿主機視角看容器

1、首先，我們啟動容器。

docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done" 

這是Docker的標準命令。意思是使用euleros_arm:2.0SP8SPC306鏡像(鏡像名:版本號)創建一個新的名字為“aimar-1-container”的容器，并在容器中執行shell命令：每秒打印一次“aimar-1-container”。

參數說明：

• -d：使用后臺運行模式啟動容器，并返回容器ID。
• --name：為容器指定一個名字。

 

docker run -d --name="aimar-1-container" euleros_arm:2.0SP8SPC306 /bin/sh -c "while true; do echo aimar-1-container; sleep 1; done"  
207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c 

從輸出中，我們看到一串長字符207b7c0cbd811791f7006cd56e17033eb430ec656f05b6cd172c77cf45ad093c。他就是容器ID，能唯一標識一個容器。當然在使用的時候，不需要使用全id，直接使用縮寫id即可(全id的前幾位)。例如下圖中，通過docker ps查詢到的容器id為207b7c0cbd81。

aimar-1-container容器啟動成功后，我們在宿主機上使用ps進行查看。這時可以發現剛才啟動的容器就是個進程，PID為12280。

我們嘗試著再啟動2個容器，并再次在宿主機進行查看，你會發現又新增了2個進程，PID分別為20049和21097。

所以，我們可以得到一個結論。從宿主機的視角看，容器就是進程。

2、接下來，我們進入這個容器。

docker exec -it 207b7c0cbd81 /bin/bash 

docker exec也是Docker的標準命令，用于進入某個容器。意思是進入容器id為207b7c0cbd81的容器，進入后執行/bin/bash命令，開啟命令交互。

參數說明：

• -it其實是-i和-t兩個參數，意思是容器啟動后，要分配一個輸入/輸出終端，方便我們跟容器進行交互，實現跟容器的“對話”能力。

從hostname從kwephispra09909變化為207b7c0cbd81，說明我們已經進入到容器里面了。在容器中，我們嘗試著啟動一個新的進程。

[root@207b7c0cbd81 /]# /bin/sh -c "while true; do echo aimar-1-container-embed; sleep 1; done" & 

 

再次回到宿主機進行ps查看，你會發現不管是直接啟動容器，還是在容器中啟動新的進程，從宿主機的角度看，他們都是進程。

容器視角看容器

前面我們已經進入容器里面，并啟動了新的進程。但是我們并沒有在容器里查看進程的情況。在容器中執行ps，會發現得到的結果和宿主機上執行ps的結果完全不一樣。下圖是容器中的執行結果。

在Container1容器中只能看見剛起啟動的shell進程(container1和container1-embed)，看不到宿主機上的其他進程，也看不到Container2和Container3里面的進程。這些進程像被關進了一個盒子里面，完全感知不到外界，甚至認為我們執行的container1是1號進程(1號進程也叫init進程，是系統中所有其他用戶進程的祖先進程)。所以，從容器的視角，容器覺得“我就是天，我就是地，歡迎來到我的世界”。

但尷尬的是，在宿主機上，他們卻是普通得不能再普通的進程。注意，相同的進程，在容器里看到的進程ID和在宿主機上看到的進程ID是不一樣的。容器中的進程ID分別是1和1859，宿主機上對應的進程ID分別是12280和9775(見上圖)。

總結

通過上面的實驗，對容器的定義就需要再加上一個定語。容器就是進程=>容器是與系統其他部分隔離開的進程。這個時候我們再看下圖就更容易理解，容器是跑在宿主機OS(虛機容器的宿主機OS就是Guest OS)上的進程，容器間以及容器和宿主機間存在隔離性，例如：進程號的隔離。

在容器內和宿主機上，同一個進程的進程ID不同。例如：Container1在容器內PID是1，在宿主機上是12280。那么該進程真正的PID是什么呢?當然是12280!那為什么會造成在容器內看到的PID是1呢，造成這種幻象的，正是Linux Namespace。

Linux Namespace是Linux內核用來隔離資源的方式。每個Namespace下的資源對于其他Namespace都是不透明，不可見的。

Namespace按隔離的資源進行分類：

前面提到的容器內外，看到的進程ID不同，正是使用了PID Namespace。那么這個Namespace在哪呢?在Linux上一切皆文件。是的，這個Namespace就在文件里。在宿主機上的proc文件中(/proc/進程號/ns)變記錄了某個進程對應的Namespace信息。如下圖，其中的數字(例如：pid:[ 4026534312])則表示一個Namespace。

對于Container1、Container2、Container3這3個容器，我們可以看到，他們的PID Namespace是不一樣的。說明他們3個容器中的PID相互隔離，也就是說，這3個容器里面可以同時擁有PID號相同的進程，例如：都有PID=1的進程。

在一個命名空間中，那這倆進程就相互可見，只是PID與宿主機上看到的不同而已。

 

至此，我們可以對容器的定義再細化一層。容器是與系統其他部分隔離開的進程=》容器是使用Linux Namespace實現與系統其他部分隔離開的進程。