近幾年 docker 風靡技術圈，不少從業人員都或多或少使用過，也了解如何通過 dockerfile 構建映象，從遠端映象倉庫拉取自己所需映象，推送構建好的映象至遠端倉庫，根據映象執行容器等。這個過程十分簡單，只需執行 docker build、docker pull、docker push、docker run 等操作即可。但大家是否想過映象在本地到底是如何儲存的？容器又是如何根據映象啟動的？推送映象至遠端映象倉庫時，伺服器又是如何儲存的呢？下面我們就來簡單聊一聊。
docker 映象不是乙個單一的檔案，而是有多層構成。我們可通過 docker images 獲取本地的映象列表及對應的元資訊， 接著可通過docker history 檢視某個映象各層內容及對應大小，每層對應著 dockerfile 中的一條指令。docker 映象預設儲存在 /var/lib/docker/中，可通過 docker_opts 或者 docker daemon 執行時指定 –graph= 或 -g 指定。
選擇會受限於 docker 版本、作業系統、系統版本等。例如，aufs 只能用於 ubuntu 或 debian 系統，btrfs 只能用於 sles （suse linux enterprise server, 僅 docker ee 支援）。
有些儲存驅動依賴於後端的檔案系統。例如，btrfs 只能執行於後端檔案系統 btrfs 上。
docker 容器其實是在映象的最上層加了一層讀寫層，通常也稱為容器層。在執行中的容器裡做的所有改動，如寫新檔案、修改已有檔案、刪除檔案等操作其實都寫到了容器層。容器層刪除了，最上層的讀寫層跟著也刪除了，改動自然也丟失了。若要持久化這些改動，須通過 docker commit [repository[:tag]] 將當前容器儲存成為乙個新映象。若想將資料持久化，或是多個容器間共享資料，需將資料儲存在 docker volume 中，並將 volume 掛載到相應容器中。
儲存驅動決定了映象及容器在檔案系統中的儲存方式及組織形式，下面分別對常見的 aufs、overlay 作一簡單介紹。
aufs 簡介
aufs 是 debian (stretch 之前的版本，stretch預設採用 overlay2) 或 ubuntu 系統上 docker 的預設儲存驅動，也是 docker 所有儲存驅動中最為成熟的。具有啟動快，記憶體、儲存使用高效等特點。如果使用的 linux 核心版本為 4.0 或更高，且使用的是 docker ce，可考慮使用overlay2 （比 aufs 效能更佳）。
配置 aufs 儲存驅動
aufs 儲存驅動工作原理
採用 aufs 儲存驅動時，有關映象和容器的所有層資訊都儲存在 /var/lib/docker/aufs/ 目錄下，下面有三個子目錄：
採用 aufs 後容器如何讀寫檔案？
讀檔案
容器進行讀檔案操作有以下三種場景：
修改檔案或目錄
容器中進行檔案的修改同樣存在三種場景：
overlayfs 簡介
overlayfs 是一種類似 aufs 的現代聯合檔案系統，但實現更簡單，效能更優。overlayfs 嚴格說來是 linux 核心的一種檔案系統，對應的 docker 儲存驅動為 overlay 或者 overlay2，overlay2 需 linux 核心 4.0 及以上，overlay 需核心 3.18 及以上。且目前僅 docker 社群版支援。條件許可的話，盡量使用 overlay2，與 overlay 相比，它的 inode 利用率更高。
容器如何使用 overlay／overlay2 讀寫檔案
讀檔案
讀檔案存在以下三種場景：
修改檔案或目錄
寫檔案存在以下三種場景：
不少人可能經常使用 docker，那麼有沒有思考過映象推送至遠端映象倉庫，是如何儲存的呢？docker 客戶端是如何與遠端映象倉庫互動的呢？
我們平時本地安裝的 docker 其實包含兩部分：docker client 與 docker engine，docker client 與 docker engine 間通過 api 進行通訊。docker engine 提供的 api 大致有認證、容器、映象、網路、卷、swarm 等，具體呼叫形式請參考：docker engine api。
docker engine 與 registry （即：遠端映象倉庫）的通訊也有一套完整的 api，大致包含 pull、push 映象所涉及的認證、授權、映象儲存等相關流程，具體請參考：registry api。目前常用 registry 版本為 v2，registry v2 擁有斷點續傳、併發拉取映象多層等特點。能併發拉取多層是因為映象的元資訊與映象層資料分開儲存，當 pull 乙個映象時，先進行認證獲取到 token 並授權通過，然後獲取映象的 manifest 檔案，進行 signature 校驗。校驗完成後，依據 manifest 裡的層資訊併發拉取各層。其中 manifest 包含的資訊有：倉庫名稱、tag、映象層 digest 等， 更多，請參考：manifest 格式文件。
各層拉下來後，也會先在本地進行校驗，校驗演算法採用 sha256。push 過程則先將映象各層併發推至 registry，推送完成後，再將映象的 manifest 推至 registry。registry 其實並不負責具體的儲存工作，具體儲存介質根據使用方來定，registry 只是提供一套標準的儲存驅動介面，具體儲存驅動實現由使用方實現。
目前官方 registry 預設提供的儲存驅動包括：微軟 azure、google gcs、amazon s3、openstack swift、阿里雲 oss、本地儲存等。若需要使用自己的物件儲存服務，則需要自行實現 registry 儲存驅動。網易雲目前將映象儲存在自己的物件儲存服務 nos 上，故專門針對 nos 實現了一套儲存驅動，另外認證服務也對接了網易雲認證服務，並結合自身業務實現了一套認證、授權邏輯，並有效地限制了倉庫配額。
Docker 映象的儲存機制
近幾年 docker 風靡技術圈，不少從業人員都或多或少使用過，也了解如何通過 dockerfile 構建映象，從遠端映象倉庫拉取自己所需映象，推送構建好的映象至遠端倉庫，根據映象執行容器等。這個過程十分簡單，只需執行 docker build docker pull docker push doc...
docker修改映象儲存位置
yum y install epel release yum y install docker docker versiondocker版本資訊 client version 1.13.1 api version 1.26 package version docker 1.13.1 94.gitb2...
docker 私有倉庫映象的儲存位置
docker 私有倉庫的映象 是儲存在5739360d1030 registry docker registry 3 days ago up 28 hours 0.0.0.0 5000 5000 tcp sad mccarthy regisry 容器裡 你可以選擇啟動registry的時候，手動掛乙...