docker 鏡像層的提取（解壓）docker pull必須按順序進行還是可以并行化？
例子
docker pull mirekphd/ml-cpu-r40-base- 出于構建性能原因，必須將映像拆分為 50 多個層 - 它包含大約 4k 個預編譯為 DEB 的 R 包（整個 CRAN 任務視圖內容），如果不將這些包拆分為多個，則無法在 docker 中構建大小大致相同的層，這將構建時間從一整天減少到幾分鐘。提取階段 - 如果并行化 - 最多可以提高 50 倍......
語境
當您觀察docker pull大型多層影像（大小為千兆位元組）時，您會注意到每一層的下載可以單獨并行執行。對于這些層中的每一層的后續提取（解焦），情況并非如此，這是按順序執行的。我們知道為什么嗎？
從我對如此大影像的軼事觀察來看，它會大大加快docker pull操作的執行速度。
此外，如果分支影像為多層會讓你旋轉起來集裝箱快，人們會開始寫DockerfileS中的可讀性更強，更快地都除錯/測驗pull/ run，而不是試圖堆積所有的指令到一個緩慢BULDING，不可能復雜和快取破壞的指令字串只是為了節省幾兆位元組的額外層開銷（這將很容易通過并行提取來彌補）。
uj5u.com熱心網友回復：
從https://github.com/moby/moby/issues/21814 上的討論來看，沒有并行提取層有兩個主要原因：
- 它不適用于所有存盤驅動程式。
- 它可能會使用大量 CPU。
請參閱下面的相關評論：
請注意，并非所有存盤驅動程式都能夠支持并行提取。有些是快照檔案系統，在應用下一層之前，必須提取第一層并對其進行快照。
@aaronlehmann
我們也不希望
pull在運行容器的主機上進行消耗大量 CPU的操作。@cpuguy83
關閉鏈接問題的用戶寫道：
由于技術原因，這不會發生。這里沒有討論的余地。AUFS 會支持這一點，但大多數其他存盤驅動程式不支持這一點。這還需要有特定的代碼來實作至少兩種不同的代碼路徑：一種具有這種并行提取，另一種沒有它。
影像基本上類似于此圖 A->B->C->D 并且大多數 Docker 存盤驅動程式無法處理依賴于尚未提取的層的任何層的提取。
如果你想加速 docker pull，你肯定想要更快的存盤和更快的網路。一旦 Go 1.7 發布并且我們開始使用它，Go 本身將有助于提高性能。
我現在將關閉它，因為從特定驅動程式的并行提取中獲得的任何收益都不值得代碼的復雜性、實作它所需的努力以及將來維護它所需的努力。
@unclejack
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/360322.html