Google和Facebook中為什么不使用Docker

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)Google和Facebook中為什么不使用Docker，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Google 和 Facebook 都使用 monolithic repository，也都有自己的 build systems（我這篇老文尋找 Google Blaze[2] 解釋過(guò) Google 的 build system）所以不需要“包”，當(dāng)然也就不需要 Docker images。

不過(guò) Borg 和 Tupperware 都是有 container 的（使用 Linux kernel 提供的一些 system calls，比如 Google Borg 團(tuán)隊(duì)十多年前貢獻(xiàn)給 Linux kernel 的 cgroup）來(lái)實(shí)現(xiàn) jobs 之間的隔離。

只是因?yàn)槿绻恍枰蠹?build Docker image 了，那么 container 的存在就不容易被關(guān)注到了。

如果不想被上述蔽之，而要細(xì)究這個(gè)問(wèn)題，那就待我一層一層剝開 Google 和 Facebook 的研發(fā)技術(shù)體系和計(jì)算技術(shù)體系。

Packaging

當(dāng)我們提交一個(gè)分布式作業(yè)（job）到集群上去執(zhí)行，我們得把要執(zhí)行的程序（包括一個(gè)可執(zhí)行文件以及相關(guān)的文件，比如 *.so，*.py）傳送到調(diào)度系統(tǒng)分配給這個(gè) job 的一些機(jī)器（節(jié)點(diǎn)、nodes）上去。

這些待打包的文件是怎么來(lái)的呢？當(dāng)時(shí)是 build 出來(lái)的。在 Google 里有 Blaze，在 Facebook 里有 Buck。

感興趣的朋友們可以看看 Google Blaze 的“開源版本”Bazel[3]，以及 Facebook Buck 的開源版本[4]。

不過(guò)提醒在先：Blaze 和 Facebook Buck 的內(nèi)部版都是用于 monolithic repo 的，而開源版本都是方便大家使用非 mono repos 的，所以理念和實(shí)現(xiàn)上有不同，不過(guò)基本使用方法還是可以感受一下的。

假設(shè)我們有如下模塊依賴（module dependencies），用 Buck 或者 Bazel 語(yǔ)法描述（兩者語(yǔ)法幾乎一樣）：

python_binary(name="A", srcs=["A.py"], deps=["B", "C"], ...)
python_library(name="B", srcs=["B.py"], deps=["D"], ...)
python_library(name="C", srcs=["C.py"], deps=["E"], ...)
cxx_library(name="D", srcs=["D.cxx", "D.hpp"], deps="F", ...)
cxx_library(name="E", srcs=["E.cxx", "E.hpp"], deps="F", ...)

那么模塊（build 結(jié)果）依賴關(guān)系如下：

A.py --> B.py --> D.so -\
     \-> C.py --> E.so --> F.so

如果是開源項(xiàng)目，請(qǐng)自行腦補(bǔ)，把上述模塊（modules）替換成 GPT-3，PyTorch，cuDNN，libc++ 等項(xiàng)目（projects）。

當(dāng)然，每個(gè) projects 里包含多個(gè) modules 也依賴其他 projects，就像每個(gè) module 有多個(gè)子 modules 一樣。

Tarball

最簡(jiǎn)單的打包方式就是把上述文件 {A,B,C}.py, {D,E,F}.so 打包成一個(gè)文件 A.zip，或者 A.tar.gz。

更嚴(yán)謹(jǐn)?shù)恼f(shuō)，文件名里應(yīng)該包括版本號(hào)。比如 A-953bc.zip，其中版本號(hào) 953bc 是 git/Mercurial commit ID。

引入版本號(hào)，可以幫助在節(jié)點(diǎn)本地 cache，下次運(yùn)行同一個(gè) tarball 的時(shí)候，就不需要下載這個(gè)文件了。

請(qǐng)注意這里我引入了 package caching 的概念。為下文解釋 Docker 預(yù)備。

XAR

ZIP 或者 tarball 文件拷貝到集群節(jié)點(diǎn)上之后，需要解壓縮到本地文件系統(tǒng)的某個(gè)地方，比如：/var/packages/A-953bc/{A,B,C}.py,{D,E,F}.so。

一個(gè)稍顯酷炫的方式是不用 Tarball，而是把上述文件放在一個(gè) overlay filesystem 的 loopback device image 里。這樣“解壓”就變成了“mount”。

請(qǐng)注意這里我引入了 loopback device image 的概念。為下文解釋 Docker 預(yù)備。

什么叫 loopback device image 呢？在 Unix 里，一個(gè)目錄樹的文件們被稱為一個(gè)文件系統(tǒng)（filesystem）。

通常一個(gè) filesystem 存儲(chǔ)在一個(gè) block device 上。什么是 block device 呢？

簡(jiǎn)單的說(shuō)，但凡一個(gè)存儲(chǔ)空間可以被看作一個(gè) byte array 的，就是一個(gè) block device。

比如一塊硬盤就是一個(gè) block device。在一個(gè)新買的硬盤里創(chuàng)建一個(gè)空的目錄樹結(jié)構(gòu)的過(guò)程，就叫做格式化（format）。

既然 block device 只是一個(gè) byte array，那么一個(gè)文件不也是一個(gè) byte array 嗎？

是的！在 Unix 的世界里，我們完全可以創(chuàng)建一個(gè)固定大小的空文件（用 truncate 命令），然后“格式化”這個(gè)文件，在里面創(chuàng)建一個(gè)空的文件系統(tǒng)。然后把上述文件 {A,B,C}.py,{D,E,F}.so 放進(jìn)去。

比如 Facebook 開源的 XAR 文件[5]格式。這是和 Buck 一起使用的。

如果我們運(yùn)行 buck build A 就會(huì)得到 A.xar . 這個(gè)文件包括一個(gè) header，以及一個(gè) squashfs loopback device image，簡(jiǎn)稱 squanshfs image。

這里 squashfs 是一個(gè)開源文件系統(tǒng)。感興趣的朋友們可以參考這個(gè)教程[6]，創(chuàng)建一個(gè)空文件，把它格式化成 squashfs，然后 mount 到本地文件系統(tǒng)的某個(gè)目錄（mount point）里。

待到我們 umount 的時(shí)候，曾經(jīng)加入到 mount point 里的文件，就留在這個(gè)“空文件”里了。

我們可以把它拷貝分發(fā)給其他人，大家都可以 mount 之，看到我們加入其中的文件。

因?yàn)?XAR 是在 squashfs image 前面加上了一個(gè) header，所以沒(méi)法用 mount -t squashf 命令來(lái) mount，得用 mount -t xar 或者 xarexec -m 命令。

比如，一個(gè)節(jié)點(diǎn)上如果有了 /packages/A-953bc.xar，我們可以用如下命令看到它的內(nèi)容，而不需要耗費(fèi) CPU 資源來(lái)解壓縮：

xarexec -m A-953bc.xar

這個(gè)命令會(huì)打印出一個(gè)臨時(shí)目錄，是 XAR 文件的 mount point。

分層

如果我們現(xiàn)在修改了 A.py，那么不管是 build 成 tarball 還是 XAR，整個(gè)包都需要重新更新。

當(dāng)然，只要 build system 支持 cache，我們是不需要重新生成各個(gè) *.so 文件的。

但是這個(gè)不解決我們需要重新分發(fā) .tar.gz 和 .xar 文件到集群的各個(gè)節(jié)點(diǎn)的麻煩。

之前節(jié)點(diǎn)上可能有老版本的 A-953bc87fe.{tar.gz,xar} 了，但是不能復(fù)用。為了復(fù)用 ，需要分層。

對(duì)于上面情況，我們可以根據(jù)模塊依賴關(guān)系圖，構(gòu)造多個(gè) XAR 文件。

A-953bc.xar --> B-953bc.xar --> D-953bc.xar -\
            \-> C-953bc.xar --> E-953bc.xar --> F-953bc.xar

其中每個(gè) XAR 文件里只有對(duì)應(yīng)的 build rule 產(chǎn)生的文件。比如，F(xiàn)-953bc.xar 里只有 F.so。

這樣，如果我們只修改了 A.py，則只有 A.xar 需要重新 build 和傳送到集群節(jié)點(diǎn)上。這個(gè)節(jié)點(diǎn)可以復(fù)用之前已經(jīng) cache 了的 {B,C,D,E,F}-953bc.xar 文件。

假設(shè)一個(gè)節(jié)點(diǎn)上已經(jīng)有 /packages/{A,B,C,D,E,F}-953bc.xar，我們是不是可以按照模塊依賴順序，運(yùn)行 xarexec -m 命令，依次 mount 這些 XAR 文件到同一個(gè) mount point 目錄，既可得到其中所有的內(nèi)容了呢？

很遺憾，不行。因?yàn)楹笠粋€(gè) xarexec/mount 命令會(huì)報(bào)錯(cuò) —— 因?yàn)檫@個(gè) mount point 已經(jīng)被前一個(gè) xarexec/mount 命令占據(jù)了。

下面解釋為什么文件系統(tǒng) image 優(yōu)于 tarball。

那退一步，不用 XAR 了，用 ZIP 或者 tar.gz 不行嗎？可以，但是慢。我們可以把所有 .tar.gz 都解壓縮到同一個(gè)目錄里。

但是如果 A.py 更新了，我們沒(méi)法識(shí)別老的 A.py 并且替換為新的，而是得重新解壓所有 .tar.gz 文件，得到一個(gè)新的文件夾。而重新解壓所有的 {B,C,D,E,F}.tar.gz 很慢。

Overlay Filesystem

有一個(gè)申請(qǐng)的開源工具 fuse-overlayfs。它可以把幾個(gè)目錄“疊加”（overlay）起來(lái)。

比如下面命令把 /tmp/{A,B,C,D,E,F}-953bc 這幾個(gè)目錄里的內(nèi)容都“疊加”到 /pacakges/A-953bc 這個(gè)目錄里。

fuse-overlayfs -o \
  lowerdir="/tmp/A-953bc:/tmp/B-953bc:..." \
  /packages/A-953bc

而 /tmp/{A,B,C,D,E,F}-953bc 這幾個(gè)目錄來(lái)自 xarcexec -m /packages/{A,B,C,D,E,F}-953bc.xar。

請(qǐng)注意這里我引入了 overlay filesystem 的概念。為下文解釋 Docker 預(yù)備。fuse-overlayfs 是怎么做到這一點(diǎn)的呢？

當(dāng)我們?cè)L問(wèn)任何一個(gè)文件系統(tǒng)目錄，比如 /packages/A 的時(shí)候，我們使用的命令行工具（比如 ls ）調(diào)用 system calls（比如 open/close/read/write） 來(lái)訪問(wèn)其中的文件。

這些 system calls 和文件系統(tǒng)的 driver 打交道 —— 它們會(huì)問(wèn) driver：/packages/A 這個(gè)目錄里有沒(méi)有一個(gè)叫 A.py 的文件呀？

如果我們使用 Linux，一般來(lái)說(shuō)，硬盤上的文件系統(tǒng)是 ext4 或者 btrfs。也就是說(shuō)，Linux universal filesystem driver 會(huì)看看每個(gè)分區(qū)的文件系統(tǒng)是啥，然后把 system call 轉(zhuǎn)發(fā)給對(duì)應(yīng)的 ext4/btrfs driver 去處理。

一般的 filesystem drivers 和其他設(shè)備的 drivers 一樣運(yùn)行在 kernel mode 里。

這是為什么一般我們運(yùn)行 mount 和 umount 這類操作 filesystems 的命令的時(shí)候，都需要 sudo。而 FUSE 是一個(gè)在 userland 開發(fā) filesystem driver 的庫(kù)。

fuse-overlayfs 這命令利用 FUSE 這個(gè)庫(kù)，開發(fā)了一個(gè)運(yùn)行在 userland 的 fuse-overlayfs driver。

當(dāng) ls 命令詢問(wèn)這個(gè) overlayfs driver /packages/A-953bc 目錄里有啥的時(shí)候，這個(gè) fuse-overlayfs driver 記得之前用戶運(yùn)行過(guò) fuse-overlayfs 命令把 /tmp/{A,B,C,D,E}-953bc 這幾個(gè)目錄給疊加上去過(guò)，所以它返回這幾個(gè)目錄里的文件。

此時(shí)，因?yàn)?nbsp;/tmp/{A,B,C,D,E}-953bc 這幾個(gè)目錄其實(shí)是 /packages/{A,B,C,D,E,F}-953bc.xar 的 mount points，所以每個(gè) XAR 就相當(dāng)于一個(gè) layer。

像 fuse-overlayfs driver 這樣實(shí)現(xiàn)把多個(gè)目錄“疊加”起來(lái)的 filesystem driver 被稱為 overlay filesystem driver，有時(shí)簡(jiǎn)稱為 overlay filesystems。

Docker Image and Layer

上面說(shuō)到用 overlay filesystem 實(shí)現(xiàn)分層。用過(guò) Docker 的人都會(huì)熟悉一個(gè) Docker image 由多層構(gòu)成。

當(dāng)我們運(yùn)行 docker pull <image-name> 命令的時(shí)候，如果本機(jī)已經(jīng) cache 了這個(gè) image 的一部分 layers，則省略下載這些 layers。這其實(shí)就是用 overlay filesystem 實(shí)現(xiàn)的。

Docker 團(tuán)隊(duì)開發(fā)了一個(gè) filesystem（driver）叫做 overlayfs —— 這是一個(gè)特定的 filesystem 的名字。

顧名思義，Docker overlayfs 也實(shí)現(xiàn)了“疊加”（overlay）的能力，這就是我們看到每個(gè) Docker image 可以有多個(gè) layers 的原因。

Docker 的 overlayfs 以及它的后續(xù)版本 overlayfs2 都是運(yùn)行在 kernel mode 里的。

這也是 Docker 需要機(jī)器的 root 權(quán)限的原因之一，而這又是 Docker 被詬病容易導(dǎo)致安全漏斗的原因。

有一個(gè)叫 btrfs 的 filesystem，是 Linux 世界里最近幾年發(fā)展很迅速的，用于管理硬盤效果很好。

這個(gè) filesystem 的 driver 也支持 overlay。所以 Docker 也可以被配置為使用這個(gè) filesystem 而不是 overlayfs。

不過(guò)只有 Docker 用戶的電腦的 local filesystem 是 btrfs 的時(shí)候，Docker 才能用 btrfs 在上面疊加 layers。

所以說(shuō)，如果你用的是 macOS 或者 Windows，那肯定沒(méi)法讓 Docker 使用 btrfs 了。

不過(guò)如果你用的是 fuse-overlayfs，那就是用了一副萬(wàn)靈藥了。只是通過(guò) FUSE 在 userland 運(yùn)行的 filesystem 的性能很一般，不過(guò)本文討論的情形對(duì)性能也沒(méi)啥需求。

其實(shí) Docker 也可以被配置使用 fuse-overlayfs。Docker 支持的分層 filesystem 列表在這里 Docker storage drivers[7]。

為什么需要 Docker Image

總結(jié)上文所述，從編程到可以在集群上跑起來(lái)，我們要做幾個(gè)步驟：

1. 編譯：把源碼編譯成可執(zhí)行的形式。

2. 打包：把編譯結(jié)果納入一個(gè)“包”里，以便部署和分發(fā)

3. 傳輸：通常是集群管理系統(tǒng)（Borg、Kubernetes、Tupperware 來(lái)做）。如果要在某個(gè)集群節(jié)點(diǎn)上啟動(dòng) container，則需要把“包”傳輸?shù)酱斯?jié)點(diǎn)上，除非這個(gè)節(jié)點(diǎn)曾經(jīng)運(yùn)行過(guò)這個(gè)程序，已經(jīng)有包的 cache。

4. 解包：如果“包”是 tarball 或者 zip，到了集群節(jié)點(diǎn)上之后需要解壓縮；如果“包”是一個(gè) filesystem image，則需要 mount。

把源碼分成模塊，可以讓編譯這步充分利用每次修改只改動(dòng)一小部分代碼的特點(diǎn)，只重新編譯被修改的模塊，從而節(jié)省時(shí)間。

為了節(jié)省 2，3 和 4 的時(shí)間，我們希望“包”是分層的。每一層最好只包含一個(gè)或者幾個(gè)代碼模塊。這樣，可以利用模塊之間的依賴關(guān)系，盡量復(fù)用容納底層模塊的“層”。

在開源的世界里，我們用 Docker image 支持分層的特點(diǎn)，一個(gè)基礎(chǔ)層可能只包括某個(gè) Linux distribution（比如 CentOS）的 userland programs，如 ls、cat、grep 等。

在其上，可以有一個(gè)層包括 CUDA。再其上安裝 Python 和 PyTorch。再再之上的一層里是 GPT-3 模型的訓(xùn)練程序。

這樣，如果我們只是修改了 GPT-3 訓(xùn)練程序，則不需要重新打包和傳輸下面三層。

這里的邏輯核心是：存在“項(xiàng)目”（project）的概念。每個(gè)項(xiàng)目可以有自己的 repo，自己的 building system（GNU make、CMake、Buck、Bazel 等），自己的發(fā)行版本（release）。

所以每個(gè)項(xiàng)目的 release 裝進(jìn) Docker image 的一層 layer。與其前置多層合稱為一個(gè) image。

為什么 Google 和 Facebook 不需要 Docker

經(jīng)過(guò)上述這么多知識(shí)準(zhǔn)備，請(qǐng)我們終于可以點(diǎn)題了。

因?yàn)?Google 和 Facebook 使用 monolithic repository，使用統(tǒng)一的 build system（Google Blaze 或者 Facebook Buck）。

雖然也可以利用“項(xiàng)目”的概念，把每個(gè)項(xiàng)目的 build result 裝入 Docker image 的一層。但是實(shí)際上并不需要。

利用 Blaze 和 Buck 的 build rules 定義的模塊，以及模塊之間依賴關(guān)系，我們可以完全去打包和解包的概念。

沒(méi)有了包，當(dāng)然就不需要 zip、tarball、以及 Docker image 和 layers 了。

直接把每個(gè)模塊當(dāng)做一個(gè) layer 既可。如果 D.so 因?yàn)槲覀冃薷牧?D.cpp 被重新編譯，那么只重新傳輸 D.so 既可，而不需要去傳輸一個(gè) layer 其中包括 D.so。

于是，在 Google 和 Facebook 里，受益于 monolithic repository 和統(tǒng)一的 build 工具。

我們把上述四個(gè)步驟省略成了兩個(gè)：

1. 編譯：把源碼編譯成可執(zhí)行的形式。
   

2. 傳輸：如果某個(gè)模塊被重新編譯，則傳輸這個(gè)模塊。
   

Google 和 Facebook 沒(méi)在用 Docker

上一節(jié)說(shuō)了 monolithic repo 可以讓 Google 和 Facebook 不需要 Docker image。

現(xiàn)實(shí)是 Google 和 Facebook 沒(méi)有在使用 Docker。這兩個(gè)概念有區(qū)別。

我們先說(shuō)“沒(méi)在用”。歷史上，Google 和 Facebook 使用超大規(guī)模集群先于 Docker 和 Kubernetes 的出現(xiàn)。當(dāng)時(shí)為了打包方便，連 tarball 都沒(méi)有。

對(duì)于 C/C++ 程序，直接全靜態(tài)鏈接，根本沒(méi)有 *.so。于是一個(gè) executable binary file 就是“包”了。

直到今天，大家用開源的 Bazel 和 Buck 的時(shí)候，仍然可以看到默認(rèn)鏈接方式就是全靜態(tài)鏈接。

Java 語(yǔ)言雖然是一種“全動(dòng)態(tài)鏈接”的語(yǔ)言，不過(guò)其誕生和演進(jìn)扣準(zhǔn)了互聯(lián)網(wǎng)歷史機(jī)遇，其開發(fā)者發(fā)明 jar 文件格式，從而支持了全靜態(tài)鏈接。

Python 語(yǔ)言本身沒(méi)有 jar 包，所以 Blaze 和 Bazel 發(fā)明了 PAR 文件格式（英語(yǔ)叫 subpar），相當(dāng)于為 Python 設(shè)計(jì)了一個(gè) jar。開源實(shí)現(xiàn)在這里[8]。

類似的，Buck 發(fā)明了 XAR 格式，也就是我上文所說(shuō)的 squashfs image 前面加了一個(gè) header。其開源實(shí)現(xiàn)在這里[9]。

Go 語(yǔ)言默認(rèn)就是全靜態(tài)鏈接的。在 Rob Pike 早期的一些總結(jié)里提到，Go 的設(shè)計(jì)，包括全靜態(tài)鏈接，基本就是繞坑而行，繞開 Google C/C++ 實(shí)踐中遇到過(guò)的各種坑。

熟悉 Google C++ style guide 的朋友們應(yīng)該感覺(jué)到了 Go 語(yǔ)法覆蓋了 guide 說(shuō)的“應(yīng)該用的 C++ 語(yǔ)法”，而不支持 guide 說(shuō)的 “不應(yīng)該用的 C++ 的部分”。

簡(jiǎn)單的說(shuō)，歷史上 Google 和 Facebook 沒(méi)有在用 Docker image，很重要的一個(gè)原因是，其 build system 對(duì)各種常見語(yǔ)言的程序都可以全靜態(tài)鏈接，所以可執(zhí)行文件就是“包”。

但這并不是最好的解法，畢竟這樣就沒(méi)有分層了。哪怕我只是修改了 main 函數(shù)里的一行代碼，重新編譯和發(fā)布，都需要很長(zhǎng)時(shí)間，十分鐘甚至數(shù)十分鐘，要知道全靜態(tài)鏈接得到的可執(zhí)行文件往往大小以 GB 計(jì)。

所以全靜態(tài)鏈接雖然是 Google 和 Facebook 沒(méi)有在用 Docker 的原因之一，但是并不是一個(gè)好選擇。

所以也沒(méi)被其他公司效仿。大家還是更愿意用支持分層 cache 的 Docker image。

完美解法的技術(shù)挑戰(zhàn)

完美的解法應(yīng)該支持分層 cache（或者更精確的說(shuō)是分塊 cache）。所以還是應(yīng)該用上文介紹的 monolithic repo 和統(tǒng)一 build system 的特點(diǎn)。

但是這里有一個(gè)技術(shù)挑戰(zhàn)，build system 描述的模塊，而模塊通常比“項(xiàng)目”細(xì)粒度太多了。

以 C/C++ 語(yǔ)言為例，如果每個(gè)模塊生成一個(gè) .so 文件，當(dāng)做一個(gè)“層”或者“塊”以便作為 cache 的單元，那么一個(gè)應(yīng)用程序可能需要的 .so 數(shù)量就太多了。

啟動(dòng)應(yīng)用的時(shí)候，恐怕要花幾十分鐘來(lái) resolve symbols 并且完成鏈接。

所以呢，雖然 monolithic repo 有很多好處，它也有一個(gè)缺點(diǎn)，不像開源世界里，大家人力的把代碼分解成“項(xiàng)目”。

每個(gè)項(xiàng)目通常是一個(gè) GitHub repo，其中可以有很多模塊，但是每個(gè)項(xiàng)目里所有模塊 build 成一個(gè) *.so 作為一個(gè) cache 的單元。

因?yàn)橐粋€(gè)應(yīng)用程序依賴的項(xiàng)目數(shù)量總不會(huì)太多，從而控制了 layer 的總數(shù)。

好在這個(gè)問(wèn)題并非無(wú)解。既然一個(gè)應(yīng)用程序?qū)Ω鱾€(gè)模塊的依賴關(guān)系是一個(gè) DAG，那么我們總可以想辦法做一個(gè) graph partitioning，把這個(gè) DAG 分解成不那么多的幾個(gè)子圖。

仍然以 C/C++ 程序?yàn)槔?，我們可以把每個(gè)子圖里的每個(gè)模塊編譯成一個(gè) .a，而每個(gè)子圖里的所有 .a 鏈接成一個(gè) *.so，作為一個(gè) cache 的單元。

上述就是小編為大家分享的Google和Facebook中為什么不使用Docker了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。