《基于Kubernetes的容器云平臺實戰》——1.3　Docker基本概念

1.3　Docker基本概念

用戶使用Docker的一般場景如下：用戶在某鏡像基礎上，在本地生成并標識新鏡像；也可根據鏡像標識從鏡像倉庫下載鏡像到本地；Docker引擎利用本地鏡像創建出多個相互隔離運行的容器；或者先自動下載，然后創建出容器。這里涉及三個基本概念，即鏡像、容器和鏡像倉庫（如圖1-2所示）。為了能夠很好地理解和運用Docker，有必要先對一些基本概念進行整理和說明。

圖1-2　Docker容器示意圖

1.3.1　鏡像

盡管鏡像的創建是Docker引擎的重要功能，但對此話題的介紹可以參考“鏡像管理”一章的內容，這里不再贅述。這里首先介紹的是鏡像的標識、存儲和傳輸這幾方面的內容。

鏡像的標識

在Docker中，鏡像以及與鏡像相關的層、配置都是用十六進制字符串表示的摘要來唯一標識的，這種摘要一般稱為ID。但是這種ID形式不利于記憶，因此對于鏡像來說，人們更喜歡使用另一種標識形式：example.com:5000/org/app:v1.0.0，被稱為鏡像的名稱或者引用。

這種鏡像名稱中可以帶有鏡像倉庫的主機名和端口號，下載鏡像時，Docker就是根據它們（可以是IP地址加端口號）來訪問鏡像倉庫的。如果鏡像名稱中沒有倉庫的主機名和端口號，那么默認倉庫域名指向registry-1.docker.io，而端口號為80。Docker訪問鏡像倉庫時一般使用HTTPS，只有對運行在本機上的倉庫服務才默認使用HTTP傳輸。

鏡像名稱中的路徑部分相當于命名空間，并且鏡像名后可帶有標簽（tag）和鏡像摘要（digest）部分。標簽的前綴為“:”，如果鏡像名稱中不帶有標簽的話，Docker會自動為它加上“latest”；而鏡像摘要部分的前綴為“@”；這兩者最好不要組合使用。

鏡像摘要是在鏡像倉庫創建鏡像的時候生成的，也是一個十六進制串（帶有表示產生鏡像摘要的算法前綴，比如“sha256:”）。Docker引擎可從鏡像倉庫返回的消息頭中得到鏡像摘要，并記錄在鏡像的描述信息中。鏡像倉庫可以根據鏡像名稱中的鏡像摘要直接準確地索引到鏡像的描述文件。

當使用docker images列出本地倉庫中的鏡像時，可以看到如下輸出：

REPOSITORY? ? ? ? ? ? ? ? TAG? ? IMAGE ID? ? ? CREATED? ? ? ?SIZE

127.0.0.1:5000/alpine-32? 3.6.2? c0f08c91ed89? 4 months ago? 3.92MB

那么，這個鏡像的標識為127.0.0.1:5000/alpine-32:3.6.2，其內部鏡像ID的縮寫，也就是完整摘要串的前綴為c0f08c91ed89。

鏡像的存儲

Docker引擎將本地鏡像默認存儲在/var/lib/docker目錄下，其中，image目錄中包含鏡像的元數據以及各個層的鏈接關系，而實際的鏡像層通過AUFS、Btrfs、ZFS、OverlayFS和Device Mapper等支持COW技術的文件系統來構建，并通過內容可尋址的ID，由元數據將它們關聯起來。使用了內容可尋址的ID后，就可以在鏡像的存儲和傳輸過程中實現鏡像層的共享和緩存。

由于歷史原因，Docker原生的鏡像配置文件中不僅包含鏡像層的相互關系，還包含此鏡像用于何種平臺環境、何種OS、創建時間、默認啟動運行命令等很多元數據。而經過標準化的manifest文件只包含各個層的描述符，以及這個原生配置文件對應的描述符。這兩種描述文件都是json格式的。

兩種描述文件中都有各個層的摘要信息的匯聚，并且這些層是有嚴格的前后順序的。Docker原生鏡像配置文件中各個層的本地標識與標準化的manifest中各個層的摘要不一樣，原因在于manifest中各個層的摘要是直接根據各個層的tar格式歸檔文件來計算的，而原生鏡像配置文件中的各個層的摘要是先對各個層中包含的每一個文件計算其摘要，再與目錄信息組成一個列表，將這個列表用tar格式歸檔文件保存起來，并計算其摘要作為各個層的標識。在鏡像倉庫中，除了保存各個層的tar文件之外，還需要保存鏡像對應的Docker原生鏡像配置文件，此配置文件也有自己的摘要，也會在manifest文件中有對應描述。但是在Docker引擎中并不保存manifest文件，而只保存各個層的摘要和本地標識之間的對應

關系。

這里只給出一個manifest json串的例子，原因在于鏡像傳輸過程中，它是與鏡像倉庫之間交互的基礎：

{

"schemaVersion": 2,

"mediaType": "application/vnd.docker.distribution.manifest.v2+json",

"config": {

"mediaType": "application/vnd.docker.container.image.v1+json",

"size": 1702,

"digest": "sha256:c0f08c91..."

},

"layers": [

{

"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",

"size": 2045593,

"digest": "sha256:c493eb32..."

},

{

"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",

"size": 8259,

"digest": "sha256:eb43f181..."

}

]

}

鏡像的傳輸

客戶端在上傳和下載鏡像時，首先請求和發送manifest文件，然后是配置文件和各個層的歸檔壓縮文件。由于每個元素都對應著唯一摘要，只要請求中帶上它，不管是鏡像倉庫還是Docker引擎，都可以據此判斷出鏡像或者某個層是否已經存儲在本地了。只有鏡像倉庫或者本地沒有的鏡像/鏡像層，才需要上傳和下載。

在傳輸的每一個步驟中都使用media-type以說明請求和載荷的內容。比如：application/vnd.docker.distribution.manifest.v2+json，對應著manifest文件。這些media-type已經被標準化，并且整個傳輸過程也被標準化了。

容器 Kubernetes 鏡像服務 Docker

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。