如何分析Docker文件系統

這篇文章將為大家詳細講解有關如何分析Docker文件系統，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

我們來實戰構建一個Docker鏡像，然后實例化容器，在Docker的生命周期中詳細分析一下Docker的文件存儲情況和DockerFile優化策略。

在開始實戰之前，我們先介紹一個概念，聯合文件系統（Union File System）。聯合文件系統是實現Docker鏡像的技術基礎，支持對文件系統的修改作為一次提交來一層層的疊加，同時可以將不同目錄掛載到同一個虛擬文件系統下。鏡像的分層存儲和繼承就是基于此特性實現。

下面是Docker官方的一張描述文件系統的圖片，顯示了一張聯合文件系統在串聯鏡像層和容器層起到的作用

Docker支持多種聯合文件系統，常見的有aufs，deviceMapper，overlay，overlay2，本文章中使用的系統版本為debian9.1，Docker版本為17.06.2-ce，默認使用是overlay2。

    看到這里如果你已經對Docker文件系統有了簡單的概念，那么讓我們開始實戰，來對分層文件系統的存儲方式進行更加深入的了解。

鏡像層

這是一個云信私有化項目中基于debian系統鏡像創建的jdk8基礎鏡像，為了方便閱讀和分析，我們Dockerfile進行了一些精簡，只保留核心部分內容

根據構建鏡像，查看構建結果，原基礎鏡像100M，構建后鏡像體積697M。

鏡像存儲

    現在開始看一下構建鏡像工作在文件層存儲情況。首先我們使用Docker history查看一下剛剛構建鏡像情況，可以看到基礎鏡像占用100M，兩個鏡像分層占用194MB和403M。

接下來我們看查看一下文件系統中的存儲情況，本環境使用overlay2，Docker鏡像層存儲默認路徑為/var/lib/Docker/overlay2/，可以看到鏡像存儲目錄下有4個目錄，其中110M的對應是基礎鏡像，另外兩個為ADD JDK（186M）和解壓JDK壓縮包的鏡像分層（389M）。

其中的l目錄包含了所有層的軟連接，軟鏈接使用短名稱，避免mount時候參數達到頁面大小限制。

下面我們了解一下，每個分層中的文件內容。基礎鏡像分層包含diff文件夾和link文件，diff文件夾中存放當前分層內容，link文件記錄短名稱。

接下來看一下COPY JDK生成的內容，diff文件夾保存了jdk壓縮包，本層相比基礎鏡像層，多了lower，merged，work三個文件/文件夾，其中lower記錄了此層的下層ID（基礎鏡像層），merged目錄作為提供了統一視圖，在容器層讀寫層被使用，work目錄用于聯合掛載指定的工作目錄，使用過程對用戶不可見。

解壓JDK層的文件夾結構內容和上一層類似，主要關注jdk壓縮包占用空間為0，表示已被刪除。

現在來重點關注一個問題，鏡像大小等于所有分層相加，在后續分層中被刪除的jdk壓縮包仍然要占用存儲空間，這并不是我們原本意圖，因此這里就出現了鏡像文件進行優化的點。優化后的Dockerfile如下

借這個優化后的內容，我們再談一下構建Docker鏡像時在時間和空間可優化的點：

1. 組合運行語句：合并相同類型構建語句，可以有效減少鏡像分層；

2. 利用鏡像構建緩存：時間同步，基礎軟件安裝等固定內容在鏡像前部分處理，鏡像重新構建時會使用緩存，節省時間；

3. 清理中間產物：注意安裝過程中使用的軟件和壓縮包在一定要同一層里清理，否則仍然會占用鏡像空間；

4. 構建語句優化：比如ADD在處理本地文件時可以直接解壓縮，起到COPY + RUN tar的作用；

5. 優化基礎鏡像源：國內高校和大型IT企業都有創建鏡像站，選擇一個穩定更新及時的鏡像站可以有效縮短構建時間；

舉例的鏡像中優化策略涉及1,3條，用curl替代add，與解壓和刪除合并為一層，Dockerfile減少了層數，清理中間過程的jdk安裝包，下圖是優化后鏡像體積變化：

    構建鏡像真的是層數越少越好嗎？當然不是這么絕對，尤其在早期鏡像版本不是很穩定或是后續迭代比較頻繁時，合理的鏡像分層會減少編譯時間，降低出錯概率，也可以讓Dockerfile更具有可讀性。可以再穩定版本形成之后對鏡像進行二次優化。

鏡像元數據

分析一個鏡像元數據我們主要關注三個目錄

第一個目錄保存鏡像基礎元數據，第二個目錄保存鏡像分層元數據，第三個是上文提到的分層存儲目錄，保存實際分層內容。下面就根據實際情況來看一下，元數據與存儲信息是如何關聯起來的。

Docker鏡像的基本信息保存在/var/lib/Docker/image/overlay2/imaged/content/sha256/下面，可以根據Docker image ID在此目錄下查找到對應ID開頭文件。此文件中以json的形式保存了該鏡像的分層文件系統、構建信息、相關容器等內容。

第二個目錄/var/lib/Docker/image/overlay2/layerdb/sha256/保存分層元數據，每一個分層元數據目錄下有cache-id，diff，size信息，其中cache-id對應分層存儲層，diff關聯鏡像基礎元數據信息。

容器層

首先我們來啟動一個容器，掛載宿主機/opt/yunxin目錄到容器/usr/local/yunxin目錄

創建容器完成之后，在鏡像存儲目錄/var/lib/Docker/overlay2/會生成容器的初始層和讀寫層，兩者使用相同標識，初始層后面多了-init。初始層中主要保存初始化容器環境時，與容器相關的環境信息，如容器主機名，主機host信息以及域名服務文件等；讀寫層用于容器的讀寫，Docker容器內的進程只對讀寫層擁有寫權限，而對其他層文件內容只擁有讀權限。

接下來我們進入容器操作進行一系列操作，再根據結果分析一下讀寫層對于文件的保存和處理，下面是操作和對應結果以及讀寫層實際文件存儲情況。

讀寫層中的merged文件夾提供了統一視圖，面向用戶展示聯合文件系統掛載完成的最終形態。

接下來我們再基于同一個鏡像啟動幾個容器實例，然后來查詢一下Docker容器使用空間，只有第一個容器由于上面修改文件只占用154k，新啟動的容器并沒有額外占用空間。可見基于同一個鏡像創建容器時，所有的容器共享鏡像層內容，有效節約了空間。讀寫層只保存修改內容，如果是操作鏡像層文件，Docker采用的是修改時復制策略(copy-on-write)。這時回頭再看一下第一節出現的兩張圖，會對Docker的文件系統有了更深的體會。

Docker 鏡像和容器文件系統相關知識在云信私有化產品的鏡像管理和運維存儲管理方面作出理論支撐，但這只是深入了解Docker的開始。隨著時間的積淀和云信旗下IM、音視頻、點播以及眾多相關產品私有化工作的深入，更多的模塊和鏡像，更多的客戶和需求，更復雜的網絡和環境都逐漸呈現在我們面前。Docker作為構建云信私有化服務的基礎，只有更深入的去了解原理才能在使用中去更好的優化產品和開展運維。希望我們能為用戶提供更可靠的云信私有化服務，也希望能在后續的文章中能與大家分享更多關于Docker的知識。

關于如何分析Docker文件系統就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。