極簡容器化交付 | 0命令行完成鏡像上傳

雖然docker、kubernetes的命令集并非十分復(fù)雜，后臺操作也比較快捷，但是對于大多數(shù)徘徊在容器化門口的企業(yè)和個(gè)人用戶來說，仍舊是一塊心病，docker or not docker， that's a question，SWR服務(wù)通過提供界面化的操作，屏蔽原生命令行，簡化用戶操作和技術(shù)門檻，為企業(yè)和個(gè)人用戶提供極簡的容器化交付平臺，我們接下來會通過一系列的文章，向大家介紹SWR的這些功能特性。

今天要為大家介紹的是用戶0命令行，通過WEB界面實(shí)現(xiàn)鏡像的上傳及實(shí)現(xiàn)原理剖析。

我們從這個(gè)最為常用并極為簡單的docker push功能開始講，為什么呢？由于我們在與客戶交流過程中發(fā)現(xiàn)，大多數(shù)都未接觸過容器化管理系統(tǒng)，甚至鏡像，對后端操作不熟悉的他們，對頁面操作是有一定需求的。目前主流的PaaS平臺基本都支持通過頁面操作構(gòu)建鏡像、創(chuàng)建集群、創(chuàng)建應(yīng)用等等，它們都在不斷地封裝底層集群管理系統(tǒng)（如kubernetes）的接口，設(shè)計(jì)一款對于云下用戶友好的前端頁面，讓盡可能多的后端復(fù)雜操作可以通過鼠標(biāo)的幾次點(diǎn)擊完成。

我們可以將這個(gè)趨勢解釋為，用戶的業(yè)務(wù)云化的成本（包括金錢成本和時(shí)間成本）越低，上云的傾向也就越大。如今，我們支持用戶在頁面上完成構(gòu)建、部署等操作，如果可以實(shí)現(xiàn)鏡像上傳下載都在頁面上完成，用戶就可以在嘗試云化的早期盡可能避開后端操作，將盡可能多的時(shí)間成本花在業(yè)務(wù)調(diào)試上，普通運(yùn)維人員不需要熟悉docker命令，也可以從內(nèi)網(wǎng)或者第三方鏡像倉庫下載鏡像，上傳并完成升級操作。

接下來，我們從鏡像上傳邏輯和鏡像結(jié)構(gòu)開始講起，闡述如何去實(shí)現(xiàn)頁面上傳鏡像的功能。

后端上傳鏡像流程分析

我們的目的是實(shí)現(xiàn)另一種鏡像上傳方式，首先要了解原生的鏡像上傳流程是怎樣的。

上傳鏡像層

docker push時(shí)，最先被上傳的是鏡像層文件。如下面的busybox，每一行的short ID都表示著一個(gè)鏡像層的sha256值，它有兩個(gè)鏡像層：

上傳元數(shù)據(jù)文件

由于層之間有順序依賴關(guān)系，我們可以想到，上傳的層文件是不足以完備地描述整個(gè)鏡像的。除了鏡像層文件外，docker push的時(shí)候還額外會上傳一個(gè)鏡像的元數(shù)據(jù)文件。該文件主要保存了鏡像的環(huán)境變量、層結(jié)構(gòu)、構(gòu)建信息等等，并且它的sha256值就是鏡像的ID。由于字段太多，在此不詳細(xì)列出各字段的含義，感興趣的朋友可以使用docker inspect命令查看，參閱docker官方文檔了解一下。

上傳manifest

你們是否注意到，每個(gè)鏡像在上傳結(jié)束之后，屏幕上都會多一行xxx: digest: xxx size: xxx，最后一行信息的打印，標(biāo)識著鏡像最后一部分?jǐn)?shù)據(jù)上傳完成，這部分?jǐn)?shù)據(jù)就是manifest，而digest后面的長ID，就是manifest的sha256值。

manifest主要是負(fù)責(zé)關(guān)聯(lián)鏡像的元數(shù)據(jù)文件和鏡像層。在所有層都上傳結(jié)束后，它才被傳到倉庫端的，用于校驗(yàn)是否所有實(shí)體文件都上傳完成。通過抓包或者查閱官方文檔，我們可以得知，manifest的結(jié)構(gòu)是這樣的：

由上述分析可知，要完備地描述一個(gè)鏡像，需要存儲如下數(shù)據(jù)：

鏡像層

元數(shù)據(jù)文件

Manifest

我們接下來分析一下，從docker save生成的鏡像包里，我們是否能獲取到這些數(shù)據(jù)。

鏡像壓縮包結(jié)構(gòu)分析

通過docker save保存鏡像壓縮包，解壓開之后，可以發(fā)現(xiàn)，它的文件結(jié)構(gòu)是比較有序的。

根目錄下有這三個(gè)文件：

此外，包內(nèi)還有多個(gè)以長ID命名的目錄，每個(gè)目錄下均有如下三個(gè)文件：

這里，有兩個(gè)較為普遍的誤區(qū)需要澄清一下：

誤區(qū)一：manifest.json就是manifest

manifest里描述的是元數(shù)據(jù)文件名稱，以及各個(gè)層的sha256值，此外，還有它們的大小。

而manifest.json里存放的不是完整的manifest信息，它僅僅記錄了元數(shù)據(jù)文件的全路徑名稱，以及各個(gè)鏡像層的全路徑名稱，沒有記錄各個(gè)層的sha256值和大小。

誤區(qū)二：各個(gè)層所在的目錄名就是鏡像層的sha256值

其實(shí)目錄名是用各個(gè)層的鏈ID（chain ID）和關(guān)聯(lián)父層的鏈ID聯(lián)合計(jì)算出來的一個(gè)特殊sha256值。這個(gè)特殊的sha256值，我們可以稱之為v1 ID，它被設(shè)計(jì)于兼容較早版本(1.10之前)的docker鏡像，早期版本，一個(gè)鏡像中可能存在多個(gè)sha256值相同的層（如空層）。

順帶提一下，上面的鏈ID是docker daemon使用遞歸的方式將每一層與依賴的所有父層聯(lián)合算出sha256得到的，它可以有效解決層相同導(dǎo)致目錄重名的問題，具體計(jì)算方式在此就不贅述了。

明白了這兩點(diǎn)之后，我們可以發(fā)現(xiàn)，鏡像壓縮包里是可以獲取到與docker push同樣完備的鏡像數(shù)據(jù)的。其中，鏡像層和元數(shù)據(jù)文件可以通過解壓直接獲取，而manifest則需要我們通過補(bǔ)充manifest.json獲得。接下來我們看一看華為云容器鏡像服務(wù)是怎么實(shí)現(xiàn)這一過程的。

頁面上傳是怎么實(shí)現(xiàn)的

解壓并校驗(yàn)

鏡像壓縮包傳至后端時(shí)，先對壓縮包里的文件類型校驗(yàn)（普通文件、軟鏈接、目錄），確認(rèn)無誤之后，解壓至臨時(shí)目錄并進(jìn)行大小校驗(yàn)（前端上傳目前有大小限制）。

此外，有一類鏡像需要被過濾：通過docker save image_id > image.tar命令生成的鏡像包。這類鏡像是沒有有效的鏡像倉庫和版本號信息的，我們無法判斷要將其歸于哪個(gè)倉庫下，因此，這樣的鏡像可以認(rèn)為是不合法的。對于頁面上傳而言，合法的鏡像壓縮包里必須有鏡像倉庫和版本號信息(如使用docker save repository:tag > image.tar的方式生成的鏡像)。

保存實(shí)體文件

接下來，通過臨時(shí)目錄下的manifest.json，找到對應(yīng)的元數(shù)據(jù)文件xxxx.json和各個(gè)目錄下的鏡像層文件進(jìn)行存儲。保存之前，通過元數(shù)據(jù)文件xxxx.json中各個(gè)層的sha256值，對實(shí)際鏡像文件進(jìn)行校驗(yàn)，保存過程中，我們在manifest.json的基礎(chǔ)上，補(bǔ)充各個(gè)鏡像層和元數(shù)據(jù)文件的sha256值、大小等信息，得到manifest。

在這里有個(gè)需要注意的地方，層文件一般都是普通文件，但是個(gè)別情況下（如docker1.10之前的版本），層文件可能是軟鏈接，指向同鏡像壓縮包里的的另一個(gè)層文件，如果要兼容老版本，需要識別出這一部分特殊文件，跳過實(shí)體文件的保存。

保存元數(shù)據(jù)

最后，將鏡像層元數(shù)據(jù)列表和manifest元數(shù)據(jù)在同一事務(wù)里存進(jìn)數(shù)據(jù)庫，保證鏡像元數(shù)據(jù)的存儲是一個(gè)原子操作，則鏡像所有數(shù)據(jù)保存完成。該鏡像可以通過docker pull的方式正常下載。

這只是華為云容器鏡像服務(wù)基于優(yōu)化用戶體驗(yàn)的目的而開發(fā)的特性之一，我們一直致力于降低云容器技術(shù)的檻和使用成本，推進(jìn)軟件行業(yè)容器化的進(jìn)程，希望有興趣的朋友可以來體驗(yàn)一下，并提供你們寶貴的意見。

除此之外，我們最近還新上線了容器持續(xù)交付的工具，可以將您的源碼快速編譯、構(gòu)建成鏡像，省去本地編寫Dockerfile、鏡像制作、發(fā)布和部署的繁瑣過程，后面文章我們將詳細(xì)為您介紹。