1. 程式人生 > >你確定你會寫 Dockerfile 嗎?

你確定你會寫 Dockerfile 嗎?

原文連結:你確定你會寫 Dockerfile 嗎?

如今 GitHub 倉庫中已經包含了成千上萬的 Dockerfile,但並不是所有的 Dockerfile 都是高效的。本文將從五個方面來介紹 Dockerfile 的最佳實踐,以此來幫助大家編寫更優雅的 Dockerfile。如果你是 Docker 的初學者,恭喜你,這篇文章就是為你準備的。後面的系列將會更加深入,敬請期待!

本文使用一個基於 Maven 的 Java 專案作為示例,然後不斷改進 Dockerfile 的寫法,直到最後寫出一個最優雅的 Dockerfile。中間的所有步驟都是為了說明某一方面的最佳實踐。

1. 減少構建時間

一個開發週期包括構建 Docker 映象,更改程式碼,然後重新構建 Docker 映象。在構建映象的過程中,如果能夠利用快取,可以減少不必要的重複構建步驟。

構建順序影響快取的利用率

映象的構建順序很重要,當你向 Dockerfile 中新增檔案,或者修改其中的某一行時,那一部分的快取就會失效,該快取的後續步驟都會中斷,需要重新構建。所以優化快取的最佳方法是把不需要經常更改的行放到最前面,更改最頻繁的行放到最後面。

只拷貝需要的檔案,防止快取溢位

當拷貝檔案到映象中時,儘量只拷貝需要的檔案,切忌使用 COPY . 指令拷貝整個目錄。如果被拷貝的檔案內容發生了更改,快取就會被破壞。在上面的示例中,映象中只需要構建好的 jar 包,因此只需要拷貝這個檔案就行了,這樣即使其他不相關的檔案發生了更改也不會影響快取。

最小化可快取的執行層

每一個 RUN 指令都會被看作是可快取的執行單元。太多的 RUN 指令會增加映象的層數,增大映象體積,而將所有的命令都放到同一個 RUN 指令中又會破壞快取,從而延緩開發週期。當使用包管理器安裝軟體時,一般都會先更新軟體索引資訊,然後再安裝軟體。推薦將更新索引和安裝軟體放在同一個 RUN 指令中,這樣可以形成一個可快取的執行單元,否則你可能會安裝舊的軟體包。

2. 減小映象體積

映象的體積很重要,因為映象越小,部署的速度更快,攻擊範圍越小。

刪除不必要依賴

刪除不必要的依賴,不要安裝除錯工具。如果實在需要除錯工具,可以在容器執行之後再安裝。某些包管理工具(如 apt

)除了安裝使用者指定的包之外,還會安裝推薦的包,這會無緣無故增加映象的體積。apt 可以通過新增引數 -–no-install-recommends 來確保不會安裝不需要的依賴項。如果確實需要某些依賴項,請在後面手動新增。

刪除包管理工具的快取

包管理工具會維護自己的快取,這些快取會保留在映象檔案中,推薦的處理方法是在每一個 RUN 指令的末尾刪除快取。如果你在下一條指令中刪除快取,不會減小映象的體積。

當然了,還有其他更高階的方法可以用來減小映象體積,如下文將會介紹的多階段構建。接下來我們將探討如何優化 Dockerfile 的可維護性、安全性和可重複性。

3. 可維護性

儘量使用官方映象

使用官方映象可以節省大量的維護時間,因為官方映象的所有安裝步驟都使用了最佳實踐。如果你有多個專案,可以共享這些映象層,因為他們都可以使用相同的基礎映象。

使用更具體的標籤

基礎映象儘量不要使用 latest 標籤。雖然這很方便,但隨著時間的推移,latest 映象可能會發生重大變化。因此在 Dockerfile 中最好指定基礎映象的具體標籤。我們使用 openjdk 作為示例,指定標籤為 8。其他更多標籤請檢視官方倉庫。

使用體積最小的基礎映象

基礎映象的標籤風格不同,映象體積就會不同。slim 風格的映象是基於 Debian 發行版製作的,而 alpine 風格的映象是基於體積更小的 Alpine Linux 發行版製作的。其中一個明顯的區別是:Debian 使用的是 GNU 專案所實現的 C 語言標準庫,而 Alpine 使用的是 Musl C 標準庫,它被設計用來替代 GNU C 標準庫(glibc)的替代品,用於嵌入式作業系統和移動裝置。因此使用 Alpine 在某些情況下會遇到相容性問題。 以 openjdk 為例,jre 風格的映象只包含 Java 執行時,不包含 SDK,這麼做也可以大大減少映象體積。

4. 重複利用

到目前為止,我們一直都在假設你的 jar 包是在主機上構建的,這還不是理想方案,因為沒有充分利用容器提供的一致性環境。例如,如果你的 Java 應用依賴於某一個特定的作業系統的庫,就可能會出現問題,因為環境不一致(具體取決於構建 jar 包的機器)。

在一致的環境中從原始碼構建

原始碼是你構建 Docker 映象的最終來源,Dockerfile 裡面只提供了構建步驟。

首先應該確定構建應用所需的所有依賴,本文的示例 Java 應用很簡單,只需要 Maven 和 JDK,所以基礎映象應該選擇官方的體積最小的 maven 映象,該映象也包含了 JDK。如果你需要安裝更多依賴,可以在 RUN 指令中新增。pom.xml檔案和 src 資料夾需要被複制到映象中,因為最後執行 mvn package 命令(-e 引數用來顯示錯誤,-B 引數表示以非互動式的“批處理”模式執行)打包的時候會用到這些依賴檔案。

雖然現在我們解決了環境不一致的問題,但還有另外一個問題:每次程式碼更改之後,都要重新獲取一遍 pom.xml 中描述的所有依賴項。下面我們來解決這個問題。

在單獨的步驟中獲取依賴項

結合前面提到的快取機制,我們可以讓獲取依賴項這一步變成可快取單元,只要 pom.xml 檔案的內容沒有變化,無論程式碼如何更改,都不會破壞這一層的快取。上圖中兩個 COPY 指令中間的 RUN 指令用來告訴 Maven 只獲取依賴項。

現在又遇到了一個新問題:跟之前直接拷貝 jar 包相比,映象體積變得更大了,因為它包含了很多執行應用時不需要的構建依賴項。

使用多階段構建來刪除構建時的依賴項

多階段構建可以由多個 FROM 指令識別,每一個 FROM 語句表示一個新的構建階段,階段名稱可以用 AS 引數指定。本例中指定第一階段的名稱為 builder,它可以被第二階段直接引用。兩個階段環境一致,並且第一階段包含所有構建依賴項。

第二階段是構建最終映象的最後階段,它將包括應用執行時的所有必要條件,本例是基於 Alpine 的最小 JRE 映象。上一個構建階段雖然會有大量的快取,但不會出現在第二階段中。為了將構建好的 jar 包新增到最終的映象中,可以使用 COPY --from=STAGE_NAME 指令,其中 STAGE_NAME 是上一構建階段的名稱。

多階段構建是刪除構建依賴的首選方案。

本文從在非一致性環境中構建體積較大的映象開始優化,一直優化到在一致性環境中構建最小映象,同時充分利用了快取機制。下一篇文章將會介紹多階段構建的更多其他用途。