作者 | The Agile Crafter
策劃 | 田曉旭
Docker 是一個供軟體開發人員和系統管理者使用容器建構、運作和與分享應用程式的平台。容器是在獨立環境中運作的程序，它運作在自己的檔案系統上，該檔案系統是使用 docker 鏡像建構的。鏡像中包含運作應用程式所需的一切（編譯後的代碼、依賴項、庫等等）。鏡像使用 Dockerfile 檔案定義。
術語 dockerization 或 containerization 通常用于定義建立 Docker 容器的過程。
因為容器具備如下優點，是以很受歡迎：
靈活性：即使是最複雜的應用程式也可以容器化。
輕量化：容器共享主機核心，使得它們遠比虛拟機高效。
便攜性：可以做到本地編譯，到處運作。
松耦合：容器自我封裝，一個容器被替換或更新不會打斷别的容器。
安全性：容器對程序進行了嚴格的限制和隔離，而無需使用者進行任何配置。
在這篇文章中，我将重點讨論如何優化 Docker 鏡像以使其輕量化。
讓我們從一個示例開始，在該示例中，我們建構了一個 React 應用程式并将其容器化。運作 npx 指令并建立 Dockerfile 之後，我們得到了如圖 1 所示的檔案結構。
圖 1：檔案結構
如果我們建構一個基礎的 Dockerfile（如下所示），我們最終會得到一個 1.16 GB 的鏡像：
圖 2：鏡像的初始大小為 1.16GB
第一步優化：使用輕量化基礎鏡像
在 Docker Hub（公共 Docker 倉庫）中，有一些鏡像可供下載下傳，每個鏡像都有不同的特征和大小。
通常，相較于基于其他 Linux 發行版（例如 Ubuntu）的鏡像，基于 Alpine 或 BusyBox 的鏡像非常小。這是因為 Alpine 鏡像和類似的其他鏡像都經過了優化，其中僅包含最少的必須的軟體包。在下面的圖檔中，你可以看到 Ubuntu、Alpine、Node 和基于 Alpine 的 Node 鏡像之間的大小比較。
圖 3：基礎鏡像的不同大小
通過修改 Dockerfile 并使用 Alpine 作為基礎鏡像，我們的鏡像最終大小為 330MB：
圖 4：經過第一步優化後鏡像大小為 330MB
第二步優化：多階段建構
通過多階段建構，我們可以在 Dockerfile 中使用多個基礎鏡像，并将編譯成品、配置檔案等從一個階段複制到另一個階段，這樣我們就可以丢棄不需要的東西。
在本例中，我們部署 React 應用程式需要的是編譯後的代碼，我們不需要源檔案，也不需要 node_modules 目錄和 package.json 檔案等。關注公衆号 逆鋒起筆，回複 pdf，下載下傳你需要的各種學習資料。
通過将 Dockerfile 修改為如下内容，我們最終得到的鏡像大小為 91.5MB。請記住，來自第一階段（第 1-4 行）的鏡像不會被自動删除，Docker 将它儲存在 cache 中，如果我們在另一個建構鏡像過程中執行了相同的階段，就可以使鏡像建構更快。是以你必須手動删除第一階段鏡像。
圖 5：第二步優化後的鏡像大小為 91.5MB
現在我們有了一個 Dockerfile，它有兩個階段：在第一個階段中，我們編譯項目，在第二個階段中，我們在 web 伺服器上部署應用程式。然而，Node 容器并不是提供網頁（HTML、CSS 和 JavaScript 檔案、圖檔等）服務的最佳選擇，最好的選擇是使用像 Nginx 或 Apache 這樣的服務。在本例中，我将使用 Nginx。
通過将 Dockerfile 修改為如下内容，我們的鏡像最終大小是 22.4MB，如果我們運作這個容器，我們可以看到網頁可以正常工作，沒有任何問題（圖 7）。
圖 6：第三步優化後的鏡像大小為 22.4MB
圖 7：最終容器的運作結果