背景

正在看一篇論文，名為《Efficient Service Handoff Across Edge Servers via Docker Container Migration》，里面介紹了如何利用docker快速遷移應用，對于一些低延遲的場景比較有用，里面有關于docker存儲的方面，所以就有了本篇文章

---

一.Docker的老存儲引擎AUFS

1.1 什么是AUFS

AUFS是一種 Union File System，全稱是Advanced Union File System，主要是把不同物理位置的目錄合并mount到同一個目錄下

1.2 AUFS的讀寫操作

將多個目錄mount成一個后，讀寫操作如下：

• 默認情況下，最上層的目錄是讀寫層，下面可以有一個或者多個只讀層
• 讀文件時，打開文檔使用O_RDONLY選項，從最上面一個文件開始逐層往下找，打開第一個找到的文件，并讀取其中的內(nèi)容
• 寫文件時，打開文件使用O_WRONLY和O_RDWR選項
  • 如果在最上層找到文件，直接打開文件
  • 如果是在只讀層中找到，則將該文件復制到最上層，然后在最上層打開這個copy的文件(如果讀寫的文件比較大，這個過程耗費的時間就會比較久)
• 刪除文件，在最上層創(chuàng)建一個whiteout文件，就是在原來文件名字前面加上.wh

---

二、Docker使用的存儲引擎

2.1 Docker 默認的存儲引擎

AUFS是及更早版本的首選存儲驅(qū)動程序，之后的docker版本默認存儲引擎是Overlay2。需要注意的是：不同的存儲引擎是需要文件系統(tǒng)支持的！

2.2 Docker層的實現(xiàn)

構建docker鏡像時一般使用dockerfile的方式(也可以在容器里面修改，然后commit成新的鏡像，前者可以看到具體的實現(xiàn)，后者除了作者，沒人知道如何實現(xiàn)的，所以一般使用前者的方式)，而docker的每行命令，都會生成一個層，即使沒做什么事。在寫dockerfile時，要避免生成很多層，因為使用存儲引擎在進行文件查找時，會遍歷層，會消耗性能

docker的鏡像層和容器層如圖所示：

Image layers是base image層，該層是不可改動的（例子中是ubuntu:鏡像），是靜態(tài)的（理解為是不會發(fā)生變化的）;

當我們基于image layer運行容器時(比如基于ubuntu:鏡像運行容器)，Docker會創(chuàng)建一個讀寫層，也就是圖中的Container layer，該讀寫層位于所有層的最上面。

我們對容器的更改操作都會在該讀寫層中，當我們執(zhí)行 docker commit 命令去保存我們的改動，生成新的鏡像時，就相當于給該讀寫層copy了一下，放到了Image layers中了

2.3 Docker實現(xiàn)文件的增刪改

2.3.1 copy-on-write寫時復制策略

我們首先需要了解Docker中使用的copy-on-write策略，該策略不是docker設計出的，而是最初沿用AUFS存儲引擎的策略，該部分的內(nèi)容見Docker的老存儲引擎AUFS

2.3.2 allocate-on-demand用時分配

用時分配是應用在原本沒有該文件的場景，只有在新寫入一個文件時才分配空間，這樣可以提高存儲資源的利用率。比如：啟動一個容器時，并不會為這個容器預分配一些磁盤空間，只有當新文件寫入時，才按需分配新空間

如此設計的好處

• 最顯而易見的好處是減少了存儲空間；鏡像被分成了很多靜態(tài)可讀層，而這些層是可以共享的；當基于本地一個已有的鏡像去構建一個新的鏡像時，只需要添加新的層，原有的層可以直接使用
• 啟動容器變得輕量快速，因為啟動容器時，只是在已有的層上添加了一層讀寫層，其他層都是用到的時候才會去搜索，遵循copy-on-write原則

---

三. Docker存儲引擎之Overlay2詳細過程

本節(jié)內(nèi)容是我想寫這篇文章的主要原因，前面介紹AUFS主要是因為該論文是2017年SEC會議收集的，那時候docker還是使用的AUFS引擎，現(xiàn)在docker已經(jīng)默認使用Overlay2了，但是對于核心的思想，都是一樣的。下面這一部分會以一個具體的例子來介紹docker存儲中的一些id的作用，以及image是如何和layer映射到一起的。實驗步驟如下：

1.拉取一個鏡像，并基于鏡像啟動一個容器，這里以jenkins/jenkins為例子（選擇該鏡像是因為之后要利用jenkins跑CI），大家做測試可以選擇busybox

2.查看容器的ID，是為了去找到對應的layer層

root@VM-0-3-ubuntu:/home/ubuntu# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 39274f2825c4 jenkins/jenkins "/sbin/tini -- /usr/…" 23 hours ago Up 23 hours 0.0.0.0:8080->8080/tcp, 50000/tcp test

可以看到容器的ID是39274f2825c4

3.查看鏡像ID，是為了該鏡像的元數(shù)據(jù)，即該鏡像包含哪些layer層

root@VM-0-3-ubuntu:/home/ubuntu# docker images REPOSITORY TAG IMAGE ID CREATED SIZE jenkins/jenkins latest 13e2b551515d 3 days ago 717MB

我們可以看到鏡像的ID是13e2b551515d

4.到 /var/lib/docker/image/overlay2/imagedb/content/sha256 目錄下找到對應鏡像文件的元數(shù)據(jù)(這里是用Step3找到的鏡像ID)，cat該文件，并找到rootfs部分的diff_ids

cat ${Image_Id}| python -m json.tool | grep rootfs -A 50"rootfs": {"diff_ids": ["sha256:7948c3e5790c6df89fe48041fabd8f1c576d4bb7c869183e03b9e3873a5f33d9","sha256:4d1ab3827f6b69f4e55bd69cc8abe1dde7d7a7f61bd6e32c665f12e0a8efd1c9",........"sha256:f7e3a65f50c8e650b07c6ea2e2486852543ae281a680cb3b71f05b4a58118cb4"],"type": "layers"}

這里一共有20層，我將中間的一些層去掉了，但是不妨礙分析。最上面的7948c3e5...是Image的layer層的底層，那既然找到了diff_id，我們再去看下layer層的實現(xiàn)

5.在/var/lib/docker/image/overlay2/layerdb/sha256目錄下去查看layer信息(sha256目錄保存的是可讀層的信息，mount目錄保存的讀寫層的信息)

root@VM-0-3-ubuntu:/var/lib/docker/image/overlay2/layerdb/sha256# ls -la total 92 drwxr-xr-x 23 root root 4096 Nov 14 10:25 . drwx------ 5 root root 4096 Nov 13 10:54 .. drwx------ 2 root root 4096 Nov 13 12:44 0277e531f0f0767896e5e3c953a44bac7d46a1595ea9e1a461257d9664868be6 #此處去掉了一些層 drwx------ 2 root root 4096 Nov 11 14:06 7948c3e5790c6df89fe48041fabd8f1c576d4bb7c869183e03b9e3873a5f33d9

我們可以看到，僅僅只能找到7948c3e579...這個Image的底層，其他的layer在這個目錄下都找不到，這是為什么呢？

這是由于Docker使用了chainID來保存layer，計算公式是：chainID=sha256sum(H(chainID) diffid),其中如果是最底層layer，那么其chainID=diff_id。所以在sha256目錄下，我們只會看到Image的最底層layer，而看不到其他的layer。 （sha256下的目錄是以chainID命名的，而不是以diff_id命名的，所以需要轉(zhuǎn)換一下）

6.計算下7948c3e579...下一層的chainID

root@VM-0-3-ubuntu:/var/lib/docker/image/overlay2/layerdb/sha256# echo -n "sha256:7948c3e5790c6df89fe48041fabd8f1c576d4bb7c869183e03b9e3873a5f33d9 sha256:4d1ab3827f6b69f4e55bd69cc8abe1dde7d7a7f61bd6e32c665f12e0a8efd1c9" | sha256sum 72df91e735ae2b70a23f1770aa365b67f4772a545ed0a23d3decc7643b21a4e4 -

可以看到下一層的chainID是72df91e735........，這樣我們能從layerdb/sha256找到對應的下一層了，依次類推，我們能知道所有的層級結構；

目錄下的layerdb目錄中保存的是元數(shù)據(jù)，那么我們需要到overlay2目錄中去找到對應的真實目錄，那么這個之間的映射關系是怎么得到的呢？

這個時候cache-id就排上用場了，我們可以打印出該chainID的cache-id,并到overlay2目錄中去找（dockr會創(chuàng)建/var/lib/docker/{存儲引擎名稱}老保存實際的數(shù)據(jù)）

#到最底層7948c3e579...中打印cache-id root@VM-0-3-ubuntu:/var/lib/docker/image/overlay2/layerdb/sha256/7948c3e5790c6df89fe48041fabd8f1c576d4bb7c869183e03b9e3873a5f33d9# cat cache-id cecf9979915e13912ed6cba6dbf22d622c4c59e645fe57ce37a76f5e098363c6#到/var/lib/dockr/overlay2中找到對應的目錄 root@VM-0-3-ubuntu:/var/lib/docker/overlay2# ls -la | grep cecf9979915e13912ed6cba6dbf22 drwx------ 3 root root 4096 Nov 11 14:06 cecf9979915e13912ed6cba6dbf22d622c4c59e645fe57ce37a76f5e098363c6

可以看到已經(jīng)找到對應的目錄了，該目錄中記錄了所有的diff

8.在Step2中找到的容器ID的元數(shù)據(jù)其實是保存在/var/lib/docker/image/overlay2/layerdb/mount/目錄下，該目錄保存的是docker的容器讀寫層。這其實也對應了docker的存儲實現(xiàn)機制，鏡像都是只讀層，當運行一個容器時，會產(chǎn)生一個容器層，該層即是讀寫層。

root@VM-0-3-ubuntu:/var/lib/docker/image/overlay2/layerdb/mounts# ls -la drwxr-xr-x 2 root root 4096 Nov 13 10:54 39274f2825c4ac012eb08ffc7fe7b383ab2f7ccda0f7fd1fd046b235d32d8a93

查看該目錄下的文件

root@VM-0-3-ubuntu:/var/lib/docker/image/overlay2/layerdb/mounts/39274f2825c4ac012eb08ffc7fe7b383ab2f7ccda0f7fd1fd046b235d32d8a93# ls -l total 12 -rw-r--r-- 1 root root 69 Nov 13 10:54 init-id -rw-r--r-- 1 root root 64 Nov 13 10:54 mount-id -rw-r--r-- 1 root root 71 Nov 13 10:54 parent

init-id 和 mount-id里面的內(nèi)容基本一樣，都是記錄該容器層的cache-id，用來映射overlays目錄下真實的存儲層

parent文件是記錄上一層的layer層，里面記錄的chainID

---

四. 參考資料

因為最初只是將知識記錄在自己的有道云上，因此有部分網(wǎng)上的資料忘記了存儲鏈接，若有兄弟發(fā)現(xiàn)自己寫的文章被我引用了，請聯(lián)系我刪除或者補鏈接！

參考資料如下：

Docker存儲驅(qū)動之--overlay2

總結

以上是生活随笔為你收集整理的docker修改镜像的存储位置_Docker存储原理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。