前言

前幾個小節中，我們在學習dubbo的時候，註冊中心zookeeper是用docker來構建的，並且我們使用docker compose的命令來一鍵搭建dubbo admin UI的管理頁面，後來的nacos的管理控制檯，也是使用docker來搭建，我們已經在無形中，享受了docker給我們提供的種種方便，我們在前幾個課程中，深深地體會了docker給我們帶來的各種便利，所以我們也會一起去深入容器的學習，方便我們更加快速地了解容器這門技術，擴大我們開發人員的知識面和技能圖譜，並且了解docker，知道CICD,完全理解其中的原理，也能夠幫助我們以更加寬廣的視角去進行更好地工作開發，本小節，一起學些一下Docker Engine的基本體系架構

本小節類似快餐小說，手機端和PC端都可以觀看，沒有大段程式碼，旨在幫助大家花費5分鐘的時間，讓大家對docker架構有一個基本的印象

docker整體結構

我們用平時最常用的【docker version】命令來檢視，可以看到如下的截圖，顯示了client端和server端

client端和server端這種C/S模型，對於我們大部分開發過web開發的人來說並不陌生，客戶端發起一個http請求，到伺服器端，伺服器端API層接收到該請求，然後解析請求的引數，然後交送給服務層，服務層做邏輯處理，最後資料層互動，返回結果

如果你是一個java spring mvc的開發者，你肯定會特別清楚，我們90%的java web開發程式日常最多的活就是CRUD,先寫一個API控制層的controller程式碼，然後業務邏輯處理層的程式碼Service，最後就是資料層，做一些資料的處理，最後返回結果，這是我們最常用的套路

可能docker公司的大牛也是受這套比較經典的業務邏輯的印象，docker的服務端,docker服務端也叫docker engine，服務端的整體架構也是如此，都是"外掛式","可插拔"的元件來一起構建成我們docker engine的

docker Engine的整體架構圖

docker engine 整體架構圖

簡要說明

翻看docker的歷史，發現跟spring發展的歷史和結果驚人的相似，一來是也是大而全，完完整整的一套，所有的元件糅合的在一起，相互耦合，導致docker的可擴充套件性特別差，讓其他的公司想要入手開源，貢獻自己的一份力量變得極其難以上手，後來docker才會有了spring的那種微核心，外掛式，可插拔的特性，Docker engine變得由Docker Daemon，containerd，runc，shim這幾大元件組成的一個優秀的容器引擎Docker Daemon——與spring mvc一樣，負責和客戶端進行API互動，主要負責和客戶端的互動，還有一些Docker Engine的配置，然後把客戶端的請求發給containerd進行處理containerd——spring mvc + spring + mybatis經典開發中的service層一樣，它是真正的邏輯處理中心，負責真正容器的生命週期，負責容器的建立，停止，刪除，相當於管控著容器的整個生命週期，並且映象的一些操作也是由containerd來進行負責，containerd還有一個鼎鼎大名的名稱叫做"容器執行時",聽起來就很炫酷，不過實至名歸啊，又當媽有當爹的，取一個炫酷的名字，不過分runc——真正建立執行容器的工具，與web開發中的mybatis比較像，mybatis一個是真正去操作資料庫的處理層，runc是真正與作業系統互動，建立指令，讓作業系統去執行這些指令，來建立容器的處理層shim——其實它就像一個哨兵，不停地監控著容器的狀態，因為runc這是一個工具類，它很爛，它建立完容器之後，就去"睡覺"了，所以需要一個shim哨兵物件來管控，報告狀態給containerd，最後反饋給Docker Daemon,返回給客戶端Docker Daemon

Docker Daemon目前是最輕量的一層，主要負責與客戶端的互動，它的主要職責就是標準API,客戶端身份認證，網路，映象構建管理等操作

Containerd

Containerd就是Docker的大腦，有承上啟下的作用，負責接收Docker daemon的命令，映象的解析，將映象轉換成OCI bundle，最後通知工人runc去拿著containerd生成的清單，去建立對應的容器

runc

runc其實是一個單獨的專案，原始碼地址在github上有所開源，地址【https://github.com/opencontainers/runc】，它是一個可以單獨執行的工具類，可以單獨變成工具行來執行

runc is a CLI tool for spawning and running containers according to the OCI specification.

簡而言之runc是一個客戶端工具，它是根據OCI規範來引導和建立容器，什麼是OCI規範呢，全程就是"open container initiative"，翻譯成大白話就是"開放容器規範"

作為普通人的我們可以這麼理解，容器技術呢，其實並不是非常難，所以想進入這個市場，分這個蛋糕的公司就特別多，docker公司比較早，但起初它的程式碼並不是特別優秀，但是它的市場份額已經很大了，很多使用者就只認docker，其他廠商就不幹了，蛋糕不能你一個人吃啊，你程式碼又爛，程式碼又沒有分層，這怎麼玩，大家紛紛揭竿而起，docker公司也扛不住了，所以就跟大家一起協商，定義了一些規範，以後我們大家只要按照這個規範來，就能夠被大家接受

所謂規範，這也就是我們平時開發中的面向介面程式設計，我們大家先把介面定義好，至於怎麼實現，實現的效能怎麼樣，就各憑本事了，具體的子類實現，由每個公司自己實現，大家只要遵循規範，都能夠成功執行，介面是大家一起說明好的，也是每個人同意的，所以最後誰好誰效能優秀，其他人都要承認，自己家的產品都要相容別人的，這樣對外客戶端提供統一介面，客戶根本不關心其具體實現。

shim

因為runc的工作比較專一就是去建立容器，簡而言之，就是隻管殺不管埋，這樣肯定是不行的，runc就是一個客戶端工具，執行完就結束了自己的生命週期，這個時候，需要有一個守護者，去監控容器的狀態，還記的我們【docker exec -it containerId sh】的命令嗎，我們可以進行容器互動式操作，進入容器內部，這個就是shim需要乾的活，容器不會因為runc，docker daemon等元件的異常而退出，而是利用shim來保持容器內外部的通訊

docker目前這種分層架構的優勢

1.每個元件相互解耦，各司其職，跟spring mvc ,spring core，mybatis類似，並且每個元件都會定義出類似的規範，例如容器規範，映象規範，可以讓容器整個生態更加開放，更多的參與者能夠參與進來

2.各個元件之間相互不影響，或者說把影響的程度降到最低，每一個元件都是能夠獨擋一面，例如runc它能夠獨立使用

小結

本小節，簡單地介紹了一下docker的整體架構，其實更多的是讓大家有一個印象，沒有深入去了解其中的執行原理，只是讓大家知道，其實docker的架構跟我們平時的開發分層架構也很類似，並沒有那種高深令人捉摸不透的架構理念，其實我們這些"凡夫俗子"能夠看懂的

如果你能看到這裡，覺得花5分鐘，看的物有所值的話，幫忙加一個關注，本小節適合手機或者PC端觀看~