1.軟件開發面臨的那些****問題

程序員根據需求和架構設計翻譯出業務邏輯之后，為保證正常轉測，打包代碼并編寫轉測說明書。

選定合適的服務器和操作系統，并通過SSH連接服務器，進行手動升級：安裝Web容器或數據庫、部署軟件APP以及配置環境。開發內部測試，如果發現新問題需要進行修復，則再次連接服務器，升級相應的版本和配置環境的變更點。如未發現問題，則通過后轉交測試人員。

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

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

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

2.Docker是什么？

要將安裝好的開發環境打成包，能夠切換到測試環境、生產環境，實現“一次打包，到處運行”的目標，就需要實現：

（1）將開發環境原汁原味地打包。

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

針對第一個實現目標：將開發環境原汁原味地打包。

回顧開發環境的安裝過程：先安裝操作系統、再安裝JDK環境、再裝Web Server、再部署應用程序。整個安裝過程是在操作系統上一層一層安裝起來，到最后整個環境是各層安裝之后的累加結果。

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

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

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

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

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

cgroup也是Linux內核實現的，可以對進程的CPU 時間、系統內存、網絡帶寬等資源進行分配。

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

2013年，Docker公司基于Linux Container開發，并借助于UnionFS，實現了Docker容器技術。

3.Docker是如何運轉的？

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

（1）將運行環境所對應的文件系統打成的包，稱為鏡像（Image）；

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

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

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

（1）將環境打包成鏡像；

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

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

容器的管理程序采用C/S架構，服務端稱為docker daemon，后端關聯倉庫。客戶端是命令行工具。

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

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

包含如下組件：

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

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

（3）Containerd:

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

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

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

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

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

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

（1）容器運行時標準（runtime spec）：定義了如何根據相應的配置構建容器運行時，也就是指定了容器的配置、執行環境和生命周期。

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

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

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

再來看containerd。

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

其架構如下圖所示。

containerd分為三個大塊：Storage、Metadata和Runtimes。其中，Storage 負責鏡像的存儲、管理和拉取；Metadata用來管理容器及鏡像的元數據，Runtimes用來對接runc。

containerd捐給社區后，形成一個龐大的生態：

參考資料

1. 容器運行時規范：https://github.com/opencontainers/runtime-spec2. 容器鏡像規范：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