本地 基本操作 wid 運行時 註釋 重復 命令執行 int size

一 鏡像基本操作

鏡像是一個包含程序運行必要依賴環境和代碼的只讀文件，其本質是磁盤上一系列文件的集合。它采用分層的文件系統，將每一次改變以讀寫層的形式增加到原來的只讀文件上。鏡像是容器運行的基石。

1.1 搜索鏡像

docker命令必須具備root權限，普通用戶可是用那個sudo。 提示：docker默認的Docker Hub 網址為： https://hub.docker.com/，速度很慢，建議添加國內的阿裏雲加速器，參考004-4.1。 選項說明： NAME:鏡像倉庫源的名稱 DESCRIPTION:鏡像的描述 OFFICIAL:是否docker官方發布 AUTOMATED：是否使用了自動構建

1.2 下載（拉取）鏡像

提示： Registry：倉庫，Registry包含一個或多個Repository Repository：系列，Repository包含一個或多個Image Tag and Image：Image用GUID表示，有一個或多個Tag與之關聯，版本號。

1.3 列出（查看）本地鏡像

選項說明:

• REPOSTITORY：表示鏡像的倉庫源，有以下類型：

• [namespace/centos]：由命名空間和實際的倉庫名稱組成。
• [centos]：只有倉庫名。屬於頂級命名空間，只用於官方鏡像。
• [dl.dockerpool.com:5000\centos:7]：指定URL路徑的方式。

• TAG：鏡像的標簽

• 未指定鏡像tag時，默認為latest，但latest沒有任何特殊含義，人為的將latest作為最新穩定版本的別名；
• 一個repository可以有多個tag,而多個tag也可能對應同一個鏡像。

• IMAGE ID：鏡像ID
• CREATED：鏡像創建時間
• SIZE：鏡像大小

1.4 推送鏡像

提示：推送鏡像之前必須配置好倉庫信息。建議推送至個人私有倉庫，同時采用國內阿裏雲私有倉庫，配置方法見《附001-docker阿裏雲Registry配置》。

1.5 導出鏡像

1.6 導入鏡像

1.7 刪除鏡像

1.8 設置鏡像標簽

二 docker文件系統

2.1 Linux文件系統簡介

linux文件系統由bootfs和rootfs組成，bootfs主要包含bootloader和kernel，bootloader主要是引導加載kernel，當kernel被加載到內存之後bootfs就被卸載掉了。rootfs包含的就是典型linux系統中/dev,/proc,/bin,/etc等標準目錄。

2.2 docker文件系統

Docker容器是建立在Aufs基礎上的，Aufs支持將不同的目錄掛載到同一個虛擬文件系統下，並實現一種layer的概念。Aufs將掛載到同一虛擬文件系統下的多個目錄分別設置成read-only，read-write以及whiteout-able權限。 read-only目錄只能讀，而寫操作只能在read-write目錄中實現。 寫操作是在read-only之上的一種增量操作，不影響read-only目錄。 docker 鏡像中每一層文件系統都是read-only。 提示：當掛載目錄的時候要嚴格按照各目錄之間的這種增量關系，將被增量操作的目錄優先於在它基礎上增量操作的目錄掛載，待所有目錄掛載結束了，繼續掛載一個read-write目錄，如此便形成了一種層次結構。

2.3 docker鏡像原理

在構建鏡像時，從一個最基本的操作系統開始，每個構建的操作都相當於做一層修改，增加了一層文件系統，一層層往上疊加，上層的修改會覆蓋底層該位置的可見性。當使用時，只會看到一個完全的整體，總共有多少層以及每層所做的修改都是透明的。 docker image 中最基礎的兩層結構： 不同的 linux 發行版（如 ubuntu 和 CentOS ) 在 rootfs 這一層會有所區別，體現發行版本的差異性： 傳統的 Linux 加載 bootfs 時會將 rootfs 設為 read-only，然後在系統自檢後將 rootfs 從 read-only改為 read-write，然後可在 rootfs 上進行讀寫操作。 Docker相比在 bootfs 自檢完畢之後不會將 rootfs 的 read-only 改為 read-write，而是利用 union mount（UnionFS 的一種掛載機制）將 image 中其他的 layer 加載到之前的 read-only 的 rootfs 層之上，每一層 layer 都是 rootfs 的結構，並且是read-only 的。因此，無法修改一個已有鏡像裏面的 layer層數據，只有當創建一個容器，即將 Docker 鏡像進行實例化後，系統會分配一層空的 read-write 的 rootfs ，用於提供數據修改。

三 鏡像結構

3.1 image結構

docker image的layer組織方式通常由 json、layer.tar、VERSION組成。 解釋：repositories 文件，裏面是一個 JSON 定義，保存了三個信息：鏡像名字、tag、tag 對應的 layer。 解釋：主要關於鏡像的配置信息，簡要部分信息如上。 解釋：包括一個類 Linux 文件目錄的結構，保存著這個 layer 所做的修改。

四 Dockerfile、Docker鏡像和Docker容器

4.1 關系

Dockerfile 是軟件的原材料，Docker 鏡像是軟件的交付品，而 Docker 容器則可以認為是軟件的運行態。從應用軟件的角度來看，Dockerfile、Docker 鏡像與 Docker 容器分別代表軟件的三個不同階段，Dockerfile 面向開發，Docker 鏡像成為交付標準，Docker 容器則涉及部署與運維。 Dockerfile構建出Docker鏡像，通過Docker鏡像運行Docker容器。 參考鏈接：http://dockone.io/article/783 https://blog.csdn.net/xuguokun1986/article/details/79295947

五 docker存儲驅動

Docker最開始采用AUFS作為文件系統，也得益於AUFS分層的概念，實現了多個Container可以共享同一個image。但由於AUFS未並入Linux內核，且只支持Ubuntu，考慮到兼容性問題，在Docker 0.7版本中引入了存儲驅動， 目前，Docker支持AUFS、Btrfs、Device mapper、OverlayFS、ZFS五種存儲驅動。

5.1 底層技術

• 寫時復制（CoW）

所有驅動都需要用到寫時復制（CoW），CoW就是copy-on-write，表示只在需要寫時才去復制，這個是針對已有文件的修改場景。比如基於一個image啟動多個Container，如果為每個Container都去分配一個image一樣的文件系統，那麽將會占用大量的磁盤空間。而CoW技術可以讓所有的容器共享image的文件系統，所有數據都從image中讀取，只有當要對文件進行寫操作時，才從image裏把要寫的文件復制到自己的文件系統進行修改。 所以無論有多少個容器共享同一個image，所做的寫操作都是對從image中復制到自己的文件系統中的復本上進行，並不會修改image的源文件，且多個容器操作同一個文件，會在每個容器的文件系統裏生成一個復本，每個容器修改的都是自己的復本，相互隔離，相互不影響。使用CoW可以有效的提高磁盤的利用率。

• 用時分配（allocate-on-demand）

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

5.2 AUFS

AUFS（AnotherUnionFS）是一種Union FS，是文件級的存儲驅動。AUFS能透明覆蓋一個或多個現有文件系統的層狀文件系統，把多層合並成文件系統的單層表示。即支持將不同目錄掛載到同一個虛擬文件系統下的文件系統。 這種文件系統可以一層一層地疊加修改文件。無論底下有多少層都是只讀的，只有最上層的文件系統是可寫的。當需要修改一個文件時，AUFS創建該文件的一個副本，使用CoW將文件從只讀層復制到可寫層進行修改，結果也保存在可寫層。 在Docker中，底下的只讀層就是image，可寫層就是Container。結構如下圖所示：

5.3 OverlayFS

Overlay是Linux內核3.18後支持的，也是一種Union FS，和AUFS的多層不同的是Overlay只有兩層：一個upper文件系統和一個lower文件系統，分別代表Docker的鏡像層和容器層。當需要修改一個文件時，使用CoW將文件從只讀的lower復制到可寫的upper進行修改，結果也保存在upper層。在Docker中，底下的只讀層就是image，可寫層就是Container。

5.4 Device mapper

Device mapper是Linux內核2.6.9後支持的，提供的一種從邏輯設備到物理設備的映射框架機制，在該機制下，用戶可根據需要制定實現存儲資源的管理策略。 不同於AUFS和OverlayFS的文件級存儲，Device mapper是塊級存儲，所有的操作都是直接對塊進行操作，而不是文件。 Device mapper驅動會先在塊設備上創建一個資源池，然後在資源池上創建一個帶有文件系統的基本設備，所有鏡像都是這個基本設備的快照，而容器則是鏡像的快照。 所以在容器裏看到文件系統是資源池上基本設備的文件系統的快照，並不有為容器分配空間。當要寫入一個新文件時，在容器的鏡像內為其分配新的塊並寫入數據，即用時分配。當要修改已有文件時，再使用CoW為容器快照分配塊空間，將要修改的數據復制到在容器快照中新的塊裏再進行修改。 Device mapper 驅動默認會創建一個100G的文件包含鏡像和容器。每一個容器被限制在10G大小的卷內，大小可配置調整。

5.5 Btrfs

Btrfs被稱為下一代寫時復制文件系統，並入Linux內核，也是文件級級存儲，但可以像Device mapper直接操作底層設備。 Btrfs把文件系統的一部分配置為一個完整的子文件系統，稱之為subvolume 。那麽采用 subvolume，一個大的文件系統可以被劃分為多個子文件系統，這些子文件系統共享底層的設備空間，在需要磁盤空間時便從底層設備中分配。 為了靈活利用設備空間，Btrfs 將磁盤空間劃分為多個chunk 。每個chunk可以使用不同的磁盤空間分配策略。比如某些chunk只存放metadata，某些chunk只存放數據。這種模型有很多優點，比如Btrfs支持動態添加設備。 用戶在系統中增加新的磁盤之後，可以使用Btrfs的命令將該設備添加到文件系統中。 Btrfs把一個大的文件系統當成一個資源池，配置成多個完整的子文件系統，還可以往資源池裏加新的子文件系統，而基礎鏡像則是子文件系統的快照，每個子鏡像和容器都有自己的快照，這些快照則都是subvolume的快照。 當寫入一個新文件時，為在容器的快照裏為其分配一個新的數據塊，文件寫在這個空間裏，這個叫用時分配。而當要修改已有文件時，使用CoW復制分配一個新的原始數據和快照，在這個新分配的空間變更數據，變結束再更新相關的數據結構指向新子文件系統和快照，原來的原始數據和快照沒有指針指向，被覆蓋。

5.6 ZFS

ZFS 文件系統是一個革命性的全新的文件系統，它從根本上改變了文件系統的管理方式，ZFS 完全拋棄了“卷管理”，不再創建虛擬的卷，而是把所有設備集中到一個存儲池中來進行管理，用“存儲池”的概念來管理物理存儲空間。過去，文件系統都是構建在物理設備之上的。為了管理這些物理設備，並為數據提供冗余，“卷管理”的概念提供了一個單設備的映像。而ZFS創建在虛擬的，被稱為“zpools”的存儲池之上。每個存儲池由若幹虛擬設備（virtual devices，vdevs）組成。這些虛擬設備可以是原始磁盤，也可能是一個RAID1鏡像設備，或是非標準RAID等級的多磁盤組。於是zpool上的文件系統可以使用這些虛擬設備的總存儲容量。 Docker裏ZFS的使用。首先從zpool裏分配一個ZFS文件系統給鏡像的基礎層，而其他鏡像層則是這個ZFS文件系統快照的克隆，快照是只讀的，而克隆是可寫的，當容器啟動時則在鏡像的最頂層生成一個可寫層。如下圖所示： 當要寫一個新文件時，使用按需分配，一個新的數據快從zpool裏生成，新的數據寫入這個塊，而這個新空間存於容器（ZFS的克隆）裏。 當要修改一個已存在的文件時，使用寫時復制，分配一個新空間並把原始數據復制到新空間完成修改。

5.7 存儲驅動的對比及適應場景

參考鏈接：http://dockone.io/article/1513

5.8 修改docker存儲驅動類型

六 創建鏡像

從鏡像倉庫中下載的鏡像若不能滿足需求，可通過以下兩種方式對鏡像進行更改。

• 從已經創建的容器中更新鏡像，並且提交這個鏡像
• 使用 Dockerfile 指令來創建一個新的鏡像

6.1 更新鏡像並提交

1. 運行容器
2. 修改容器
3. 將容器保存為新的鏡像

參數說明：

• -m:提交的描述信息
• -a:指定鏡像作者
• 01b2b251e216 ：容器ID
• centos-7-01:指定要創建的目標鏡像名

更新現有鏡像缺陷

• 手動創建，容易出錯，效率低及可重復性弱
• 使用者並不知道鏡像是如何創建出來的，裏面是否有惡意程序，可能存在案例隱患

6.2 Dockerfile構建鏡像舉例

語句說明： 第一條FROM，指定所采用的鏡像源，每一個指令的前綴都必須是大寫的； RUN 指令表示docker在鏡像內執行的命令，更多詳見七Dockerfile詳解。 參數說明：

• -t ：指定要創建的目標鏡像名
• /dockerfiles/：Dockerfile 文件所在目錄

七 Dockerfile詳解

7.1 Dockerfile典型結構

7.2 Dockerfile相關指令

• 指令：From

語法： 含義：FROM命令定義構建鏡像的基礎鏡像，該條必須是dockerfile的首個命令。若同一個DockerFile創建多個鏡像時，可使用多個From指令（每個鏡像一次），FROM 是必備且必須是第一條指令。在FROM指定構建鏡像的基礎源鏡像時，若本地沒有指定的該鏡像，則會自動從 Docker 的公共庫 pull 鏡像下來。 提示：

• FROM必須是 Dockerfile 中非註釋行的第一個指令，即一個 Dockerfile 從FROM語句開始。
• 如果有需求在一個 Dockerfile 中創建多個鏡像，則FROM可以在一個 Dockerfile 中出現多次。
• 如果FROM語句沒有指定鏡像標簽，則默認使用latest標簽。

舉例：FROM ubuntu

• 指令：MAINTAINER

語法： 含義：聲明作者信息，可以放在文件任何位置，建議放在FROM後面。 舉例：

• 指令：RUN

語法： 含義：RUN 指令是用來執行命令行命令的,每條RUN指令將在當前鏡像基礎上執行指定命令，並提交為新的鏡像，後續RUN都在之前RUN提交後的鏡像為基礎. exec 方式會被解析為一個 JSON 數組，所以必須使用雙引號而不是單引號。exec 方式不會調用一個命令 shell，所以也就不會繼承相應的變量,RUN產生的緩存在下一次構建的時依舊有效，且會被重用，可以使用--no-cache選項，即docker build --no-cache，如此便不會緩存。 舉例： 提示：對於處理同一事件的多個命令，建議采用&&連接為一個命令，即構建一層即可。命令過長可使用\的換行方式。

• 指令：CMD

語法： 含義：CMD配置在啟動容器時提供一個默認的命令執行選項，如果用戶啟動容器時指定了運行的命令，則會覆蓋掉CMD指定的命令。 舉例： 提示：在容器運行時可指定新的命令來替代鏡像設置的默認命令，如ubuntu鏡像默認的CMD是/bin/bash，直接docker run -it ubuntu則會進入bash。若在運行時指定其他的命令，如docker run -it ubuntu cat /etc/os-release 。則使用cat /etc/os-release命令替換默認/bin/bash命令。 註意：CMD會在啟動容器的時候執行，build 時不執行，而RUN只是在構建鏡像的時候執行。

• 指令：ENTRYPOINT

語法： 含義：ENTRYPOINT配置容器啟動後執行的命令，並且不可被 docker run 提供的參數覆蓋，區別於CMD是可以被覆蓋的。若需要ENTRYPOINT被覆蓋，則可以使用docker run --entrypoint選項。 舉例： 註意：每個 Dockerfile 中只能有一個ENTRYPOINT，當指定多個時，只有最後一個生效； 當指定了 ENTRYPOINT 後， CMD 不再是直接的運行其命令，而是將CMD 的內容作為參數傳給 ENTRYPOINT 指令，即：<ENTRYPOINT> "<CMD>"

• 指令：ADD

語法： 含義：復制本地主機、url或啟動配置上下文中的文件到容器指定路徑中 。 舉例： 提示：若 <src> 是一個 URL ，構建鏡像時會下載這個鏈接的文件放至 <dest> ，下載後權限為 600； 若傳入dest的是個tar壓縮包，壓縮格式為 gzip、bzip2 以及 xz 的情況下， ADD 指令將會自動解壓縮這個壓縮文件至 <dest> 。因此若只是復制個壓縮文件進去，而不解壓縮，建議使用copy； ADD 指令會令鏡像構建緩存失效，從而可能會令鏡像構建變得比較緩慢。

• 指令：COPY

語法： 含義：復制新文件或者目錄從 並且添加到容器指定路徑中 ，用法參考ADD，但COPY不能指定遠程文件 URLS。 舉例： 建議：在 COPY 和 ADD 指令中選擇的時候，可以遵循這樣的原則，所有的文件復制均使用 COPY 指令，僅在需要自動解壓縮的場合使用 ADD 。

• 指令：EXPOSE

語法： 含義：聲明Docker服務端容器對外監聽的端口，需要同時在docker run 的時候使用-p或者-P選項生效，默認為TCP。 舉例：

• 指令：ENV

語法： 含義：指定一個環節變量，會被後續RUN指令使用，並在容器運行時保留。 舉例：

• 指令：VOLUME

語法： 含義：卷分為宿主目錄、數據卷、容器卷。VOLUME命令會設置掛載點，在啟動容器的時候Docker會在/var/lib/docker/的下一級目錄下創建一個卷，一般用來存放動態數據和需要保持的數據等。 舉例：

• 指令：WORKDIR

語法： 含義：使用 WORKDIR 指令可以來指定工作目錄（或者稱為當前目錄），之後各層的當前目錄就被改為指定的目錄，如該目錄不存在， WORKDIR 會幫你建立目錄，在使用 docker run 命令啟動容器時，默認會進入的目錄是 WORKDIR 指定的目錄。 舉例：

• 指令：USER

語法： 含義：指定運行容器時的用戶名或UID，後續的 RUN 也會使用指定用戶。當服務不需要管理員權限時，可以通過該命令指定運行用戶。 舉例： 提示：WORKDIR 是改變工作目錄， USER 則是改變之後層的執行 RUN , CMD 以及 ENTRYPOINT 這類命令的身份。

• 指令：ONBUILD

語法： 含義：ONBUILD 是一個特殊的指令，ONBUILD 後是其它指令，比如 RUN , COPY 等，而此類指令，在當前鏡像構建時並不會被執行。只有當以當前鏡像為基礎鏡像，去構建下一個鏡像的時候才會被執行。即配置當該鏡像作為其它新創建鏡像的基礎鏡像時，所執行的操作指令。 舉例：Dockerfile-01使用如下的內容創建了鏡像image-A： Dockerfile-02使用基於image-A的基礎鏡像創建image-B： Dockerfile-02的內容等同於：

• 指令：HEALTHCHECK

語法： 含義：HEALTHCHECK 指令用於判斷Docker容器的狀態是否正常。 選項： HEALTHCHECK 支持下列選項：

• interval=<間隔> ：兩次健康檢查的間隔，默認為 30 秒；
• timeout=<時長> ：健康檢查命令運行超時時間，如果超過這個時間，本次健康檢查就被視為失敗，默認 30 秒；
• retries=<次數> ：當連續失敗指定次數後，則將容器狀態視為 unhealthy ，默認 3 次。

舉例： 設置了每 5 秒檢查一次，如果健康檢查命令超過 3 秒沒響應就視為失敗，並且使用 curl -fs http://localhost/ || exit 1 作為健康檢查命令。 提示：類似CMD , ENTRYPOINT 一樣， HEALTHCHECK 也只可以出現一次，若存在多個HEALTHCHECK，只有最後一個生效。 參考鏈接：https://blog.csdn.net/wo18237095579/article/details/80540571

7.3 dockerfile最佳實踐

• 使用.dockerignore文件

為在docker build過程中更快上傳和更加高效，可使用一個.dockerignore文件用來排除構建鏡像時不需要的文件或目錄。

• 避免安裝不必要的軟件包

為了降低復雜性、依賴性、文件大小以及構建時間，應該避免安裝額外的或不必要的包。

• 每個容器都跑一個進程

在大多數情況下，一個容器應該只單獨跑一個程序。解耦應用到多個容器使其更容易橫向擴展和重用。

• 最小化層

每執行一個指令，都會有一次鏡像的提交，鏡像是分層的結構，對於Dockerfile，應該找到可讀性和最小化層之間的平衡。

• 多行參數排序

如果可能，通過字母順序來排序，這樣可以避免安裝包的重復並且更容易更新列表，另外可讀性也會更強，添加一個空行使用\換行:

• 盡可能清理不必要的文件

使構建後的鏡像盡可能的小。

Docker鏡像原理(轉載)