包括 鏡像 存在 沒有 pretty -- 安裝、配置 nbsp bsp

cache 機制註意事項

可以說，cache 機制很大程度上做到了鏡像的復用，降低存儲空間的同時，還大大縮短了構建時間。然而，不得不說的是，想要用好 cache 機制，那就必須了解利用 cache 機制時的一些註意事項。

1. ADD 命令與 COPY 命令：Dockerfile 沒有發生任何改變，但是命令ADD run.sh / 中 Dockerfile 當前目錄下的 run.sh 卻發生了變化，從而將直接導致鏡像層文件系統內容的更新，原則上不應該再使用 cache。那麽，判斷 ADD 命令或者 COPY 命令後緊接的文件是否發生變化，則成為是否延用 cache 的重要依據。Docker 采取的策略是：獲取 Dockerfile 下內容（包括文件的部分 inode 信息），計算出一個唯一的 hash 值，若 hash 值未發生變化，則可以認為文件內容沒有發生變化，可以使用 cache 機制；反之亦然。

2. RUN 命令存在外部依賴：一旦 RUN 命令存在外部依賴，如RUN apt-get update

，那麽隨著時間的推移，基於同一個基礎鏡像，一年的 apt-get update 和一年後的 apt-get update， 由於軟件源軟件的更新，從而導致產生的鏡像理論上應該不同。如果繼續使用 cache 機制，將存在不滿足用戶需求的情況。Docker 一開始的設計既考慮了外部依賴的問題，用戶可以使用參數 --no-cache 確保獲取最新的外部依賴，命令為docker build --no-cache -t="my_new_image" .

3. 樹狀的鏡像關系決定了，一次新鏡像的成功構建將導致後續的 cache 機制全部失效：這一點很好理解，一旦產生一個新的鏡像，同時意味著產生一個新的鏡像 ID，而當前宿主機環境中肯定不會存在一個鏡像，此鏡像 ID 的父鏡像 ID 是新產生鏡像的ID。這也是為什麽，書寫 Dockerfile 時，應該將更多靜態的安裝、配置命令盡可能地放在 Dockerfile 的較前位置。

docker build 的 cache 機制