1.軟件開發(fā)面臨的那些****問題

程序員根據(jù)需求和架構(gòu)設(shè)計翻譯出業(yè)務(wù)邏輯之后，為保證正常轉(zhuǎn)測，打包代碼并編寫轉(zhuǎn)測說明書。

選定合適的服務(wù)器和操作系統(tǒng)，并通過SSH連接服務(wù)器，進行手動升級：安裝Web容器或數(shù)據(jù)庫、部署軟件APP以及配置環(huán)境。開發(fā)內(nèi)部測試，如果發(fā)現(xiàn)新問題需要進行修復，則再次連接服務(wù)器，升級相應的版本和配置環(huán)境的變更點。如未發(fā)現(xiàn)問題，則通過后轉(zhuǎn)交測試人員。

測試重復開發(fā)類似的部署動作，測試通過，版本發(fā)布；運維人員拿到版本發(fā)布包后，重復測試的部署動作。

這種重復的工作就像雙11雜亂的快遞不斷分揀的過程：

如果有集裝箱的話，只要開發(fā)集中裝箱一次，測試、運維就可以直接用了。

2.Docker是什么？

要將安裝好的開發(fā)環(huán)境打成包，能夠切換到測試環(huán)境、生產(chǎn)環(huán)境，實現(xiàn)“一次打包，到處運行”的目標，就需要實現(xiàn)：

（1）將開發(fā)環(huán)境原汁原味地打包。

（2）讓應用程序認為自己擁有“整個天下”。

針對第一個實現(xiàn)目標：將開發(fā)環(huán)境原汁原味地打包。

回顧開發(fā)環(huán)境的安裝過程：先安裝操作系統(tǒng)、再安裝JDK環(huán)境、再裝Web Server、再部署應用程序。整個安裝過程是在操作系統(tǒng)上一層一層安裝起來，到最后整個環(huán)境是各層安裝之后的累加結(jié)果。

《初識Docker鏡像》一文中介紹了Linux操作系統(tǒng)、UnionFS聯(lián)合文件系統(tǒng)，UnionFS可實現(xiàn)將多個文件系統(tǒng)的目錄或者文件合并成一個“統(tǒng)一的文件系統(tǒng)”，掛載到某個目錄（掛載點）下。

針對第二個實現(xiàn)目標：讓應用程序認為自己擁有“整個天下”。

進一步解釋，讓應用程序認為自己擁有獨立的計算、存儲、網(wǎng)絡(luò)。這里需要使用命名空間NameSpace技術(shù)。Linux命名空間是Linux內(nèi)核中實現(xiàn)的虛擬化機制，可以將系統(tǒng)資源劃分成多個獨立的空間，每個空間中的進程邏輯上互相隔離，彼此不影響。

如何讓應用程序認為擁有整個文件系統(tǒng)？使用chroot技術(shù)。chroot 是一種修改當前進程及其子進程的可見根目錄的操作。修改后，進程將不能訪問該根目錄樹以外的任何文件和命令，這種修改后的環(huán)境叫作chroot jail（直譯為chroot監(jiān)獄）。

如何保證應用程序使用有限的資源，從而不擠爆整個宿主機？使用cgroup技術(shù)。

cgroup也是Linux內(nèi)核實現(xiàn)的，可以對進程的CPU 時間、系統(tǒng)內(nèi)存、網(wǎng)絡(luò)帶寬等資源進行分配。

2008年，Linux Container（簡稱LXC），整合了cgroups和Namespace技術(shù)，并合入到Linux內(nèi)核v2.6.27中。

2013年，Docker公司基于Linux Container開發(fā)，并借助于UnionFS，實現(xiàn)了Docker容器技術(shù)。

3.Docker是如何運轉(zhuǎn)的？

有了上面可用的技術(shù)，還需要做一些約定：

（1）將運行環(huán)境所對應的文件系統(tǒng)打成的包，稱為鏡像（Image）；

（2）將應用程序運行起來的進程，稱為容器（Container）；

（3）將存放鏡像的地方，稱為Repository（倉庫）。

有了這些約定，就可以構(gòu)建一個容器的管理程序，用來：

（1）將環(huán)境打包成鏡像；

（2）上傳、下載鏡像到倉庫；

（3）運行容器，容器也可以提交為鏡像；

容器的管理程序采用C/S架構(gòu)，服務(wù)端稱為docker daemon，后端關(guān)聯(lián)倉庫。客戶端是命令行工具。

4. Docker Daemon是如何演進****的?

上文中展示的Docker Daemon服務(wù)端，從Docker v1.11版本開始，便進行拆分重構(gòu)，如圖所示。

包含如下組件：

（1）runc： 負責容器的創(chuàng)建、刪除等生命周期管理。后面詳細介紹。

（2）Containerd-shim： 是一個守護進程，與Containerd一一對應，并向其提供管理容器生命周期的API，也可以向Containerd 報告容器的退出狀態(tài)。向下，在runc運行容器之后并退出，containerd-shim作為容器的父進程。這樣可以重啟Containerd，而不會對運行中的容器產(chǎn)生影響。

（3）Containerd:

containerd是一個守護進程，負責監(jiān)聽傳入的請求以進行容器的生命周期管理（啟動、停止或報告容器的狀態(tài)），同時，也負責鏡像的管理（上傳、下載到倉庫，本地保存鏡像等功能），以及跨容器的網(wǎng)絡(luò)管理。

（4）dockerd： 也就是docker daemon，是一個守護進程。提供docker pull、docker push、docker run等命令接口，并將接口轉(zhuǎn)換為containerd API以調(diào)用containerd。同時，提供容器編排功能。

下面詳細分析runC和containerd兩個組件。

首先來看runC。 Docker的底層技術(shù)是Namespace和Cgroup，LXC組合了這兩種技術(shù)，為運行應用程序提供了“隔離”的環(huán)境，這些都已經(jīng)合入到Linux內(nèi)核。

最初Docker基于LXC進行開發(fā)，因存在強綁定問題，而重新開發(fā)了libcontainer。

后來因Docker成為事實標準，且不開放，影響到生態(tài)建設(shè)（影響了Google、微軟的發(fā)展）。在Linux基金會的參與下，Docker發(fā)起OCI組織，起草了OCI標準：

（1）容器運行時標準（runtime spec）：定義了如何根據(jù)相應的配置構(gòu)建容器運行時，也就是指定了容器的配置、執(zhí)行環(huán)境和生命周期。

（2）容器鏡像標準（image spec）：定義了容器運行時所使用的鏡像打包規(guī)范，也就是指定了文件系統(tǒng)標準包bundle的格式。

總的來說，OCI標準指定了容器運行所需要的bundle和配置信息。

Docker公司根據(jù)OCI容器運行時標準，將libcontainer進行了二次封裝形成新的項目，改為RunC，作為參考實現(xiàn)捐給社區(qū)。需要說明的是RunC項目實現(xiàn)了從定義的容器標準包運行容器，而沒有實現(xiàn)下載鏡像并將解析成標準包。

再來看containerd。

2016年12月，Docker公司將其拆分為獨立組件（守護進程），并于2017年3月捐贈給CNCF。

其架構(gòu)如下圖所示。

containerd分為三個大塊：Storage、Metadata和Runtimes。其中，Storage 負責鏡像的存儲、管理和拉?。籑etadata用來管理容器及鏡像的元數(shù)據(jù)，Runtimes用來對接runc。

containerd捐給社區(qū)后，形成一個龐大的生態(tài)：

參考資料

1. 容器運行時規(guī)范：https://github.com/opencontainers/runtime-spec2. 容器鏡像規(guī)范：https://github.com/opencontainers/image-spec3. https://containerd.io/4.https://github.com/containerd/containerd/blob/main/docs/getting-started.md5.https://mp.weixin.qq.com/s/yIuGm92sshYOZAcIpmu9Ag6.https://www.zhangjiee.com/blog/2021/container-runtime.html