歡迎光臨
每天分享高質量文章

如何打造更小巧的容器鏡像 | Linux 中國

五種優化 Linux 容器大小和構建更小的鏡像的方法。

— Chris Collins

Docker[1] 近幾年的爆炸性發展讓大家逐漸瞭解到容器和容器鏡像的概念。儘管 Linux 容器技術在很早之前就已經出現,但這項技術近來的蓬勃發展卻還是要歸功於 Docker 對用戶友好的命令列界面以及使用 Dockerfile 格式輕鬆構建鏡像的方式。縱然 Docker 大大降低了入門容器技術的難度,但構建一個兼具功能強大、體積小巧的容器鏡像的過程中,有很多技巧需要瞭解。

第一步:清理不必要的檔案

這一步和在普通服務器上清理檔案沒有太大的區別,而且要清理得更加仔細。一個小體積的容器鏡像在傳輸方面有很大的優勢,同時,在磁盤上儲存不必要的資料的多個副本也是對資源的一種浪費。因此,這些技術對於容器來說應該比有大量專用記憶體的服務器更加需要。

清理容器鏡像中的快取檔案可以有效縮小鏡像體積。下麵的對比是使用 dnf 安裝 Nginx[2] 構建的鏡像,分別是清理和沒有清理 yum 快取檔案的結果:

  1. # Dockerfile with cache
  2. FROM fedora:28
  3. LABEL maintainer Chris Collins <collins.[email protected].com>
  4. RUN dnf install -y nginx
  5. -----
  6. # Dockerfile w/o cache
  7. FROM fedora:28
  8. LABEL maintainer Chris Collins <collins.[email protected].com>
  9. RUN dnf install -y nginx \
  10. && dnf clean all \
  11. && rm -rf /var/cache/yum
  12. -----
  13. [[email protected]] $ docker build -t cache -f Dockerfile .
  14. [[email protected]] $ docker images --format "{{.Repository}}: {{.Size}}"
  15. | head -n 1
  16. cache: 464 MB
  17. [[email protected]] $ docker build -t no-cache -f Dockerfile-wo-cache .
  18. [[email protected]] $ docker images --format "{{.Repository}}: {{.Size}}" | head -n 1
  19. no-cache: 271 MB

從上面的結果來看,清理快取檔案的效果相當顯著。和清除了元資料和快取檔案的容器鏡像相比,不清除的鏡像體積接近前者的兩倍。除此以外,包管理器快取檔案、Ruby gem 的臨時檔案、nodejs 快取檔案,甚至是下載的原始碼 tarball 最好都全部清理掉。

層:一個潛在的隱患

很不幸(當你往下讀,你會發現這是不幸中的萬幸),根據容器中的層的概念,不能簡單地向 Dockerfile 中寫一句 RUN rm -rf /var/cache/yum 就完事兒了。因為 Dockerfile 的每一條命令都以一個層的形式儲存,並一層層地疊加。所以,如果你是這樣寫的:

  1. RUN dnf install -y nginx
  2. RUN dnf clean all
  3. RUN rm -rf /var/cache/yum

你的容器鏡像就會包含三層,而 RUN dnf install -y nginx 這一層仍然會保留著那些快取檔案,然後在另外兩層中被移除。但快取實際上仍然是存在的,當你把一個檔案系統掛載在另外一個檔案系統之上時,檔案仍然在那裡,只不過你見不到也訪問不到它們而已。

在上一節的示例中,你會看到正確的做法是將幾條命令鏈接起來,在產生快取檔案的同一條 Dockerfile 指令里把快取檔案清理掉:

  1. RUN dnf install -y nginx \
  2. && dnf clean all \
  3. && rm -rf /var/cache/yum

這樣就把幾條命令連成了一條命令,在最終的鏡像中只占用一個層。這樣只會浪費一點快取的好處,稍微多耗費一點點構建容器鏡像的時間,但被清理掉的快取檔案就不會留存在最終的鏡像中了。作為一個折衷方法,只需要把一些相關的命令(例如 yum install 和 yum clean all、下載檔案、解壓檔案、移除 tarball 等等)連接成一個命令,就可以在最終的容器鏡像中節省出大量體積,你也能夠利用 Docker 的快取加快開發速度。

層還有一個更隱蔽的特性。每一層都記錄了檔案的更改,這裡的更改並不僅僅已有的檔案累加起來,而是包括檔案屬性在內的所有更改。因此即使是對檔案使用了 chmod 操作也會被在新的層創建檔案的副本。

下麵是一次 docker images 命令的輸出內容。其中容器鏡像 layer_test_1 是在 CentOS 基礎鏡像中增加了一個 1GB 大小的檔案後構建出來的鏡像,而容器鏡像 layer_test_2 是使用了 FROM layer_test_1 陳述句創建出來的,除了執行一條 chmod u+x 命令沒有做任何改變。

  1. layer_test_2 latest e11b5e58e2fc 7 seconds ago 2.35 GB
  2. layer_test_1 latest 6eca792a4ebe 2 minutes ago 1.27 GB

如你所見,layer_test_2 鏡像比 layer_test_1 鏡像大了 1GB 以上。儘管事實上 layer_test_1 只是 layer_test_2 的前一層,但隱藏在這第二層中有一個額外的 1GB 的檔案。在構建容器鏡像的過程中,如果在單獨一層中進行移動、更改、刪除檔案,都會出現類似的結果。

專用鏡像和公用鏡像

有這麼一個親身經歷:我們部門重度依賴於 Ruby on Rails[3],於是我們開始使用容器。一開始我們就建立了一個正式的 Ruby 的基礎鏡像供所有的團隊使用,為了簡單起見(以及在“這就是我們自己在服務器上瞎鼓搗的”想法的指導下),我們使用 rbenv[4] 將 Ruby 最新的 4 個版本都安裝到了這個鏡像當中,目的是讓開發人員只用這個單一的鏡像就可以將使用不同版本 Ruby 的應用程式遷移到容器中。我們當時還認為這是一個雖然非常大但兼容性相當好的鏡像,因為這個鏡像可以同時滿足各個團隊的使用。

實際上這是費力不討好的。如果維護獨立的、版本略微不同的鏡像中,可以很輕鬆地實現鏡像的自動化維護。同時,選擇特定版本的特定鏡像,還有助於在引入破壞性改變,在應用程式接近生命周期結束前提前做好預防措施,以免產生不可控的後果。龐大的公用鏡像也會對資源造成浪費,當我們後來將這個龐大的鏡像按照 Ruby 版本進行拆分之後,我們最終得到了共享一個基礎鏡像的多個鏡像,如果它們都放在一個服務器上,會額外多占用一點空間,但是要比安裝了多個版本的巨型鏡像要小得多。

這個例子也不是說構建一個靈活的鏡像是沒用的,但僅對於這個例子來說,從一個公共鏡像創建根據用途而構建的鏡像最終將節省儲存資源和維護成本,而在受益於公共基礎鏡像的好處的同時,每個團隊也能夠根據需要來做定製化的配置。

從零開始:將你需要的內容添加到空白鏡像中

有一些和 Dockerfile 一樣易用的工具可以輕鬆創建非常小的兼容 Docker 的容器鏡像,這些鏡像甚至不需要包含一個完整的操作系統,就可以像標準的 Docker 基礎鏡像一樣小。

我曾經寫過一篇關於 Buildah 的文章[5],我想在這裡再一次推薦一下這個工具。因為它足夠的靈活,可以使用宿主機上的工具來操作一個空白鏡像並安裝打包好的應用程式,而且這些工具不會被包含到鏡像當中。

Buildah 取代了 docker build 命令。可以使用 Buildah 將容器的檔案系統掛載到宿主機上併進行交互。

下麵來使用 Buildah 實現上文中 Nginx 的例子(現在忽略了快取的處理):

  1. #!/usr/bin/env bash
  2. set -o errexit
  3. # Create a container
  4. container=$(buildah from scratch)
  5. # Mount the container filesystem
  6. mountpoint=$(buildah mount $container)
  7. # Install a basic filesystem and minimal set of packages, and nginx
  8. dnf install --installroot $mountpoint --releasever 28 glibc-minimal-langpack nginx --setopt install_weak_deps=false -y
  9. # Save the container to an image
  10. buildah commit --format docker $container nginx
  11. # Cleanup
  12. buildah unmount $container
  13. # Push the image to the Docker daemons storage
  14. buildah push nginx:latest docker-daemon:nginx:latest

你會發現這裡使用的已經不再是 Dockerfile 了,而是普通的 Bash 腳本,而且是從框架(或空白)鏡像開始構建的。上面這段 Bash 腳本將容器的根檔案系統掛載到了宿主機上,然後使用宿主機的命令來安裝應用程式,這樣的話就不需要把軟體包管理器放置到容器鏡像中了。

這樣所有無關的內容(基礎鏡像之外的部分,例如 dnf)就不再會包含在鏡像中了。在這個例子當中,構建出來的鏡像大小隻有 304 MB,比使用 Dockerfile 構建的鏡像減少了 100 MB 以上。

  1. [[email protected]] $ docker images |grep nginx
  2. docker.io/nginx buildah 2505d3597457 4 minutes ago 304 MB

註:這個鏡像是使用上面的構建腳本構建的,鏡像名稱中前綴的 docker.io 只是在推送到鏡像倉庫時加上的。

對於一個 300MB 級別的容器基礎鏡像來說,能縮小 100MB 已經是很顯著的節省了。使用軟體包管理器來安裝 Nginx 會帶來大量的依賴項,如果能夠使用宿主機直接從原始碼對應用程式進行編譯然後構建到容器鏡像中,節省出來的空間還可以更多,因為這個時候可以精細的選用必要的依賴項,非必要的依賴項一概不構建到鏡像中。

Tom Sweeney[6] 有一篇文章《用 Buildah 構建更小的容器[7]》,如果你想在這方面做深入的優化,不妨參考一下。

通過 Buildah 可以構建一個不包含完整操作系統和代碼編譯工具的容器鏡像,大幅縮減了容器鏡像的體積。對於某些型別的鏡像,我們可以進一步採用這種方式,創建一個只包含應用程式本身的鏡像。

使用靜態鏈接的二進制檔案來構建鏡像

按照這個思路,我們甚至可以更進一步捨棄容器內部的管理和構建工具。例如,如果我們足夠專業,不需要在容器中進行排錯除錯,是不是可以不要 Bash 了?是不是可以不要 GNU 核心套件[8]了?是不是可以不要 Linux 基礎檔案系統了?如果你使用的編譯型語言支持靜態鏈接庫[9],將應用程式所需要的所有庫和函式都編譯成二進制檔案,那麼程式所需要的函式和庫都可以複製和儲存在二進制檔案本身裡面。

這種做法在 Golang[10] 社區中已經十分常見,下麵我們使用由 Go 語言編寫的應用程式進行展示:

以下這個 Dockerfile 基於 golang:1.8 鏡像構建一個小的 Hello World 應用程式鏡像:

  1. FROM golang:1.8
  2. ENV GOOS=linux
  3. ENV appdir=/go/src/gohelloworld
  4. COPY ./ /go/src/goHelloWorld
  5. WORKDIR /go/src/goHelloWorld
  6. RUN go get
  7. RUN go build -o /goHelloWorld -a
  8. CMD ["/goHelloWorld"]

構建出來的鏡像中包含了二進制檔案、原始碼以及基礎鏡像層,一共 716MB。但對於應用程式運行唯一必要的只有編譯後的二進制檔案,其餘內容在鏡像中都是多餘的。

如果在編譯的時候通過指定引數 CGO_ENABLED=0 來禁用 cgo,就可以在編譯二進制檔案的時候忽略某些函式的 C 語言庫:

  1. GOOS=linux CGO_ENABLED=0 go build -a goHelloWorld.go

編譯出來的二進制檔案可以加到一個空白(或框架)鏡像:

  1. FROM scratch
  2. COPY goHelloWorld /
  3. CMD ["/goHelloWorld"]

來看一下兩次構建的鏡像對比:

  1. [ [email protected] ] $ docker images
  2. REPOSITORY TAG IMAGE ID CREATED SIZE
  3. goHello scratch a5881650d6e9 13 seconds ago 1.55 MB
  4. goHello builder 980290a100db 14 seconds ago 716 MB

從鏡像體積來說簡直是天差地別了。基於 golang:1.8 鏡像構建出來帶有 goHelloWorld 二進制的鏡像(帶有 builder 標簽)體積是基於空白鏡像構建的只包含該二進制檔案的鏡像的 460 倍!後者的整個鏡像大小隻有 1.55MB,也就是說,有 713MB 的資料都是非必要的。

正如上面提到的,這種縮減鏡像體積的方式在 Golang 社區非常流行,因此不乏這方面的文章。Kelsey Hightower[11] 有一篇文章[12]專門介紹瞭如何處理這些庫的依賴關係。

壓縮鏡像層

除了前面幾節中講到的將多個命令鏈接成一個命令的技巧,還可以對鏡像進行壓縮。鏡像壓縮的實質是匯出它,刪除掉鏡像構建過程中的所有中間層,然後儲存鏡像的當前狀態為單個鏡像層。這樣可以進一步將鏡像縮小到更小的體積。

在 Docker 1.13 之前,壓縮鏡像層的的過程可能比較麻煩,需要用到 docker-squash 之類的工具來匯出容器的內容並重新匯入成一個單層的鏡像。但 Docker 在 Docker 1.13 中引入了 --squash 引數,可以在構建過程中實現同樣的功能:

  1. FROM fedora:28
  2. LABEL maintainer Chris Collins <collins.[email protected].com>
  3. RUN dnf install -y nginx
  4. RUN dnf clean all
  5. RUN rm -rf /var/cache/yum
  6. [[email protected]] $ docker build -t squash -f Dockerfile-squash --squash .
  7. [[email protected]] $ docker images --format "{{.Repository}}: {{.Size}}" | head -n 1
  8. squash: 271 MB

通過這種方式使用 Dockerfile 構建出來的鏡像有 271MB 大小,和上面連接多條命令的方案構建出來的鏡像體積一樣,因此這個方案也是有效的,但也有一個潛在的問題,而且是另一種問題。

“什麼?還有另外的問題?”

好吧,有點像以前一樣的問題,以另一種方式引發了問題。

過頭了:過度壓縮、太小太專用了

容器鏡像之間可以共享鏡像層。基礎鏡像或許大小上有幾 Mb,但它只需要拉取/儲存一次,並且每個鏡像都能復用它。所有共享基礎鏡像的實際鏡像大小是基礎鏡像層加上每個特定改變的層的差異內容,因此,如果有數千個基於同一個基礎鏡像的容器鏡像,其體積之和也有可能只比一個基礎鏡像大不了多少。

因此,這就是過度使用壓縮或專用鏡像層的缺點。將不同鏡像壓縮成單個鏡像層,各個容器鏡像之間就沒有可以共享的鏡像層了,每個容器鏡像都會占有單獨的體積。如果你只需要維護少數幾個容器鏡像來運行很多容器,這個問題可以忽略不計;但如果你要維護的容器鏡像很多,從長遠來看,就會耗費大量的儲存空間。

回顧上面 Nginx 壓縮的例子,我們能看出來這種情況並不是什麼大的問題。在這個鏡像中,有 Fedora 操作系統和 Nginx 應用程式,沒有快取,並且已經被壓縮。但我們一般不會使用一個原始的 Nginx,而是會修改配置檔案,以及引入其它代碼或應用程式來配合 Nginx 使用,而要做到這些,Dockerfile 就變得更加複雜了。

如果使用普通的鏡像構建方式,構建出來的容器鏡像就會帶有 Fedora 操作系統的鏡像層、一個安裝了 Nginx 的鏡像層(帶或不帶快取)、為 Nginx 作自定義配置的其它多個鏡像層,而如果有其它容器鏡像需要用到 Fedora 或者 Nginx,就可以復用這個容器鏡像的前兩層。

  1. [ App 1 Layer ( 5 MB) ] [ App 2 Layer (6 MB) ]
  2. [ Nginx Layer ( 21 MB) ] ------------------^
  3. [ Fedora Layer (249 MB) ]

如果使用壓縮鏡像層的構建方式,Fedora 操作系統會和 Nginx 以及其它配置內容都被壓縮到同一層裡面,如果有其它容器鏡像需要使用到 Fedora,就必須重新引入 Fedora 基礎鏡像,這樣每個容器鏡像都會額外增加 249MB 的大小。

  1. [ Fedora + Nginx + App 1 (275 MB)] [ Fedora + Nginx + App 2 (276 MB) ]

當你構建了大量在功能上趨於分化的的小型容器鏡像時,這個問題就會暴露出來了。

就像生活中的每一件事一樣,關鍵是要做到適度。根據鏡像層的實現原理,如果一個容器鏡像變得越小、越專用化,就越難和其它容器鏡像共享基礎的鏡像層,這樣反而帶來不好的效果。

對於僅在基礎鏡像上做微小變動構建出來的多個容器鏡像,可以考慮共享基礎鏡像層。如上所述,一個鏡像層本身會帶有一定的體積,但只要存在於鏡像倉庫中,就可以被其它容器鏡像復用。這種情況下,數千個鏡像也許要比單個鏡像占用更少的空間。

  1. [ specific app ] [ specific app 2 ]
  2. [ customizations ]--------------^
  3. [ base layer ]

一個容器鏡像變得越小、越專用化,就越難和其它容器鏡像共享基礎的鏡像層,最終會不必要地占用越來越多的儲存空間。

  1. [ specific app 1 ] [ specific app 2 ] [ specific app 3 ]

總結

減少處理容器鏡像時所需的儲存空間和帶寬的方法有很多,其中最直接的方法就是減小容器鏡像本身的大小。在使用容器的過程中,要經常留意容器鏡像是否體積過大,根據不同的情況採用上述提到的清理快取、壓縮到一層、將二進制檔案加入在空白鏡像中等不同的方法,將容器鏡像的體積縮減到一個有效的大小。


via: https://opensource.com/article/18/7/building-container-images

作者:Chris Collins[14] 選題:lujun9972 譯者:HankChow 校對:wxy

赞(0)

分享創造快樂