引言
通常我們在使用集群或者容器的時候，都會接觸到存盤在本地的鏡像，也或多或少對本地鏡像存盤有一定的了解，但是服務端的鏡像存盤細節呢？本文主要介紹容器鏡像的服務端存盤結構，對于自建鏡像服務或是對容器鏡像底層原理或優化有興趣的同學可以了解一下，
相關開源專案
目前容器鏡像服務相關的開源專案主要有以下兩個，
- Registry (https://github.com/docker/distribution)
- Harbor (https://github.com/goharbor/harbor)
Registry具有基本的鏡像上傳、下載以及對接第三方鑒權的能力，Harbor則基于Registry做了相應的企業級擴展的專案，提供了更多權限、審計、鏡像等功能，目前是CNCF范訓專案之一，其他詳情參考相關文章，這篇文章主要講解Registry專案的存盤細節，
鏡像細節
在了解服務端之前，我們來了解一下客戶端的鏡像容器的存盤環境，
聯合檔案系統 UnionFS(Union File System)
Docker的存盤驅動的實作是基于UnionFS，簡單列舉一下UnionFS下存盤鏡像的一些特點，
首先，UnionFS是一個分層的檔案系統，一個Docker鏡像可能有多個層組成（注意他們是有順序的），
其次，只有頂層是可寫的，其它層都是只讀的，這樣的機制帶來的好處是鏡像層可以被多個鏡像共享，對于Docker鏡像來說，所有層都是只讀的，當一個鏡像運行時，會在該鏡像上增加一個容器層，十個相同的鏡像啟動，僅僅是增加十個容器層，銷毀容器時也僅僅是銷毀一個容器層而已，
-
UnionFS是一個分層的檔案系統，一個Docker鏡像可能有多個層組成（注意他們是有順序的），
-
只有頂層是可寫的，其它層都是只讀的，這樣的機制帶來的好處是鏡像層可以被多個鏡像共享，對于Docker鏡像來說，所有層都是只讀的，當一個鏡像運行時，會在該鏡像上增加一個容器層，十個相同的鏡像啟動，僅僅是增加十個容器層，銷毀容器時也僅僅是銷毀一個容器層而已，
-
- 當容器需要讀取檔案的時候：從最上層鏡像開始查找，往下找，找到檔案后讀取并放入記憶體，若已經在記憶體中了，直接使用，(即，同一臺機器上運行的docker容器共享運行時相同的檔案)，
- 當容器需要添加檔案的時候：直接在最上面的容器層可寫層添加檔案，不會影響鏡像層，
- 當容器需要修改檔案的時候：從上往下層尋找檔案，找到后，復制到容器可寫層，然后，對容器來說，可以看到的是容器層的這個檔案，看不到鏡像層里的檔案，容器在容器層修改這個檔案，
- 當容器需要洗掉檔案的時候：從上往下層尋找檔案，找到后在容器中記錄洗掉，即，并不會真正的洗掉檔案，而是軟洗掉，這將導致鏡像體積只會增加，不會減少，
由此可以思考很多安全和鏡像優化上的問題，
- 在鏡像構建中記錄敏感資訊然后再下一個構建指令中洗掉安全嗎？（不安全）
- 在鏡像構建中安裝軟體包然后再下一個構建指令中清理軟體包能減小鏡像體積嗎？（并不能）
UnionFS一般有兩種實作方案：1. 基于檔案實作，檔案整體的覆寫重寫，2. 基于塊實作，對檔案的修改只修改少量塊，
鏡像的服務端存盤細節
提供一個鏡像元資訊(manifest)用于參考：
? ~ docker pull ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c7b1c981c: Pulling from paas/service-controllerDigest: sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419Status: Image is up to date for ccr.ccs.tencentyun.com/paas/service-controller:7b1c981cccr.ccs.tencentyun.com/paas/service-controller:7b1c981c
{ "schemaVersion": 2, "mediaType": "application/vnd.docker.distribution.manifest.v2+json", "config": { "mediaType": "application/vnd.docker.container.image.v1+json", "size": 4671, "digest": "sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827" }, "layers": [ { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 44144090, "digest": "sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 529, "digest": "sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 849, "digest": "sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 170, "digest": "sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 8461461, "digest": "sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f" }, { "mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip", "size": 22178452, "digest": "sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f" } ]}
*接下來是本文最為重要的內容，通過對上面這張圖的理解，我們就可以了解到Registry服務端存盤的細節，*
-
圖中藍色的是服務端存盤的目錄，文字是目錄名稱，這個名稱是固定的，
-
圖中紫色的是服務端存盤的檔案，文字是檔案名稱，
link檔案的內容都是一個sha256的哈希值，data檔案存盤了真正的元檔案和鏡像層， -
圖中橙色的是服務端的動態目錄，目錄的名稱和倉庫名、鏡像標簽或者sha256有關的，
整個圖是從上往下的，舉個例子，我們上面描述的manifest如果是存盤在服務端的話（檔案哈希:sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419），它存盤的路徑應該是：/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data，對應圖上應該是沿著左側一直向下，
我們開始拆解分析其結構細節，
-
左側是鏡像所有內容的實際存盤，其幾乎占據的絕大部分儲存的空間，包括了鏡像層和鏡像元資訊Manifest，
-
- 例如鏡像層
sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451的存盤位置，應該在/docker/registry/v2/blobs/sha256/e8/e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451/data
- 例如鏡像層
-
右側是鏡像元資訊存盤的地方，鏡像元資訊是按照命名空間和倉庫名稱分兩級目錄存盤的，
-
-
每一個倉庫下面又分為
_layers、_manifests兩個部分 -
_layers負責記錄該倉庫參考了哪些鏡像層檔案， -
_manifests負責記錄鏡像的元資訊 -
-
revisions包含了倉庫下曾經上傳過的所有版本的鏡像元資訊 -
tags包含了倉庫中的所有標簽 -
current記錄了當前標簽指向的鏡像index目錄則記錄了標簽指向的歷史鏡像，
-
-
對上述提供的manifest計算sha256，會得到元資訊檔案的哈希值
sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419，這個元資訊的存盤位置應該在/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data
-
舉個鏡像下載的例子：
我們想要知道ccr.ccs.tencentyun.com/paas/service-controller:7b1c981c這個鏡像現在的元資訊，如何在服務端存盤中找到，
- 找到
/docker/registry/v2/paas/service-controller/_manifests/tags/7b1c981c/current/link檔案，里面有元資訊的sha256資訊，內容應該是sha256:e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419 - 找到實際存盤檔案（
/docker/registry/v2/blobs/sha256/e8/e8b84ce6c245f04e6e453532d676f7c7f0a94b3122f93a89a58f9ae49939e419/data），前文中給出了該檔案的json內容， - 根據源檔案資訊，客戶端依次下載對應檔案就可以了，（鑒權程序參考參考檔案）
-
ImageConfig
sha256:785f4150a5d9f62562f462fa2d8b8764df4215f0f2e3a3716c867aa31887f827
-
ImageLayer
sha256:e80174c8b43b97abb6bf8901cc5dade4897f16eb53b12674bef1eae6ae847451 sha256:d1072db285cc5eb2f3415891381631501b3ad9b1a10da20ca2e932d7d8799988 sha256:858453671e6769806e0374869acce1d9e5d97f5020f86139e0862c7ada6da621 sha256:3d07b1124f982f6c5da7f1b85a0a12f9574d6ce7e8a84160cda939e5b3a1faad sha256:994dade28a14b2eac1450db7fa2ba53998164ed271b1e4b0503b1f89de44380c sha256:60a5bd5c14d0f37da92d2a5e94d6bbfc1e2a942d675aee24f055ced76e8a208f
Tips:
- 很明顯同樣的鏡像層檔案在存盤中只會有一個副本，使用相同基礎鏡像將節省大量的存盤成本，
- 如果想要算上述元資訊檔案的哈希值，請保證你復制的檔案內容尾部沒有EOL，[noeol]
基于存盤的幾個問題
鏡像構建如何優化？
根據UnionFS的特性，針對性的進行優化：
- 構建時，一個構建指令會生成一個鏡像層，盡量避免在鏡像層中出現垃圾檔案，例如在安裝軟體之后洗掉軟體包，
- 洗掉敏感資源并不能使得該內容真正消失，避免敏感內容造成的安全問題，例如編譯鏡像最后洗掉代碼是無效的欺騙自己的行為，
- 通過多階段構建，減少中間產物以及編譯環境中的依賴內容，
上傳到服務端鏡像，再上傳到其他倉庫需要重新上傳嗎？
需要，在Registry的設計中倉庫是權限的最小單位，用戶是根據倉庫進行權限管理與隔離的，考慮如果這里忽略了這一塊的設計，鏡像層存在就避免重復上傳的話，客戶端可以通過構造虛假鏡像元資訊的方式，越權獲取到其他用戶的鏡像，_layers中記錄了倉庫有權限獲取的所有鏡像層的目的就在于此，
鏡像復制場景下如何優化？
復制鏡像的場景和上傳場景的區別在于，源鏡像是用戶確實已經擁有的，這里可以通過上述問題的思考進行復制的優化，當鏡像層在目的地址已經存在時，直接標記倉庫擁有該層避免不必要的上傳，
鏡像歷史版本
根據存盤結構的特點，可以較為輕松的回答這個問題，理論上只要不做Registry GC，不洗掉倉庫元資訊，倉庫歷史版本的鏡像都會在倉庫中一直保存的，
怎么拿到鏡像的元資訊？
這里不做詳細講解了，有興趣的同學可以參考以下檔案：
- DockerRegistry API V2——https://docs.docker.com/registry/spec/api/
- Docker Registry TokenAuthentication Specification——https://docs.docker.com/registry/spec/auth/token/
- DockerImage Manifests V2 Schema2——https://docs.docker.com/registry/spec/manifest-v2-2/
云服務的存盤對接
Registry作為一個開源軟體，適配各種云存盤產品屬于標配功能了，Registry提供了標準的存盤驅動介面，只要實作了這一套介面就能適配運行起來了，
相關文章
- 為什么有了Docker registry還需要Harbor？——https://cloud.tencent.com/developer/article/1080444
- 理解Docker鏡像分層——https://www.cnblogs.com/woshimrf/p/docker-container-lawyer.html
- Docker Registry 存盤驅動——https://docs.docker.com/registry/storage-drivers/
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/105005.html
標籤：其他