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

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

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

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

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

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

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

后端上傳鏡像流程分析

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

上傳鏡像層

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

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

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

上傳manifest

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

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

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

鏡像層

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

Manifest

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

鏡像壓縮包結構分析

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

根目錄下有這三個文件：

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

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

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

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

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

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

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

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

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

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

解壓并校驗

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

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

保存實體文件

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

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

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

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

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

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

華為云APP 容器鏡像服務 SWR

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

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