Docker文件系統實戰

• 2020 年 6 月 30 日
• 筆記

關鍵詞：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的知識。

立即了解網易雲信私有雲>>

更多技術乾貨，歡迎關注vx公眾號「網易智慧企業技術+」。系列課程提前看，精品禮物免費得，還可直接對話CTO。

聽網易CTO講述前沿觀察，看最有價值技術乾貨，學網易最新實踐經驗。網易智慧企業技術+，陪你從思考者成長為技術專家。