如何解決Docker鏡像體積太大問題

這篇文章主要為大家展示了“如何解決Docker鏡像體積太大問題”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“如何解決Docker鏡像體積太大問題”這篇文章吧。

虛擬機的問題

最初，大家都使用虛擬機作為軟件的運行環境，對外提供服務。為了在虛擬機上運行你的 Service，你不得不運行一大堆程序：

系統進程
定時任務
SSH
安裝 Agent
安裝 Bash
安裝一大堆 libs

其實，你僅僅只是想讓你的 Service運行起來，但你不得不維護一個 40GB的虛擬機。

然后你開始試用 Docker

開始試用 Docker，你毫不猶豫選擇了和之前虛擬機一樣的鏡像：Ubuntu 1404，將之前的虛機的內容復制到了 Docker鏡像，安裝了一堆軟件，最后發現你的 Docker鏡像有 8GB。

谷歌的 Docker鏡像構建實踐

找到最小的基礎鏡像

Alpine Linux是基于 musl和 BusyBox的操作系統，目的是為了為用戶提供更高效的資源使用效率。它的特性是體積小，最小的 Alpine Linux體積可以只有 5MB。谷歌某些團隊使用 Alpine Linux作為 Docker Build的基礎鏡像。

目的：僅僅為了運行 Service

谷歌認為，為了運行一個 Service，并不需要將那些無關聯的包、程序打包到容器里，換句話說，Docker鏡像里只留下需要用到的，其他的都刪除，從而得到一個最小的鏡像。這需要考慮以下幾點：

1、程序編譯后的二進制文件（從 Artifactory獲?。?/p>

2、程序的所有依賴（從 Artifactory獲?。?/p>

3、程序語言的運行時（libc，JRE，node，…）

4、任何程序和 Kernel之間的中間件

其實這一切的信息，構建工具都已經知道。

谷歌的構建工具 Bazel

介紹 Bazel之前，先介紹下谷歌的開發模式，對于服務器端代碼庫，谷歌的開發流程如下：

1、所有的服務器端代碼庫都在一個巨大的版本控制系統里

2、每個人都用 Bazel構建軟件

3、不同的組負責源碼樹的不同部分，所有的組件都是作為 BUILD目標來用

4、分支主要是用來管理發布，所以每個人都在最新版本上開發軟件

Bazel（https://bazel.build/）是 Google內部用來構建自己的服務器端軟件的工具。目前變成谷歌公司貢獻的一個開源項目，目的是幫助開發者將軟件的構建和測試變得更快、更可靠。

從上圖可以看到，Bazel有 WORDSPACE的概念，WORDSPACE文件用來準備 Docker鏡像構建所依賴的所有材料和來源。BUILD文件用來告訴 Bazel這個鏡像應該使用什么命令進行構建，以及如何構建、如何測試。

使用 Bazel的聲明式語言: WORKSPACE和 BUILD，開發者可以用文件描述整個構建和部署的環境。谷歌使用 Bazel進行 Docker的構建已經很多年，它為谷歌帶來以下收益：

1、支持跨平臺構建，分布式緩存，優化依賴解析，并行構建，增量構建。

2、支持多語言（Java, C++, Android, iOS, Go等等）。

3、跨平臺。

4、水平擴展和自定義擴展。

Bazel是以下理念的奠基石：由于 Bazel需要所有的依賴都被完整地指定，我們可以預測改動影響了哪些程序和測試，并在提交前執行他們。

谷歌提供的 Distroless鏡像構建文件

Distroless (https://github.com/GoogleCloudPlatform/distroless)是谷歌內部使用的鏡像構建文件，包括 Java、Node、Python等鏡像構建文件，Distroless僅僅只包含運行服務所需要的最小鏡像，不包含包管理工具、shell命令行等其他功能。

為什么你需要這些鏡像？這些鏡像是谷歌和其他大公司的最佳實踐的產物，經過了漏洞掃描，鏡像會持續更新，保持安全性。

如何使用？Distroless提供的構建鏡像的 BUILD文件，通過 Bazel可以直接進行構建。

谷歌為大家介紹了內部如何解決鏡像過大的問題，以及進行大規模并發構建、測試所用到的構建工具 Bazel，并且開源了 Docker鏡像構建文件 Distroless項目。如果你認為你的鏡像也存在體積太大的問題，可以參考谷歌的實踐，體驗他們的工具。

以上是“如何解決Docker鏡像體積太大問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！