大家好,本文是對 Docker 鏡像的詳細講解,講解了如何安裝 Docker、配置 Docker 鏡像加速以及操作 Docker 鏡像。希望對大家有所幫助~
Docker 要求 CentOS 系統(tǒng)的內核版本高于 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
系統(tǒng)要求
Docker CE 支持以下版本的 Ubuntu 操作系統(tǒng):
Artful 17.10 (Docker CE 17.11 Edge +)
Xenial 16.04 (LTS)
Trusty 14.04 (LTS)
Docker CE 可以安裝在 64 位的 x86平臺或 ARM 平臺上。Ubuntu 發(fā)行版中,LTS(Long-Term-Support)長期支持版本,會獲得 5 年的升級維護支持,這樣的版本會更穩(wěn)定,因此在生產環(huán)境中推薦使用 LTS 版本,當前最新的 LTS 版本為 Ubuntu 16.04。
卸載舊版本
舊版本的 Docker 稱為 docker 或者 docker-engine,使用以下命令卸載舊版本:
sudo apt-get remove docker \
docker-engine \
docker.io
使用腳本自動安裝
在測試或開發(fā)環(huán)境中 Docker 官方為了簡化安裝流程,提供了一套便捷的安裝腳本,Ubuntu 系統(tǒng)上可以使用這套安裝腳本:
curl -fsSL get.docker.com -o get-docker.sh
sudo sh get-docker.sh --mirror AzureChinaCloud
執(zhí)行這個命令后,腳本就會自動的將一切準備工作做好,并且把 Docker CE 的 Edge 版本安裝在系統(tǒng)中
啟動 Docker CE
sudo systemctl enable docker
sudo systemctl start docker
卸載 Docker
先執(zhí)行命令:apt-get autoremove docker-ce
刪除 /etc/apt/sources.list.d 目錄下的 docker.list 文件
國內從 Docker Hub 拉取鏡像有時會遇到困難,此時可以配置鏡像加速器。Docker 官方和國內很多云服務商都提供了國內加速器服務,例如:
Docker 官方提供的中國 registry mirror
阿里云加速器
DaoCloud 加速器
我們以Docker阿里云加速器為例進行介紹。
首先登錄阿里云(沒有賬號請先注冊),搜索 容器鏡像服務,找到你的專屬加速器地址。
對于使用 upstart 的系統(tǒng)而言,編輯 /etc/default/docker 文件,在其中的 DOCKER_OPTS 中配置加速器地址:
DOCKER_OPTS='--registry-mirror=https://xxxxxxxx.mirror.aliyuncs.com'
重新啟動服務。
sudo service docker restart
對于使用 systemd 的系統(tǒng),請在 /etc/docker/daemon.json 中寫入如下內容(如果文件不存在請新建該文件)
{
'registry-mirrors': [
'https://xxxxxxxx.mirror.aliyuncs.com'
]
}
注意,一定要保證該文件符合 json 規(guī)范,否則 Docker 將不能啟動。
之后重新啟動服務。
sudo systemctl daemon-reload
sudo systemctl restart docker
對于使用 Windows 10 的系統(tǒng),在系統(tǒng)右下角托盤 Docker 圖標內右鍵菜單選擇 Settings ,打開配置窗口后左側導航菜單選擇 Daemon 。在 Registry mirrors 一欄中填寫加速器地址 https://registry.docker-cn.com ,之后點擊 Apply 保存后 Docker 就會重啟并應用配置的鏡像地址了。
對于使用 macOS 的用戶,在任務欄點擊 Docker for mac 應用圖標 -> Perferences… -> Daemon -> Registry mirrors。在列表中填寫加速器地址 https://registry.docker-cn.com 。修改完成之后,點擊 Apply & Restart 按鈕,Docker 就會重啟并應用配置的鏡像地址了。
配置加速器之后,如果拉取鏡像仍然十分緩慢,請手動檢查加速器配置是否生效,在命令行執(zhí)行 docker info ,如果從結果中看到了如下內容,說明配置成功。
Registry Mirrors:
https://xxxxxxxx.mirror.aliyuncs.com
之前提到過,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 的摘要,以確保下載一致性。
在使用上面命令的時候,你可能會發(fā)現(xiàn),你所看到的層 ID 以及 sha256 的摘要和這里不一樣。這是因為官方鏡像是一致在維護的,有任何新的 bug,或者版本更新,都會進行修復再以原來的標簽發(fā)布,這樣可有確保任何使用這個標簽的用戶可以獲得更安全、更穩(wěn)定的鏡像。
如果從 Docker Hub 下載鏡像非常緩慢,可以參照 鏡像加速器 一節(jié)配置加速器。
有了鏡像后,我們就能夠以這個鏡像為基礎啟動并運行一個容器。以上面的 ubuntu:16.04 為例,如果我們打算啟動里面的 bash 并且進行交互式操作的話,可以執(zhí)行下面的命令。
$ docker run -it --rm \
ubuntu:16.04 \
bash
root@e7009c6ce357:/# cat /etc/os-release
NAME='Ubuntu'
VERSION='16.04.4 LTS, Trusty Tahr'
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME='Ubuntu 16.04.4 LTS'
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 就是運行容器的命令,我們這里簡要的說明一下上面用到的參數(shù)。
it :這是兩個參數(shù),一個是 -i :交互式操作,一個是 -t 終端。我們這里打算進入 bash 執(zhí)行一些命令并查看返回結果,因此我們需要交互式終端。
--rm :這個參數(shù)是說容器退出后隨之將其刪除。默認情況下,為了排障需求,退出的容器并不會立即刪除,除非手動 docker rm 。我們這里只是隨便執(zhí)行個命令,看看結果,不需要排障和保留結果,因此使用 --rm 可以避免浪費空間。
ubuntu:16.04 :這是指用 ubuntu:16.04 鏡像為基礎來啟動容器。
bash :放在鏡像名后的是命令,這里我們希望有個交互式 Shell,因此用的是 bash。
進入容器后,我們可以在 Shell 下操作,執(zhí)行任何所需的命令。這里,我們執(zhí)行了 cat /etc/os-release ,這是 Linux 常用的查看當前系統(tǒng)版本的命令,從返回的結果可以看到容器內是 Ubuntu 16.04.4 LTS 系統(tǒng)。
最后們通過 exit 或者 Ctrl + D 退出了這個容器。
要想列出已經下載下來的鏡像,可以使用 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、創(chuàng)建時間、以及所占用的空間。
其中倉庫名、標簽在之前的基礎概念已經介紹過了。鏡像 ID 則是鏡像的唯一標識,一個鏡像可以對應多個標簽。因此,在上面的例子中,我們可以看到 ubuntu:16.04 和 ubuntu:latest 擁有相同的 ID,因為它們對應的是同一個鏡像。
如果仔細觀察,會注意到,這里標識的所占用空間和在 Docker Hub 上看到的鏡像大小不同。比如, ubuntu:16.04 鏡像大小,在這里是 127MB ,但是在 Docker Hub 顯示的卻是 50MB 。這是因為 Docker Hub 中顯示的體積是壓縮后的體積。在鏡像下載和上傳過程中鏡像是保持著壓縮狀態(tài)的,因此 Docker Hub 所顯示的是鏡像下載到本地后,展開的大小,準確說,是展開后的各層所占空間的總和,因為鏡像到本地后,查看空間的時候,更關心的是本地磁盤空間占用的大小。
另外一個需要注意的問題是, docker image ls 列表中的鏡像體積總和并非是所有鏡像實際硬盤消耗,由于 Docker 鏡像是多層存儲結構,并且可以繼承、復用,因此不同鏡像可能會因為使用相同的基礎鏡像,從而擁有共同的層。由于 Docker 使用 Union FS,相同的層只需要保存一份即可,因此實際鏡像硬盤占用空間很可能要比這個列表鏡像大小的總和要小的多。
你可以通過以下命令來便捷的查看鏡像、容器、數(shù)據(jù)卷所占用空間。
$ 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
尚明的鏡像列表中,還可以看到一個特殊的鏡像,這個鏡像既沒有倉庫名,也沒有標簽,均為
<none> <none> 00285df0df87 5 days ago 342 MB
這個鏡像原本是有鏡像名和標簽的,原來為 mongo:3.2,隨著官方鏡像維護,發(fā)布了新版本后,重新 docker pull mongo:3.2 時, mongo:3.2 這個鏡像名被轉移到了新下載的鏡像身上,而舊的鏡像上的這個名稱則被取消,從而成為了
$ docker image ls -f dangling=true
REPOSITORY TAG IMAGE ID CREATED SIZE
<none> <none> 00285df0df87 5 days ago 342 MB
一般來說,虛懸鏡像已經失去了存在的價值,是可以隨意刪除的,可以用下面的命令刪除。
$ docker image prune
為了加速鏡像構建、重復利用資源,Docker 會利用 中間層鏡像。所以在使用一段時間后,可能會看到一些依賴的中間層鏡像。默認的 docker image ls 列表中只會顯示頂層鏡像,如果希望顯示包括中間層鏡像在內的所有鏡像的話,需要加 -a 參數(shù)。
$ docker image ls -a
這樣會看到很多無標簽的鏡像,與之前的虛懸鏡像不同,這些無標簽的鏡像很多都是中間層鏡像,是其他鏡像所依賴的鏡像。這些無標簽鏡像不應該刪除,否者會導致上層鏡像因為依賴丟失而出錯。實際上,這些鏡像也沒必要刪除,因為之前說過,相同的層只會存一遍,而這些鏡像是別的鏡像的依賴,因此并不會因為它們被列出來而多存了一份,無論如何你也會需要它們。只要刪除那些依賴它們的鏡像后,這些依賴的中間層鏡像也會被連帶刪除。
不加任何參數(shù)的情況下,docker image ls 會列出所有頂級鏡像,但是有時候我們只希望列出部分鏡像。docker iimage ls 有好幾個參數(shù)可以幫助做到這個事情。
根據(jù)倉庫名列出鏡像
$ 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 還支持強大的過濾器參數(shù) --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
...
默認情況下, docker image ls 會輸出一個完整的表格,但是我們并非所有時候都會需要這些內容。比如,剛才刪除虛懸鏡像的時候,我們需要利用 docker image ls 把所有的虛懸鏡像的 ID 列出來,然后才可以交給 docker image rm 命令作為參數(shù)來刪除指定的這些鏡像,這個時候就用到了 -q 參數(shù)。
$ docker image ls -q
5f515359c7f8
05a60462f8ba
fe9198c04d62
00285df0df87
f753707788c5
f753707788c5
1e0c3dd64ccd
--filter 配合 -q 產生出指定范圍的 ID 列表,然后送給另一個 docker 命令作為參數(shù),從而針對這組實體成批的進行某種操作的做法在 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}}'
如果想要刪除本地的鏡像,可以使用 docker image rm 命令,其格式為:
docker image rm [選項] <鏡像1> [<鏡像2> ...]
其中, <鏡像> 可以是 鏡像短 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 個字符以上,只要足夠區(qū)分于別的鏡像就可以了。
比如這里,如果我們要刪除 redis:alpine 鏡像,可以執(zhí)行:
$ 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
如果觀察上面這幾個命令的運行輸出信息的話,你會注意到刪除行為分為兩類,一類是 Untagged,另一類是 Deleted。我們之前介紹過,鏡像的唯一標識是其 ID 和摘要,而一個鏡像可以有多個標簽。
因此當我們使用上面命令刪除鏡像的時候,實際上是在要求刪除某個標簽的鏡像。所以首先需要做的是將滿足我們要求的所有鏡像標簽都取消,這就是我們看到的 Untagged 的信息。因為一個鏡像可以對應多個標簽,因此當我們刪除了所指定的標簽后,可能還有別的標簽指向了這個鏡像,如果是這種情況,那么 Delete 行為就不會發(fā)生。所以并非所有的 docker image rm 都會產生刪除鏡像的行為,有可能僅僅是取消了某個標簽而已。
當該鏡像所有的標簽都被取消了,該鏡像很可能會失去了存在的意義,因此會觸發(fā)刪除行為。鏡像是多層存儲結構,因此在刪除的時候也是從上層向基礎層方向依次進行判斷刪除。鏡像的多層結構讓鏡像復用變動非常容易,因此很有可能某個其它鏡像正依賴于當前鏡像的某一層。這種情況,依舊不會觸發(fā)刪除該層的行為。直到沒有任何層依賴當前層時,才會真實的刪除當前層。這就是為什么,有時候會奇怪,為什么明明沒有別的標簽指向這個鏡像,但是它還是存在的原因,也是為什么有時候會發(fā)現(xiàn)所刪除的層數(shù)和自己 docker pull 看到的層數(shù)不一樣的源。
除了鏡像依賴以外,還需要注意的是容器對鏡像的依賴。如果有用這個鏡像啟動的容器存在(即使容器沒有運行),那么同樣不可以刪除這個鏡像。之前講過,容器是以鏡像為基礎,再加一層容器存儲層,組成這樣的多層存儲結構去運行的。因此該鏡像如果被這個容器所依賴的,那么刪除必然會導致故障。如果這些容器是不需要的,應該先將它們刪除,然后再來刪除鏡像。
像其它可以承接多個實體的命令一樣,可以使用 docker image ls -q 來配合使用 docker image rm ,這樣可以成批的刪除希望刪除的鏡像。我們在 “鏡像列表”章節(jié)介紹過很多過濾鏡像列表的方式都可以拿過來使用。
比如,我們需要刪除所有倉庫名為 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 命令行的強大,你可以完成很多非常贊的功能。
在 Ubuntu/Debian 上有 UnionFS 可以使用,如 aufs 或者 overlay2,而 CentOS 和 RHEL 的內核中沒有相關驅動。因此對于這類系統(tǒng),一般使用 devicemapper 驅動利用 LVM 的一些機制來模擬分層存儲。這樣的做法除了性能比較差外,穩(wěn)定性一般也不好,而且配置相對復雜。
Docker 安裝在 CentOS/RHEL 上后,會默認選擇 devicemapper,但是為了簡化配置,其 devicemapper 是跑在一個稀疏文件模擬的塊設備上,也被稱為 loop-lvm。這樣的選擇是因為不需要額外配置就可以運行 Docker,這是自動配置唯一能做到的事情。但是 loop-lvm 的做法非常不好,其穩(wěn)定性、性能更差,無論是日志還是 docker info 中都會看到警告信息。官方文檔有明確的文章講解了如何配置塊設備給 devicemapper 驅動做存儲層的做法,這類做法也被稱為配置 direct-lvm。
除了前面說到的問題外,devicemapper + loop-lvm 還有一個缺陷,因為它是稀疏文件,所以它會不斷增長。用戶在使用過程中會注意到 /var/lib/docker/devicemapper/devicemapper/data 不斷增長,而且無法控制。很多人會希望刪除鏡像或者可以解決這個問題,結果發(fā)現(xiàn)效果并不明顯。原因就是這個稀疏文件的空間釋放后基本不進行垃圾回收的問題。因此往往會出現(xiàn)即使刪除了文件內容,空間卻無法回收,隨著使用這個稀疏文件一直在不斷增長。
所以對于 CentOS/RHEL 的用戶來說,在沒有辦法使用 UnionFS 的情況下,一定要配置 direct-lvm 給 devicemapper,無論是為了性能、穩(wěn)定性還是空間利用率。
或許有人注意到了 CentOS 7 中存在被 backports 回來的 overlay 驅動,不過 CentOS 里的這個驅動達不到生產環(huán)境使用的穩(wěn)定程度,所以不推薦使用。
讀到這里,想必你知道如何的安裝Docker,以及了解了Docker非常重要的鏡像。