銀河麒麟服務(wù)器操作系統(tǒng)運(yùn)維實(shí)踐 課件 19.-2 Docker容器安裝與部署

Docker虛擬化篇Docker核心組件Docker底層管理Docker原理與安裝overlay2

UFS與AUFSDocker鏡像應(yīng)用Docker的特性本章目標(biāo)◆了解Docker底層架構(gòu)原理◆掌握Docker虛擬化名字空間的特性，以及不同名字空間的作用◆掌握Docker的安裝◆了解Docker鏡像的概念，掌握Docker鏡像的管理與維護(hù)◆了解Docker容器的概念，掌握Docker容器的管理與維護(hù)Docker底層原理LinuxNamespaces機(jī)制提供一種資源隔離方案。PID、IPC、Network等系統(tǒng)資源不再是全局性的，而是屬于某個(gè)特定的Namespace。每個(gè)namespace下的資源對(duì)于其他namespace下的資源都是透明，不可見的。因此在操作系統(tǒng)層面上看，就會(huì)出現(xiàn)多個(gè)相同pid的進(jìn)程。Namespace介紹Linux內(nèi)核實(shí)現(xiàn)Namespace的主要目的之一是實(shí)現(xiàn)輕量級(jí)虛擬化（容器）服務(wù)。再此之前，Linux中很多資源是全局管理。命名空間建立系統(tǒng)的不同視圖，對(duì)于每一個(gè)命名空間，從用戶看起來(lái)，應(yīng)該像一臺(tái)單獨(dú)的Linux計(jì)算機(jī)一樣，有自己的init進(jìn)程(PID為0)，其他進(jìn)程的PID依次遞增，A和B空間都有PID為0的init進(jìn)程，子容器的進(jìn)程映射到父容器的進(jìn)程上，父容器可以知道每一個(gè)子容器的運(yùn)行狀態(tài)，而子容器與子容器之間是隔離的。Namespace介紹想要實(shí)現(xiàn)一個(gè)資源隔離的容器，需要6項(xiàng)隔離，Linux內(nèi)核提供了這6種Namespace隔離的系統(tǒng)調(diào)用，在同一個(gè)Namespace下的進(jìn)程可以感知彼此的變化，但不了解外界的變化，因此，可以讓容器中的進(jìn)程以為自己在一個(gè)獨(dú)立的系統(tǒng)環(huán)境中，達(dá)到獨(dú)立和隔離的目的。Linux提供了多個(gè)API用來(lái)操作Namespace，它們是clone()、setns()和unshare()函數(shù)?！鬰lone()：創(chuàng)建新進(jìn)程，flags參數(shù)可以用來(lái)創(chuàng)建新的namespace◆setns()：讓進(jìn)程加入存在的namespace◆unshare()：將調(diào)用進(jìn)程移動(dòng)到新的namespace中Namespace介紹同時(shí)我們還可以通過(guò)/proc下面的一些文件來(lái)操作Namespace。首先通過(guò)systemctlstatusdocker獲取到pid查看進(jìn)程所屬的Namespace：從版本號(hào)為3.8的內(nèi)核開始，/proc/[pid]/ns目錄下會(huì)包含進(jìn)程所屬的namespace信息，使用下面的命令可以查看當(dāng)前進(jìn)程所屬的namespace信息：ls–l/proc/[PID]/nsNamespace介紹pid名字空間不同用戶的進(jìn)程就是通過(guò)pid名字空間隔離開的，且不同名字空間中可以有相同pid。所有的LXC進(jìn)程在Docker中的父進(jìn)程為Docker進(jìn)程，每個(gè)LXC進(jìn)程具有不同的名字空間。同時(shí)由于允許嵌套，因此可以很方便的實(shí)現(xiàn)嵌套的Docker容器。net名字空間有了pid名字空間,每個(gè)名字空間中的pid能夠相互隔離，但是網(wǎng)絡(luò)端口還是共享host的端口。網(wǎng)絡(luò)隔離是通過(guò)net名字空間實(shí)現(xiàn)的，每個(gè)net名字空間有獨(dú)立的網(wǎng)絡(luò)設(shè)備,IP地址,路由表,/proc/net目錄。這樣每個(gè)容器的網(wǎng)絡(luò)就能隔離開來(lái)。Docker默認(rèn)采用veth的方式，將容器中的虛擬網(wǎng)卡同host上的一個(gè)Docker網(wǎng)橋docker0連接在一起。ipc名字空間容器中進(jìn)程交互還是采用了Linux常見的進(jìn)程間交互方法(interprocesscommunication-IPC),包括信號(hào)量、消息隊(duì)列和共享內(nèi)存等。然而同VM不同的是，容器的進(jìn)程間交互實(shí)際上還是host上具有相同pid名字空間中的進(jìn)程間交互，因此需要在IPC資源申請(qǐng)時(shí)加入名字空間信息，每個(gè)IPC資源有一個(gè)唯一的32位id。mnt名字空間類似chroot，將一個(gè)進(jìn)程放到一個(gè)特定的目錄執(zhí)行。mnt名字空間允許不同名字空間的進(jìn)程看到的文件結(jié)構(gòu)不同，這樣每個(gè)名字空間中的進(jìn)程所看到的文件目錄就被隔離開了。同chroot不同，每個(gè)名字空間中的容器在/proc/mounts的信息只包含所在名字空間的mountpoint。uts名字空間UTS(“UNIXTime-sharingSystem”)名字空間允許每個(gè)容器擁有獨(dú)立的hostname和domainname,使其在網(wǎng)絡(luò)上可以被視作一個(gè)獨(dú)立的節(jié)點(diǎn)而非主機(jī)上的一個(gè)進(jìn)程。user名字空間每個(gè)容器可以有不同的用戶和組id,也就是說(shuō)可以在容器內(nèi)用容器內(nèi)部的用戶執(zhí)行程序而非主機(jī)上的用戶。Docker底層原理-cgroupscgroups是Linux內(nèi)核提供的一種可以限制單個(gè)進(jìn)程或者多個(gè)進(jìn)程所使用資源的機(jī)制，可以對(duì)cpu，內(nèi)存等資源實(shí)現(xiàn)精細(xì)化的控制，目前越來(lái)越火的輕量級(jí)容器Docker就使用了cgroups提供的資源限制能力來(lái)完成cpu，內(nèi)存等部分的資源控制。另外，開發(fā)者也可以使用cgroups提供的精細(xì)化控制能力，限制某一個(gè)或者某一組進(jìn)程的資源使用。cgroups概念及原理cgroups的全稱是controlgroups，cgroups為每種可以控制的資源定義了一個(gè)子系統(tǒng)。典型的子系統(tǒng)介紹如下：

◆

cpu子系統(tǒng)，主要限制進(jìn)程的cpu使用率。

◆

cpuacct子系統(tǒng)，可以統(tǒng)計(jì)cgroups中的進(jìn)程的cpu使用報(bào)告。

◆

cpuset子系統(tǒng)，可以為cgroups中的進(jìn)程分配單獨(dú)的cpu節(jié)點(diǎn)或者內(nèi)存節(jié)點(diǎn)。

◆

memory子系統(tǒng)，可以限制進(jìn)程的memory使用量。

◆

blkio子系統(tǒng)，可以限制進(jìn)程的塊設(shè)備io。

◆

devices子系統(tǒng)，可以控制進(jìn)程能夠訪問(wèn)某些設(shè)備。

◆

net_cls子系統(tǒng)，可以標(biāo)記cgroups中進(jìn)程的網(wǎng)絡(luò)數(shù)據(jù)包，然后可以使用tc模塊對(duì)數(shù)據(jù)包進(jìn)行控制。

◆

freezer子系統(tǒng)，可以掛起或者恢復(fù)cgroups中的進(jìn)程。

◆

ns子系統(tǒng)，可以使不同cgroups下面的進(jìn)程使用不同的namespace。cgroups層級(jí)結(jié)構(gòu)（Hierarchy）內(nèi)核使用cgroup結(jié)構(gòu)體來(lái)表示一個(gè)controlgroup對(duì)某一個(gè)或者某幾個(gè)cgroups子系統(tǒng)的資源限制。cgroup結(jié)構(gòu)體可以組織成一顆樹的形式，每一棵cgroup結(jié)構(gòu)體組成的樹稱之為一個(gè)cgroups層級(jí)結(jié)構(gòu)。cgroups層級(jí)結(jié)構(gòu)可以包含一個(gè)或者幾個(gè)cgroups子系統(tǒng)，當(dāng)前層級(jí)結(jié)構(gòu)可以對(duì)其attach的cgroups子系統(tǒng)進(jìn)行資源的限制。cgroups層級(jí)結(jié)構(gòu)（Hierarchy）上面提到了內(nèi)核使用cgroups子系統(tǒng)對(duì)系統(tǒng)的資源進(jìn)行限制，也提到了cgroups子系統(tǒng)需要attach到cgroups層級(jí)結(jié)構(gòu)中來(lái)對(duì)進(jìn)程進(jìn)行資源控制。下面我們來(lái)看一下內(nèi)核是如何把進(jìn)程與cgroups層級(jí)結(jié)構(gòu)聯(lián)系起來(lái)的。在創(chuàng)建了cgroups層級(jí)結(jié)構(gòu)中的節(jié)點(diǎn)（cgroup結(jié)構(gòu)體）之后，可以把進(jìn)程加入到某一個(gè)節(jié)點(diǎn)的控制任務(wù)列表中，一個(gè)節(jié)點(diǎn)的控制列表中的所有進(jìn)程都會(huì)受到當(dāng)前節(jié)點(diǎn)的資源限制。同時(shí)某一個(gè)進(jìn)程也可以被加入到不同的cgroups層級(jí)結(jié)構(gòu)的節(jié)點(diǎn)中，因?yàn)椴煌腸groups層級(jí)結(jié)構(gòu)可以負(fù)責(zé)不同的系統(tǒng)資源。所以說(shuō)進(jìn)程和cgroup結(jié)構(gòu)體是一個(gè)多對(duì)多的關(guān)系。cgroups層級(jí)結(jié)構(gòu)（Hierarchy）cgroups文件系統(tǒng)Linux使用了多種數(shù)據(jù)結(jié)構(gòu)在內(nèi)核中實(shí)現(xiàn)了cgroups的配置，關(guān)聯(lián)了進(jìn)程和cgroups節(jié)點(diǎn)。Linux內(nèi)核有一個(gè)很強(qiáng)大的模塊叫VFS(VirtualFileSystem)。VFS能夠把具體文件系統(tǒng)的細(xì)節(jié)隱藏起來(lái)，給用戶態(tài)進(jìn)程提供一個(gè)統(tǒng)一的文件系統(tǒng)API接口。cgroups也是通過(guò)VFS把功能暴露給用戶態(tài)的，cgroups與VFS之間的銜接部分稱之為cgroups文件系統(tǒng)。VFS是一個(gè)內(nèi)核抽象層，能夠隱藏具體文件系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)，從而給用戶態(tài)進(jìn)程提供一套統(tǒng)一的API接口。VFS使用了一種通用文件系統(tǒng)的設(shè)計(jì)，具體的文件系統(tǒng)只要實(shí)現(xiàn)了VFS的設(shè)計(jì)接口，就能夠注冊(cè)到VFS中，從而使內(nèi)核可以讀寫這種文件系統(tǒng)。UnionFSUnionFS是一種為L(zhǎng)inux，F(xiàn)reeBSD和NetBSD操作系統(tǒng)設(shè)計(jì)的把其他文件系統(tǒng)聯(lián)合到一個(gè)聯(lián)合掛載點(diǎn)的文件系統(tǒng)服務(wù)。它使用branch把不同文件系統(tǒng)的文件和目錄“透明地”覆蓋，形成一個(gè)單一一致的文件系統(tǒng)。這些branches或者是read-only或者是read-write的，所以當(dāng)對(duì)這個(gè)虛擬后的聯(lián)合文件系統(tǒng)進(jìn)行寫操作的時(shí)候，系統(tǒng)是真正寫到了一個(gè)新的文件中?？雌饋?lái)這個(gè)虛擬后的聯(lián)合文件系統(tǒng)是可以對(duì)任何文件進(jìn)行操作的，但是其實(shí)它并沒(méi)有改變?cè)瓉?lái)的文件，這是因?yàn)閡nionfs用到了一個(gè)重要的資管管理技術(shù)叫寫時(shí)復(fù)制。Docker原理與安裝04Docker工作流程Docker采用了C/S架構(gòu)，包括客戶端和服務(wù)端。Dockerdaemon作為服務(wù)端接受來(lái)自客戶的請(qǐng)求，并處理這些請(qǐng)求（創(chuàng)建、運(yùn)行、分發(fā)容器）?？蛻舳撕头?wù)端既可以運(yùn)行在一個(gè)機(jī)器上，也可通過(guò)socket或者RESTfulAPI來(lái)進(jìn)行通信。Docker工作流程dockerdaemon一般在宿主主機(jī)后臺(tái)運(yùn)行，等待接收來(lái)自客戶端的消息。Docker客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實(shí)現(xiàn)跟Dockerdaemon交互。容器-鏡像-倉(cāng)庫(kù)-daemon-client之間的關(guān)系Docker安裝卸載舊版本[root@kylinos~]#yumremovedocker安裝docker[root@kylinos~]#yuminstalldocker啟動(dòng)docker[root@kylinos~]#systemctlstartdocker開機(jī)自啟[root@kylinos~]#systemctlenabledocker驗(yàn)證啟動(dòng)[root@kylinos~]#systemctlstatusdockerDocker鏡像加速國(guó)內(nèi)從DockerHub拉取鏡像有時(shí)會(huì)遇到困難，此時(shí)可以配置鏡像加速器。Docker官方和國(guó)內(nèi)很多云服務(wù)商都提供了國(guó)內(nèi)加速器服務(wù)，例如：科大鏡像：/網(wǎng)易：/七牛云加速器：mkdir/etc/dockervim/etc/docker/daemon.json(如果文件不存在則創(chuàng)建){"registry-mirrors":["/"]}##配置完后還要對(duì)服務(wù)進(jìn)行重啟systemctlrestartdockerDockerEngineDocker生態(tài)已經(jīng)遠(yuǎn)比它誕生之初要龐大許多，目前這款實(shí)現(xiàn)容器化的工具是由Docker官方進(jìn)行維護(hù)的，Docker官方將其命名為DockerEngine，同時(shí)定義其為工業(yè)級(jí)的容器引擎。在DockerEngine中，實(shí)現(xiàn)了Docker技術(shù)中最核心的部分，也就是容器引擎這一部分。雖然DockerEngine是一款軟件，但其實(shí)算是由多個(gè)獨(dú)立軟件所組成的軟件包。在這些程序中，最核心的就是dockerdaemon和dockerCLI。DockerDaemonDockerdaemon：所有通常認(rèn)為的Docker所能提供的容器管理、應(yīng)用編排、鏡像分發(fā)等功能，都集中在了dockerdaemon中，而之前所提到的鏡像模塊、容器模塊、數(shù)據(jù)卷模塊和網(wǎng)絡(luò)模塊也都實(shí)現(xiàn)在其中。在操作系統(tǒng)里，dockerdaemon通常以服務(wù)的形式運(yùn)行以便靜默的提供這些功能，所以也通常稱之為Docker服務(wù)。DockerclientDockerclient：Dockerclient是一個(gè)泛稱，用來(lái)向Dockerdaemon發(fā)起請(qǐng)求，執(zhí)行相應(yīng)的容器管理操作。它既可以是命令行工具docker，也可以是任何遵循了DockerAPI的客戶端。在dockerdaemon管理容器等相關(guān)資源的同時(shí)，它也向外暴露了一套R(shí)ESTfulAPI，能夠通過(guò)這套接口對(duì)dockerdaemon進(jìn)行操作。dockerdaemon和dockerCLI所組成的，是一個(gè)標(biāo)準(zhǔn)C/S結(jié)構(gòu)的應(yīng)用程序。銜接這兩者的，正是dockerdaemon所提供的這套R(shí)ESTfulAPI。Client與Daemon分離作為Docker容器管理的守護(hù)進(jìn)程，DockerDaemon從最初集成在docker命令中（1.11版本前），到后來(lái)的獨(dú)立成單獨(dú)二進(jìn)制程序（1.11版本開始），其功能正在逐漸拆分細(xì)化，被分配到各個(gè)單獨(dú)的模塊中去。從Docker服務(wù)的啟動(dòng)腳本，也能看見守護(hù)進(jìn)程的逐漸剝離。課程小結(jié)課后練習(xí)◆簡(jiǎn)述Docker虛擬化的特性◆描述Docker基本架構(gòu)原理◆簡(jiǎn)述Docker名字空間的作用，包括pid、net、ipc、mnt、uts和user◆

部署Docker虛擬化環(huán)境UFS與AUFS05UnionFileSystemUnionFileSystem，簡(jiǎn)稱UnionFS，是一種為L(zhǎng)inux、FreeBSD和NetBSD操作系統(tǒng)設(shè)計(jì)的文件系統(tǒng)，它能夠多個(gè)其他文件系統(tǒng)聯(lián)合到一個(gè)地方來(lái)掛載。換句話說(shuō)，就是多個(gè)目錄合并mount到同一個(gè)目錄中。它和核心原理有兩個(gè)：

分支管理：它使用branch把不同文件系統(tǒng)的文件和目錄"透明地"覆蓋，形成一個(gè)單一一致的文件系統(tǒng)。這些branch或者是read-only的，或者是read-write的，所以當(dāng)對(duì)這個(gè)虛擬后的聯(lián)合文件系統(tǒng)進(jìn)行寫操作的時(shí)候，系統(tǒng)是真正寫到了一個(gè)新的文件中。

寫時(shí)復(fù)制：copy-on-write，簡(jiǎn)寫為CoW，也叫隱式共享，是一種提高資源使用效率的資源管理技術(shù)。UnionFileSystem寫時(shí)復(fù)制的思想：如果一個(gè)資源是重復(fù)的，在沒(méi)有對(duì)資源做出修改前，并不需要立即復(fù)制出一個(gè)新的資源實(shí)例，這個(gè)資源被不同的所有者共享使用。當(dāng)任何一個(gè)所有者要對(duì)該資源做出修改時(shí)，復(fù)制出一個(gè)新的資源實(shí)例給該所有者進(jìn)行修改，修改后的資源成為其所有者的私有資源。通過(guò)這種資源共享的方式，可以顯著地減少?gòu)?fù)制相同資源帶來(lái)的消耗，但是這樣做也會(huì)在進(jìn)行資源的修改時(shí)增加一部分開銷。AUFS的概念A(yù)UFS又叫AnotherUnionFS，后來(lái)叫AlternativeUnionFS，再后來(lái)更改為AdvanceUnionFS。開發(fā)人員叫JunjiroOkajima在2006年開發(fā)的。AUFS完全重寫了早期的UnionFS1.x，其主要目的是為了可靠性和性能，并且引入了一些新的功能，比如可寫分支的負(fù)載均衡。AUFS在使用上全兼容UnionFS，而且比之前的UnionFS在穩(wěn)定性和性能上都要好很多，后來(lái)的UnionFS2.x開始抄AUFS中的功能。AUFS演示在麒麟操作系統(tǒng)中，我們可以通過(guò)mount命令手動(dòng)來(lái)創(chuàng)建AUFS，以此來(lái)感受AUFS的特性。1. 創(chuàng)建實(shí)驗(yàn)?zāi)夸沘ufsroot@kylinos:~#mkdir/aufs2. 在aufs目錄下創(chuàng)建mnt目標(biāo)作為文件系統(tǒng)的掛載點(diǎn)root@kylinos:~#mkdir/aufs/mnt3. 在aufs目錄下創(chuàng)建container-layer文件夾，用來(lái)模擬容器的讀寫層，并初始化內(nèi)容root@kylinos:~#mkdir/aufs/container-layerroot@kylinos:~#echo"containerlayer">/aufs/container-layer/container-layer.txtAUFS演示4.在aufs目錄下創(chuàng)建三個(gè)文件image-layer01、image-layer02、image-layer03，用來(lái)模擬容器的鏡像層，并初始化內(nèi)容root@kylinos:~#mkdir/aufs/{image-layer01,image-layer02,image-layer03}root@kylinos:~#echo"imagelayer01">/aufs/image-layer01/image-layer01.txtroot@kylinos:~#echo"imagelayer02">/aufs/image-layer02/image-layer02.txtroot@kylinos:~#echo"imagelayer03">/aufs/image-layer03/image-layer03.txtAUFS演示創(chuàng)建AUFS文件系統(tǒng)通過(guò)mount把container-layer、image-layer01、image-layer02、image-layer03以AUFS的方式掛載到剛才創(chuàng)建的mnt目錄下root@kylinos:~#mount-taufs-odirs=/aufs/container-layer:/aufs/image-layer01:/aufs/image-layer02:/aufs/image-layer03none/aufs/mntroot@kylinos:~#tree/aufs/mnt/aufs/mnt├──container-layer.txt├──image-layer01.txt├──image-layer02.txt└──image-layer03.txtAUFS演示在mount命令中我們沒(méi)有指定要掛載的4個(gè)文件夾的權(quán)限信息，其默認(rèn)行為是：dirs指定的左邊起第一個(gè)目錄是read-write權(quán)限，后續(xù)目錄都是read-only權(quán)限。驗(yàn)證寫時(shí)復(fù)制接下來(lái)我們向mnt/image-layer03.txt文件寫入數(shù)據(jù)：root@kylinos:~#echo"image-layer03.txt">>/aufs/mnt/image-layer03.txt查看/aufs/mnt/image-layer03.txt的內(nèi)容，發(fā)現(xiàn)已經(jīng)變化了：那再去看看底層文件/aufs/image-layer03/image-layer03.txt，發(fā)現(xiàn)他的內(nèi)容并沒(méi)有改變AUFS演示那么，改變的內(nèi)容被存儲(chǔ)到了什么地方呢？去看看container-layer目錄當(dāng)嘗試向mnt/image-layer03.txt中寫入文件時(shí)，系統(tǒng)首先在mnt目錄下查找名為image-layer03.txt的文件，將其拷貝到read-write層的container-layer目錄中，接著對(duì)container-layer目錄中的image-layer03.txt的文件進(jìn)行寫操作。這個(gè)過(guò)程也就是AUFS的實(shí)際工作原理。Overlay202Overlay2docker支持多種graphDriver，包括vfs、devicemapper、overlay、overlay2、aufs等等，其中最常用的就是aufs了，但隨著linux內(nèi)核3.18把overlay納入其中，overlay的地位變得更重，國(guó)產(chǎn)麒麟操作系統(tǒng)docker環(huán)境默認(rèn)使用Overlay2存儲(chǔ)驅(qū)動(dòng)Overlay2查看docker默認(rèn)的存儲(chǔ)目錄/var/lib/docker，我們只需要關(guān)心/var/lib/docker/image和/var/lib/docker/overlay2兩個(gè)目錄首先我們創(chuàng)建一個(gè)容器，后面章節(jié)也會(huì)重點(diǎn)講到容器。root@kylinos:~#dockerrun-dnginxOverlay2先到/var/lib/docker/image目錄下查看，只能看到overlay2這個(gè)目錄，docker會(huì)在/var/lib/docker/image目錄下按每個(gè)存儲(chǔ)驅(qū)動(dòng)的名字創(chuàng)建一個(gè)目錄，如這里的overlay2。接下來(lái)，使用tree命令瀏覽一下overlay2目錄：Overlay2關(guān)鍵地方是imagedb和layerdb目錄就是專門用來(lái)存儲(chǔ)元數(shù)據(jù)的地方，那為什么區(qū)分image和layer呢？因?yàn)樵赿ocker中，image是由多個(gè)layer組合而成的，換句話就是layer是一個(gè)共享的層，可能有多個(gè)image會(huì)指向某個(gè)layer。那如何才能確認(rèn)image包含了哪些layer呢？我們可以在imagedb這個(gè)目錄中去找。比如之前啟動(dòng)的nginx容器，我們可以先找到這個(gè)容器對(duì)應(yīng)的鏡像Overlay2我們打印/var/lib/docker/image/overlay2/imagedb/content/sha256這個(gè)目錄：所顯示的內(nèi)容正是記錄我們nginx鏡像元數(shù)據(jù)的文件，接下來(lái)cat一下這個(gè)文件，得到一個(gè)長(zhǎng)長(zhǎng)的json，我們只查看關(guān)鍵信息，也就是rootfscat/var/lib/docker/image/overlay2/imagedb/content/sha256/904b8cb13b932e23230836850610fa45dce9eb0650d5618c2b1487c2a4f577b8|json_pp|grep-A10rootfsOverlay2可以看到rootfs的diff_ids是一個(gè)包含了6個(gè)元素的數(shù)組，其實(shí)這6個(gè)元素正是組成nginx鏡像的6個(gè)layerID，從上往下看，就是底層到頂層?，F(xiàn)在得到了組成這個(gè)image的所有l(wèi)ayerID，那么我們就可以帶著這些layerID去尋找對(duì)應(yīng)的layer了。接下來(lái)，我們返回到上一層的layerdb中，先打印