Docker 鏡像詳細講解
前言
大家好,本文是對 Docker 鏡像的詳細講解,講解了如何安裝 Docker、配置 Docker 鏡像加速以及操作 Docker 鏡像。希望對大家有所幫助~
安裝 Docker
1.1 CentOS
Docker 要求 CentOS 系統的內核版本高於 3.10 ,查看本頁面的前提條件來驗證你的 CentOS 版本是否支持 Docker
通過 uname -r 命令查看你當前的內核版本
uname -r
使用 root 權限登錄 CentOS。確保 yum 包更新到最新
sudo yum update
卸載舊版本 (如果安裝過舊版本的話)
sudo yum remove docker docker-common docker-selinux docker-engine
安裝需要的軟件包, yum-util 提供 yum-config-manager 功能,另外兩個是 devicemapper 驅動依賴的
sudo yum install -y yum-utils device-mapper-persistent-data lvm2
設置 yum 源
- 官方源
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
- 阿里雲源
sudo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
- 清華大學源
sudo yum-config-manager --add-repo https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/centos/docker-ce.repo
安裝 docker
sudo yum install docker-ce
也可以查看所有倉庫中所有 docker 版本,並選擇特定版本安裝
yum list docker-ce --showduplicates | sort -r
sudo yum install docker-ce-版本號.ce
啓動並加入開機啓動
sudo systemctl start docker
sudo systemctl enable docker
驗證安裝是否成功 (有 client 和 service 兩部分表示 docker 安裝啓動都成功了)
docker version
1.2 Ubuntu
系統要求
Docker CE 支持以下版本的 Ubuntu 操作系統:
-
Artful 17.10 (Docker CE 17.11 Edge +)
-
Xenial 16.04 (LTS)
-
Trusty 14.04 (LTS)
Docker CE 可以安裝在 64 位的 x86 平臺或 ARM 平臺上。Ubuntu 發行版中,LTS(Long-Term-Support)長期支持版本,會獲得 5 年的升級維護支持,這樣的版本會更穩定,因此在生產環境中推薦使用 LTS 版本, 當前最新的 LTS 版本爲 Ubuntu 16.04。
卸載舊版本
舊版本的 Docker 稱爲 docker 或者 docker-engine,使用以下命令卸載舊版本:
sudo apt-get remove docker \
docker-engine \
docker.io
使用腳本自動安裝
在測試或開發環境中 Docker 官方爲了簡化安裝流程,提供了一套便捷的安裝腳本,Ubuntu 系統上可以使用這套安裝腳本:
curl -fsSL get.docker.com -o get-docker.sh
sudo sh get-docker.sh --mirror AzureChinaCloud
執行這個命令後,腳本就會自動的將一切準備工作做好,並且把 Docker CE 的 Edge 版本安裝在系統中
啓動 Docker CE
sudo systemctl enable docker
sudo systemctl start docker
卸載 Docker
-
先執行命令:apt-get autoremove docker-ce
-
刪除 /etc/apt/sources.list.d 目錄下的 docker.list 文件
Docker 鏡像加速器
國內從 Docker Hub 拉取鏡像有時會遇到困難,此時可以配置鏡像加速器。Docker 官方和國內很多雲服務商都提供了國內加速器服務,例如:
-
Docker 官方提供的中國 registry mirror
-
阿里雲加速器
-
DaoCloud 加速器
我們以 Docker 阿里雲加速器爲例進行介紹。
首先登錄阿里雲(沒有賬號請先註冊),搜索 容器鏡像服務,找到你的專屬加速器地址。
2.1 Ubuntu 14.04、Debian 7 Wheezy
對於使用 upstart 的系統而言,編輯 /etc/default/docker 文件,在其中的 DOCKER_OPTS 中配置加速器地址:
DOCKER_OPTS="--registry-mirror=https://xxxxxxxx.mirror.aliyuncs.com"
重新啓動服務。
sudo service docker restart
2.2 Ubuntu 16.04+、Debian 8+、CentOS 7
對於使用 systemd 的系統,請在 /etc/docker/daemon.json 中寫入如下內容(如果文件不存在請新建該文件)
{
"registry-mirrors": [
"https://xxxxxxxx.mirror.aliyuncs.com"
]
}
注意,一定要保證該文件符合 json 規範,否則 Docker 將不能啓動。
之後重新啓動服務。
sudo systemctl daemon-reload
sudo systemctl restart docker
2.3 Windows 10
對於使用 Windows 10 的系統,在系統右下角托盤 Docker 圖標內右鍵菜單選擇 Settings ,打開配置窗口後左側導航菜單選擇 Daemon 。在 Registry mirrors 一欄中填寫加速器地址 https://registry.docker-cn.com ,之後點擊 Apply 保存後 Docker 就會重啓並應用配置的鏡像地址了。
2.4 macOS
對於使用 macOS 的用戶,在任務欄點擊 Docker for mac 應用圖標 -> Perferences… -> Daemon -> Registry mirrors。在列表中填寫加速器地址 https://registry.docker-cn.com 。修改完成之後,點擊 Apply & Restart 按鈕,Docker 就會重啓並應用配置的鏡像地址了。
2.5 檢查加速器是否生效
配置加速器之後,如果拉取鏡像仍然十分緩慢,請手動檢查加速器配置是否生效,在命令行執行 docker info ,如果從結果中看到了如下內容,說明配置成功。
Registry Mirrors:
https://xxxxxxxx.mirror.aliyuncs.com
Docker 鏡像
3.1 獲取鏡像
之前提到過,Docker Hub 上有大量的高質量的鏡像可以用,這裏我們就說一下怎麼獲取這些鏡像。
從 Docker 鏡像倉庫獲取鏡像的命令是 docker pull 。其命令格式爲:
docker pull [選項] [Docker Registry 地址[:端口號]/]倉庫名[:標籤]
具體的選項可以通過 docker pull --help 命令看到,這裏我們說一下鏡像名稱的格式。
- Docker 鏡像倉庫地址:地址的格式一般是 <域名 / IP>[: 端口號] 。默認地址是 Docker Hub。
倉庫名:如之前所說,這裏的倉庫名是兩段式名稱,即 <用戶名>/< 軟件名 > 。對於 Docker Hub ,如果不給出用戶名,則默認爲 library ,也就是官方鏡像。
比如:
$ docker pull ubuntu:16.04
16.04: Pulling from library/ubuntu
4f53fa4d2cf0: Pull complete
6af7c939e38e: Pull complete
903d0ffd64f6: Pull complete
04feeed388b7: Pull complete
Digest: sha256:185fec2d6dbe9165f35e4a1136b4cf09363b328d4f850695393ca191aa1475fd
Status: Downloaded newer image for ubuntu:16.04
docker.io/library/ubuntu:16.04
上面的命令中沒有給出 Docker 鏡像倉庫地址,因此將會從 Docker Hub 獲取鏡像。而鏡像名稱是 ubuntu:16.04 ,因此將會獲取官方鏡像 library/ubuntu 倉庫中標籤爲 16.04 的鏡像。
從下載過程中可以看到我們之前提及的分層存儲的概念,鏡像是由多層存儲所構成。下載也是一層層的去下載,並非單一文件。下載過程中給出了每一層的 ID 的前 12 位。並且下載結束後,給出該鏡像完整的 sha256 的摘要,以確保下載一致性。
在使用上面命令的時候,你可能會發現,你所看到的層 ID 以及 sha256 的摘要和這裏不一樣。這是因爲官方鏡像是一致在維護的,有任何新的 bug,或者版本更新,都會進行修復再以原來的標籤發佈,這樣可有確保任何使用這個標籤的用戶可以獲得更安全、更穩定的鏡像。
如果從 Docker Hub 下載鏡像非常緩慢,可以參照 鏡像加速器 一節配置加速器。
3.1.1 運行
有了鏡像後,我們就能夠以這個鏡像爲基礎啓動並運行一個容器。以上面的 ubuntu:16.04 爲例,如果我們打算啓動裏面的 bash 並且進行交互式操作的話,可以執行下面的命令。
$ docker run -it --rm \
ubuntu:16.04 \
bash
root@e7009c6ce357:/# cat /etc/os-release
VERSION="16.04.4 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
docker run 就是運行容器的命令,我們這裏簡要的說明一下上面用到的參數。
-
it :這是兩個參數,一個是 -i :交互式操作,一個是 -t 終端。我們這裏打算進入 bash 執行一些命令並查看返回結果,因此我們需要交互式終端。
-
--rm :這個參數是說容器退出後隨之將其刪除。默認情況下,爲了排障需求,退出的容器並不會立即刪除,除非手動 docker rm 。我們這裏只是隨便執行個命令,看看結果,不需要排障和保留結果,因此使用 --rm 可以避免浪費空間。
-
ubuntu:16.04 :這是指用 ubuntu:16.04 鏡像爲基礎來啓動容器。
-
bash :放在鏡像名後的是命令,這裏我們希望有個交互式 Shell,因此用的是 bash。
進入容器後,我們可以在 Shell 下操作,執行任何所需的命令。這裏,我們執行了 cat /etc/os-release ,這是 Linux 常用的查看當前系統版本的命令,從返回的結果可以看到容器內是 Ubuntu 16.04.4 LTS 系統。
最後們通過 exit 或者 Ctrl + D 退出了這個容器。
3.2 列出鏡像
要想列出已經下載下來的鏡像,可以使用 docker image ls 命令。
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest 5f515359c7f8 5 days ago 183 MB
nginx latest 05a60462f8ba 5 days ago 181 MB
mongo 3.2 fe9198c04d62 5 days ago 342 MB
<none> <none> 00285df0df87 5 days ago 342 MB
ubuntu 16.04 f753707788c5 4 weeks ago 127 MB
ubuntu latest f753707788c5 4 weeks ago 127 MB
ubuntu 14.04 1e0c3dd64ccd 4 weeks ago 188 MB
列表包含了倉庫名、標籤、鏡像 ID、創建時間、以及所佔用的空間。
其中倉庫名、標籤在之前的基礎概念已經介紹過了。鏡像 ID 則是鏡像的唯一標識,一個鏡像可以對應多個標籤。因此,在上面的例子中,我們可以看到 ubuntu:16.04 和 ubuntu:latest 擁有相同的 ID,因爲它們對應的是同一個鏡像。
3.2.1 鏡像體積
如果仔細觀察,會注意到,這裏標識的所佔用空間和在 Docker Hub 上看到的鏡像大小不同。比如, ubuntu:16.04 鏡像大小,在這裏是 127MB ,但是在 Docker Hub 顯示的卻是 50MB 。這是因爲 Docker Hub 中顯示的體積是壓縮後的體積。在鏡像下載和上傳過程中鏡像是保持着壓縮狀態的,因此 Docker Hub 所顯示的是鏡像下載到本地後,展開的大小,準確說,是展開後的各層所佔空間的總和,因爲鏡像到本地後,查看空間的時候,更關心的是本地磁盤空間佔用的大小。
另外一個需要注意的問題是, docker image ls 列表中的鏡像體積總和並非是所有鏡像實際硬盤消耗,由於 Docker 鏡像是多層存儲結構,並且可以繼承、複用,因此不同鏡像可能會因爲使用相同的基礎鏡像,從而擁有共同的層。由於 Docker 使用 Union FS,相同的層只需要保存一份即可,因此實際鏡像硬盤佔用空間很可能要比這個列表鏡像大小的總和要小的多。
你可以通過以下命令來便捷的查看鏡像、容器、數據卷所佔用空間。
$ docker system df
TYPE TOTAL ACTIVE SIZE RECLAIMABLE
Images 24 0 1.992GB 1.992GB (100%)
Containers 1 0 62.82MB 62.82MB (100%)
Local Volumes 9 0 652.2MB 652.2MB (100%)
Build Cache
3.2.2 虛懸鏡像
尚明的鏡像列表中,還可以看到一個特殊的鏡像,這個鏡像既沒有倉庫名,也沒有標籤,均爲。:
<none> <none> 00285df0df87 5 days ago 342 MB
這個鏡像原本是有鏡像名和標籤的,原來爲 mongo:3.2,隨着官方鏡像維護,發佈了新版本後,重新 docker pull mongo:3.2 時, mongo:3.2 這個鏡像名被轉移到了新下載的鏡像身上,而舊的鏡像上的這個名稱則被取消,從而成爲了。除了 docker pull 可能導致這種情況, docker build 也同樣可以導致這種現象。由於新舊鏡像同名,舊鏡像名稱被取消,從而出現倉庫名、標籤均爲的鏡像。這類無標籤鏡像也被稱之爲 虛懸鏡像 (dangling image),可以用下面的命令專門顯示這類鏡像:
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 00285df0df87 5 days ago 342 MB
一般來說,虛懸鏡像已經失去了存在的價值,是可以隨意刪除的,可以用下面的命令刪除。
$ docker image prune
3.2.3 中間層鏡像
爲了加速鏡像構建、重複利用資源,Docker 會利用 中間層鏡像。所以在使用一段時間後,可能會看到一些依賴的中間層鏡像。默認的 docker image ls 列表中只會顯示頂層鏡像,如果希望顯示包括中間層鏡像在內的所有鏡像的話,需要加 -a 參數。
$ docker image ls -a
這樣會看到很多無標籤的鏡像,與之前的虛懸鏡像不同,這些無標籤的鏡像很多都是中間層鏡像,是其他鏡像所依賴的鏡像。這些無標籤鏡像不應該刪除,否者會導致上層鏡像因爲依賴丟失而出錯。實際上,這些鏡像也沒必要刪除,因爲之前說過,相同的層只會存一遍,而這些鏡像是別的鏡像的依賴,因此並不會因爲它們被列出來而多存了一份,無論如何你也會需要它們。只要刪除那些依賴它們的鏡像後,這些依賴的中間層鏡像也會被連帶刪除。
3.2.4 列出部分鏡像
不加任何參數的情況下,docker image ls 會列出所有頂級鏡像,但是有時候我們只希望列出部分鏡像。docker iimage ls 有好幾個參數可以幫助做到這個事情。
根據倉庫名列出鏡像
$ docker image ls ubuntu
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 16.04 f753707788c5 4 weeks ago 127 MB
ubuntu latest f753707788c5 4 weeks ago 127 MB
ubuntu 14.04 1e0c3dd64ccd 4 weeks ago 188 MB
列出特定的某個鏡像,也就是說指定倉庫名和標籤
$ docker image ls ubuntu:16.04
REPOSITORY TAG IMAGE ID CREATED SIZE
ubuntu 16.04 f753707788c5 4 weeks ago 127 MB
除此之外,docker image ls 還支持強大的過濾器參數 --filter,或者簡寫 -f。之前我們已經看到了使用過濾器來列出虛懸鏡像的用法,塔還有更多的用法。比如,我們希望在 mongo:3.2 之後建立的鏡像,可以用下面的命令:
$ docker image ls -f since=mongo:3.2
REPOSITORY TAG IMAGE ID CREATED SIZE
redis latest 5f515359c7f8 5 days ago 183 MB
nginx latest 05a60462f8ba 5 days ago 181 MB
想查看某個位置之前的鏡像也可以,只需要把 since 換成 before 即可。此外,如果鏡像構建時,定義了 LABEL ,還可以通過 LABEL 來過濾。
$ docker image ls -f label=com.example.version=0.1
...
3.2.5 以特定格式顯示
默認情況下, docker image ls 會輸出一個完整的表格,但是我們並非所有時候都會需要這些內容。比如,剛纔刪除虛懸鏡像的時候,我們需要利用 docker image ls 把所有的虛懸鏡像的 ID 列出來,然後纔可以交給 docker image rm 命令作爲參數來刪除指定的這些鏡像,這個時候就用到了 -q 參數。
$ docker image ls -q
5f515359c7f8
05a60462f8ba
fe9198c04d62
00285df0df87
f753707788c5
f753707788c5
1e0c3dd64ccd
--filter 配合 -q 產生出指定範圍的 ID 列表,然後送給另一個 docker 命令作爲參數,從而針對這組實體成批的進行某種操作的做法在 Docker 命令行使用過程中非常常見,不僅僅是鏡像,將來我們會在各個命令中看到這類搭配已完成很強大的功能。因此每次在文檔看到過濾器後,可以多注意一下它們的用法。
另外一些時候,我們可能只是對錶格的結構不滿意,希望自己組織列;或者不希望有標題,這樣方便其它程序解析結果等,這就用到了 Go 的模板語法。
比如,下面的命令會直接列出鏡像結果,並且只包含鏡像 ID 和倉庫名:
$ docker image ls --format "{{.ID}}: {{.Repository}}"
5f515359c7f8: redis
05a60462f8ba: nginx
fe9198c04d62: mongo
00285df0df87: <none>
f753707788c5: ubuntu
f753707788c5: ubuntu
1e0c3dd64ccd: ubuntu
或者打算以表格等距顯示,並且有標題行,和默認一樣,不過自己定義列:
docker image ls --format "table {{.ID}}\t{{.Repository}}\t{{.Tag}}"
3.3 刪除本地鏡像
如果想要刪除本地的鏡像,可以使用 docker image rm 命令,其格式爲:
docker image rm [選項] <鏡像1> [<鏡像2> ...]
3.3.1 用 ID、鏡像名、摘要刪除鏡像
其中, <鏡像> 可以是 鏡像短 ID、鏡像長 ID、鏡像名 或者 鏡像摘要。
比如我們有這麼一些鏡像:
$ docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
centos latest 0584b3d2cf6d 3 weeks ago 196.5 MB
redis alpine 501ad78535f0 3 weeks ago 21.03 MB
docker latest cf693ec9b5c7 3 weeks ago 105.1 MB
nginx latest e43d811ce2f4 5 weeks ago 181.5 MB
我們可以用鏡像的完整 ID,也稱爲 長 ID ,來刪除鏡像。使用腳本的時候可能會用長 ID,但是人工輸入就太累了,所以更多的時候使用 短 ID 來刪除鏡像。docker image ls 默認列出的就已經是短 ID 了,一般取前 3 個字符以上,只要足夠區分於別的鏡像就可以了。
比如這裏,如果我們要刪除 redis:alpine 鏡像,可以執行:
$ docker image rm 501
Untagged: redis:alpine
Untagged: redis@sha256:f1ed3708f538b537eb9c2a7dd50dc90a706f7debd7e1196c9264edeea521a86d
Deleted: sha256:501ad78535f015d88872e13fa87a828425117e3d28075d0c117932b05bf189b7
Deleted: sha256:96167737e29ca8e9d74982ef2a0dda76ed7b430da55e321c071f0dbff8c2899b
Deleted: sha256:32770d1dcf835f192cafd6b9263b7b597a1778a403a109e2cc2ee866f74adf23
Deleted: sha256:127227698ad74a5846ff5153475e03439d96d4b1c7f2a449c7a826ef74a2d2fa
Deleted: sha256:1333ecc582459bac54e1437335c0816bc17634e131ea0cc48daa27d32c75eab3
Deleted: sha256:4fc455b921edf9c4aea207c51ab39b10b06540c8b4825ba57b3feed1668fa7c7
我們也可以用 鏡像名 ,也就是 <倉庫名>:< 標籤 > ,來刪除鏡像。
$ docker image rm centos
Untagged: centos:latest
Untagged: centos@sha256:b2f9d1c0ff5f87a4743104d099a3d561002ac500db1b9bfa02a783a46e0d366c
Deleted: sha256:0584b3d2cf6d235ee310cf14b54667d889887b838d3f3d3033acd70fc3c48b8a
Deleted: sha256:97ca462ad9eeae25941546209454496e1d66749d53dfa2ee32bf1faabd239d38
當然,更精確的是使用 鏡像摘要 刪除鏡像。
$ docker image ls --digests
REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE
node slim sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228 6e0c4c8e3913 3 weeks ago 214 MB
$ docker image rm node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
Untagged: node@sha256:b4f0e0bdeb578043c1ea6862f0d40cc4afe32a4a582f3be235a3b164422be228
3.3.2 Untagged 和 Deleted
如果觀察上面這幾個命令的運行輸出信息的話,你會注意到刪除行爲分爲兩類,一類是 Untagged,另一類是 Deleted。我們之前介紹過,鏡像的唯一標識是其 ID 和摘要,而一個鏡像可以有多個標籤。
因此當我們使用上面命令刪除鏡像的時候,實際上是在要求刪除某個標籤的鏡像。所以首先需要做的是將滿足我們要求的所有鏡像標籤都取消,這就是我們看到的 Untagged 的信息。因爲一個鏡像可以對應多個標籤,因此當我們刪除了所指定的標籤後,可能還有別的標籤指向了這個鏡像,如果是這種情況,那麼 Delete 行爲就不會發生。所以並非所有的 docker image rm 都會產生刪除鏡像的行爲,有可能僅僅是取消了某個標籤而已。
當該鏡像所有的標籤都被取消了,該鏡像很可能會失去了存在的意義,因此會觸發刪除行爲。鏡像是多層存儲結構,因此在刪除的時候也是從上層向基礎層方向依次進行判斷刪除。鏡像的多層結構讓鏡像複用變動非常容易,因此很有可能某個其它鏡像正依賴於當前鏡像的某一層。這種情況,依舊不會觸發刪除該層的行爲。直到沒有任何層依賴當前層時,纔會真實的刪除當前層。這就是爲什麼,有時候會奇怪,爲什麼明明沒有別的標籤指向這個鏡像,但是它還是存在的原因,也是爲什麼有時候會發現所刪除的層數和自己 docker pull 看到的層數不一樣的源。
除了鏡像依賴以外,還需要注意的是容器對鏡像的依賴。如果有用這個鏡像啓動的容器存在(即使容器沒有運行),那麼同樣不可以刪除這個鏡像。之前講過,容器是以鏡像爲基礎,再加一層容器存儲層,組成這樣的多層存儲結構去運行的。因此該鏡像如果被這個容器所依賴的,那麼刪除必然會導致故障。如果這些容器是不需要的,應該先將它們刪除,然後再來刪除鏡像。
3.3.3 用 docker image ls 命令來配合
像其它可以承接多個實體的命令一樣,可以使用 docker image ls -q 來配合使用 docker image rm ,這樣可以成批的刪除希望刪除的鏡像。我們在 “鏡像列表” 章節介紹過很多過濾鏡像列表的方式都可以拿過來使用。
比如,我們需要刪除所有倉庫名爲 redis 的鏡像:
docker image rm $(docker image ls -q redis)
或者刪除所有在 mongo:3.2 之前的鏡像:
docker image rm $(docker image ls -q -f before=mongo:3.2)
充分利用你的想象力和 Linux 命令行的強大,你可以完成很多非常讚的功能。
3.3.4 CentOS/RHEL 的用戶需要注意的事項
在 Ubuntu/Debian 上有 UnionFS 可以使用,如 aufs 或者 overlay2,而 CentOS 和 RHEL 的內核中沒有相關驅動。因此對於這類系統,一般使用 devicemapper 驅動利用 LVM 的一些機制來模擬分層存儲。這樣的做法除了性能比較差外,穩定性一般也不好,而且配置相對複雜。
Docker 安裝在 CentOS/RHEL 上後,會默認選擇 devicemapper,但是爲了簡化配置,其 devicemapper 是跑在一個稀疏文件模擬的塊設備上,也被稱爲 loop-lvm。這樣的選擇是因爲不需要額外配置就可以運行 Docker,這是自動配置唯一能做到的事情。但是 loop-lvm 的做法非常不好,其穩定性、性能更差,無論是日誌還是 docker info 中都會看到警告信息。官方文檔有明確的文章講解了如何配置塊設備給 devicemapper 驅動做存儲層的做法,這類做法也被稱爲配置 direct-lvm。
除了前面說到的問題外,devicemapper + loop-lvm 還有一個缺陷,因爲它是稀疏文件,所以它會不斷增長。用戶在使用過程中會注意到 /var/lib/docker/devicemapper/devicemapper/data 不斷增長,而且無法控制。很多人會希望刪除鏡像或者可以解決這個問題,結果發現效果並不明顯。原因就是這個稀疏文件的空間釋放後基本不進行垃圾回收的問題。因此往往會出現即使刪除了文件內容,空間卻無法回收,隨着使用這個稀疏文件一直在不斷增長。
所以對於 CentOS/RHEL 的用戶來說,在沒有辦法使用 UnionFS 的情況下,一定要配置 direct-lvm 給 devicemapper,無論是爲了性能、穩定性還是空間利用率。
或許有人注意到了 CentOS 7 中存在被 backports 回來的 overlay 驅動,不過 CentOS 裏的這個驅動達不到生產環境使用的穩定程度,所以不推薦使用。
讀到這裏,想必你知道如何的安裝 Docker,以及瞭解了 Docker 非常重要的鏡像。
作者 | 微楓 Micromaple
來源 | CSDN 博客
傑哥的 IT 之旅
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/Rw5oFeqayeV0c4IeGqUxIQ