寫(xiě)作本文的起因是我想讓修改后的分布式 PyTorch 程序能更快的在 Facebook 的集群上啟動(dòng)。探索過(guò)程很有趣，也展示了工業(yè)機器學(xué)習需要的知識體系。
2007 年我剛畢業(yè)后在 Google 工作過(guò)三年。當時(shí)覺(jué)得分布式操作系統 Borg 真好用。
從 2010 年離開(kāi) Google 之后就一直盼著(zhù)它開(kāi)源，直到 Kubernetes 的出現。
Kubernetes 調度的計算單元是 containers（準確的翻譯是“集裝箱”，而不是意思泛泛的“容器”，看看 Docker 公司的 Logo 上畫(huà)的是啥就知道作者的心意了）。
而一個(gè) container 執行一個(gè) image，就像一個(gè) process 執行一個(gè) program。
無(wú)論 Googlers 還是 ex-Googlers，恐怕在用 Borg 的時(shí)候都未曾接觸過(guò) container 和 image 這兩個(gè)概念。為啥 Borg 里沒(méi)有，而 Kubernetes 卻要引入了這樣兩個(gè)概念呢？
這個(gè)曾經(jīng)問(wèn)題在我腦海中一閃而過(guò)就被忽略了。畢竟后來(lái)我負責開(kāi)源項目比較多，比如百度 Paddle 以及螞蟻的 SQLFlow 和 ElasticDL，Docker 用起來(lái)很順手。于是也就沒(méi)有多想。
今年（2021 年）初，我加入 Facebook。恰逢 Facebook 發(fā)論文[1]介紹了其分布式集群管理系統 Tupperware。
不過(guò) Tupperware 是一個(gè)注冊于 1946 年的品牌 https://en.wikipedia.org/wiki/Tupperware_Brands，所以在論文里只好起了另一個(gè)名字 Twine。
因為行業(yè)里知道 Tupperware 這個(gè)名字的朋友很多，本文就不說(shuō) Twine 了。
總之，這篇論文的發(fā)表又引發(fā)了我對于之前問(wèn)題的回顧——Facebook 里也沒(méi)有 Docker！
和 Facebook Tuppware 團隊以及 Google Borg 幾位新老同事仔細聊了聊之后，方才恍然。因為行業(yè)里沒(méi)有看到相關(guān)梳理，本文是為記錄。
簡(jiǎn)單的說(shuō)，如果用 monolithic repository 來(lái)管理代碼，則不需要 Docker image（或者 ZIP、tarball、RPM、deb）之類(lèi)的“包”。
所謂 monolithic repo 就是一家公司的所有項目的所有代碼都集中放在一個(gè)（或者極少數）repo 里。
因為 monolithic repository 得有配套的統一構建系統（build system）否則編譯不動(dòng)那么老大一坨代碼。
而既然有統一的 build system，一旦發(fā)現某個(gè)集群節點(diǎn)需要執行的程序依賴(lài)的某個(gè)模塊變化了，同步這個(gè)模塊到此節點(diǎn)既可。完全不需要打包再同步。
反之，如果每個(gè)項目在一個(gè)獨立的 git/svn repo 里，各自用不同的 build system，比如各個(gè)開(kāi)源項目在不同的 GitHub repo 里，則需要把每個(gè)項目 build 的結果打包。
而 Docker image 這樣支持分層的包格式讓我們只需要傳輸那些容納被修改的項目的最上面幾層，而盡量復用被節點(diǎn) cache 了的下面的幾層。
Google 和 Facebook 都使用 monolithic repository，也都有自己的 build systems（我這篇老文尋找 Google Blaze[2] 解釋過(guò) Google 的 build system）所以不需要“包”，當然也就不需要 Docker images。
不過(guò) Borg 和 Tupperware 都是有 container 的（使用 Linux kernel 提供的一些 system calls，比如 Google Borg 團隊十多年前貢獻給 Linux kernel 的 cgroup）來(lái)實(shí)現 jobs 之間的隔離。
只是因為如果不需要大家 build Docker image 了，那么 container 的存在就不容易被關(guān)注到了。
如果不想被上述蔽之，而要細究這個(gè)問(wèn)題，那就待我一層一層剝開(kāi) Google 和 Facebook 的研發(fā)技術(shù)體系和計算技術(shù)體系。
當我們提交一個(gè)分布式作業(yè)（job）到集群上去執行，我們得把要執行的程序（包括一個(gè)可執行文件以及相關(guān)的文件，比如 *.so，*.py）傳送到調度系統分配給這個(gè) job 的一些機器（節點(diǎn)、nodes）上去。
這些待打包的文件是怎么來(lái)的呢？當時(shí)是 build 出來(lái)的。在 Google 里有 Blaze，在 Facebook 里有 Buck。
感興趣的朋友們可以看看 Google Blaze 的“開(kāi)源版本”Bazel[3]，以及 Facebook Buck 的開(kāi)源版本[4]。
不過(guò)提醒在先：Blaze 和 Facebook Buck 的內部版都是用于 monolithic repo 的，而開(kāi)源版本都是方便大家使用非 mono repos 的，所以理念和實(shí)現上有不同，不過(guò)基本使用方法還是可以感受一下的。
假設我們有如下模塊依賴(lài)（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 結果）依賴(lài)關(guān)系如下：
A.py --> B.py --> D.so -\
\-> C.py --> E.so --> F.so
如果是開(kāi)源項目，請自行腦補，把上述模塊（modules）替換成 GPT-3，PyTorch，cuDNN，libc++ 等項目（projects）。
當然，每個(gè) projects 里包含多個(gè) modules 也依賴(lài)其他 projects，就像每個(gè) module 有多個(gè)子 modules 一樣。
最簡(jiǎn)單的打包方式就是把上述文件 {A,B,C}.py, {D,E,F}.so 打包成一個(gè)文件 A.zip，或者 A.tar.gz。
更嚴謹的說(shuō)，文件名里應該包括版本號。比如 A-953bc.zip，其中版本號 953bc 是 git/Mercurial commit ID。
引入版本號，可以幫助在節點(diǎn)本地 cache，下次運行同一個(gè) tarball 的時(shí)候，就不需要下載這個(gè)文件了。
請注意這里我引入了 package caching 的概念。為下文解釋 Docker 預備。
ZIP 或者 tarball 文件拷貝到集群節點(diǎn)上之后，需要解壓縮到本地文件系統的某個(gè)地方，比如：/var/packages/A-953bc/{A,B,C}.py,{D,E,F}.so。
一個(gè)稍顯酷炫的方式是不用 Tarball，而是把上述文件放在一個(gè) overlay filesystem 的 loopback device image 里。這樣“解壓”就變成了“mount”。
請注意這里我引入了 loopback device image 的概念。為下文解釋 Docker 預備。
什么叫 loopback device image 呢？在 Unix 里，一個(gè)目錄樹(shù)的文件們被稱(chēng)為一個(gè)文件系統（filesystem）。
通常一個(gè) filesystem 存儲在一個(gè) block device 上。什么是 block device 呢？
簡(jiǎn)單的說(shuō)，但凡一個(gè)存儲空間可以被看作一個(gè) byte array 的，就是一個(gè) block device。
比如一塊硬盤(pán)就是一個(gè) block device。在一個(gè)新買(mǎi)的硬盤(pán)里創(chuàng )建一個(gè)空的目錄樹(shù)結構的過(guò)程，就叫做格式化（format）。
既然 block device 只是一個(gè) byte array，那么一個(gè)文件不也是一個(gè) byte array 嗎？
是的！在 Unix 的世界里，我們完全可以創(chuàng )建一個(gè)固定大小的空文件（用 truncate 命令），然后“格式化”這個(gè)文件，在里面創(chuàng )建一個(gè)空的文件系統。然后把上述文件 {A,B,C}.py,{D,E,F}.so 放進(jìn)去。
比如 Facebook 開(kāi)源的 XAR 文件[5]格式。這是和 Buck 一起使用的。
如果我們運行 buck build A 就會(huì )得到 A.xar . 這個(gè)文件包括一個(gè) header，以及一個(gè) squashfs loopback device image，簡(jiǎn)稱(chēng) squanshfs image。
這里 squashfs 是一個(gè)開(kāi)源文件系統。感興趣的朋友們可以參考這個(gè)教程[6]，創(chuàng )建一個(gè)空文件，把它格式化成 squashfs，然后 mount 到本地文件系統的某個(gè)目錄（mount point）里。
待到我們 umount 的時(shí)候，曾經(jīng)加入到 mount point 里的文件，就留在這個(gè)“空文件”里了。
我們可以把它拷貝分發(fā)給其他人，大家都可以 mount 之，看到我們加入其中的文件。
因為 XAR 是在 squashfs image 前面加上了一個(gè) header，所以沒(méi)法用 mount -t squashf 命令來(lái) mount，得用 mount -t xar 或者 xarexec -m 命令。
比如，一個(gè)節點(diǎn)上如果有了 /packages/A-953bc.xar，我們可以用如下命令看到它的內容，而不需要耗費 CPU 資源來(lái)解壓縮：
xarexec -m A-953bc.xar
這個(gè)命令會(huì )打印出一個(gè)臨時(shí)目錄，是 XAR 文件的 mount point。
如果我們現在修改了 A.py，那么不管是 build 成 tarball 還是 XAR，整個(gè)包都需要重新更新。
當然，只要 build system 支持 cache，我們是不需要重新生成各個(gè) *.so 文件的。
但是這個(gè)不解決我們需要重新分發(fā) .tar.gz 和 .xar 文件到集群的各個(gè)節點(diǎn)的麻煩。
之前節點(diǎn)上可能有老版本的 A-953bc87fe.{tar.gz,xar} 了，但是不能復用。為了復用 ，需要分層。
對于上面情況，我們可以根據模塊依賴(lài)關(guān)系圖，構造多個(gè) XAR 文件。
A-953bc.xar --> B-953bc.xar --> D-953bc.xar -\
\-> C-953bc.xar --> E-953bc.xar --> F-953bc.xar
其中每個(gè) XAR 文件里只有對應的 build rule 產(chǎn)生的文件。比如，F-953bc.xar 里只有 F.so。
這樣，如果我們只修改了 A.py，則只有 A.xar 需要重新 build 和傳送到集群節點(diǎn)上。這個(gè)節點(diǎn)可以復用之前已經(jīng) cache 了的 {B,C,D,E,F}-953bc.xar 文件。
假設一個(gè)節點(diǎn)上已經(jīng)有 /packages/{A,B,C,D,E,F}-953bc.xar，我們是不是可以按照模塊依賴(lài)順序，運行 xarexec -m 命令，依次 mount 這些 XAR 文件到同一個(gè) mount point 目錄，既可得到其中所有的內容了呢？
很遺憾，不行。因為后一個(gè) xarexec/mount 命令會(huì )報錯 —— 因為這個(gè) mount point 已經(jīng)被前一個(gè) xarexec/mount 命令占據了。
下面解釋為什么文件系統 image 優(yōu)于 tarball。
那退一步，不用 XAR 了，用 ZIP 或者 tar.gz 不行嗎？可以，但是慢。我們可以把所有 .tar.gz 都解壓縮到同一個(gè)目錄里。
但是如果 A.py 更新了，我們沒(méi)法識別老的 A.py 并且替換為新的，而是得重新解壓所有 .tar.gz 文件，得到一個(gè)新的文件夾。而重新解壓所有的 {B,C,D,E,F}.tar.gz 很慢。
Overlay Filesystem
有一個(gè)申請的開(kāi)源工具 fuse-overlayfs。它可以把幾個(gè)目錄“疊加”（overlay）起來(lái)。
比如下面命令把 /tmp/{A,B,C,D,E,F}-953bc 這幾個(gè)目錄里的內容都“疊加”到 /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。
請注意這里我引入了 overlay filesystem 的概念。為下文解釋 Docker 預備。fuse-overlayfs 是怎么做到這一點(diǎn)的呢？
當我們訪(fǎng)問(wèn)任何一個(gè)文件系統目錄，比如 /packages/A 的時(shí)候，我們使用的命令行工具（比如 ls ）調用 system calls（比如 open/close/read/write） 來(lái)訪(fǎng)問(wèn)其中的文件。
這些 system calls 和文件系統的 driver 打交道 —— 它們會(huì )問(wèn) driver：/packages/A 這個(gè)目錄里有沒(méi)有一個(gè)叫 A.py 的文件呀？
如果我們使用 Linux，一般來(lái)說(shuō)，硬盤(pán)上的文件系統是 ext4 或者 btrfs。也就是說(shuō)，Linux universal filesystem driver 會(huì )看看每個(gè)分區的文件系統是啥，然后把 system call 轉發(fā)給對應的 ext4/btrfs driver 去處理。
一般的 filesystem drivers 和其他設備的 drivers 一樣運行在 kernel mode 里。
這是為什么一般我們運行 mount 和 umount 這類(lèi)操作 filesystems 的命令的時(shí)候，都需要 sudo。而 FUSE 是一個(gè)在 userland 開(kāi)發(fā) filesystem driver 的庫。
fuse-overlayfs 這命令利用 FUSE 這個(gè)庫，開(kāi)發(fā)了一個(gè)運行在 userland 的 fuse-overlayfs driver。
當 ls 命令詢(xún)問(wèn)這個(gè) overlayfs driver /packages/A-953bc 目錄里有啥的時(shí)候，這個(gè) fuse-overlayfs driver 記得之前用戶(hù)運行過(guò) fuse-overlayfs 命令把 /tmp/{A,B,C,D,E}-953bc 這幾個(gè)目錄給疊加上去過(guò)，所以它返回這幾個(gè)目錄里的文件。
此時(shí)，因為 /tmp/{A,B,C,D,E}-953bc 這幾個(gè)目錄其實(shí)是 /packages/{A,B,C,D,E,F}-953bc.xar 的 mount points，所以每個(gè) XAR 就相當于一個(gè) layer。
像 fuse-overlayfs driver 這樣實(shí)現把多個(gè)目錄“疊加”起來(lái)的 filesystem driver 被稱(chēng)為 overlay filesystem driver，有時(shí)簡(jiǎn)稱(chēng)為 overlay filesystems。
Docker Image and Layer
上面說(shuō)到用 overlay filesystem 實(shí)現分層。用過(guò) Docker 的人都會(huì )熟悉一個(gè) Docker image 由多層構成。
當我們運行 docker pull <image-name> 命令的時(shí)候，如果本機已經(jīng) cache 了這個(gè) image 的一部分 layers，則省略下載這些 layers。這其實(shí)就是用 overlay filesystem 實(shí)現的。
Docker 團隊開(kāi)發(fā)了一個(gè) filesystem（driver）叫做 overlayfs —— 這是一個(gè)特定的 filesystem 的名字。
顧名思義，Docker overlayfs 也實(shí)現了“疊加”（overlay）的能力，這就是我們看到每個(gè) Docker image 可以有多個(gè) layers 的原因。
Docker 的 overlayfs 以及它的后續版本 overlayfs2 都是運行在 kernel mode 里的。
這也是 Docker 需要機器的 root 權限的原因之一，而這又是 Docker 被詬病容易導致安全漏斗的原因。
有一個(gè)叫 btrfs 的 filesystem，是 Linux 世界里最近幾年發(fā)展很迅速的，用于管理硬盤(pán)效果很好。
這個(gè) filesystem 的 driver 也支持 overlay。所以 Docker 也可以被配置為使用這個(gè) filesystem 而不是 overlayfs。
不過(guò)只有 Docker 用戶(hù)的電腦的 local filesystem 是 btrfs 的時(shí)候，Docker 才能用 btrfs 在上面疊加 layers。
所以說(shuō)，如果你用的是 macOS 或者 Windows，那肯定沒(méi)法讓 Docker 使用 btrfs 了。
不過(guò)如果你用的是 fuse-overlayfs，那就是用了一副萬(wàn)靈藥了。只是通過(guò) FUSE 在 userland 運行的 filesystem 的性能很一般，不過(guò)本文討論的情形對性能也沒(méi)啥需求。
其實(shí) Docker 也可以被配置使用 fuse-overlayfs。Docker 支持的分層 filesystem 列表在這里 Docker storage drivers[7]。
為什么需要 Docker Image
總結上文所述，從編程到可以在集群上跑起來(lái)，我們要做幾個(gè)步驟：
把源碼分成模塊，可以讓編譯這步充分利用每次修改只改動(dòng)一小部分代碼的特點(diǎn)，只重新編譯被修改的模塊，從而節省時(shí)間。
為了節省 2，3 和 4 的時(shí)間，我們希望“包”是分層的。每一層最好只包含一個(gè)或者幾個(gè)代碼模塊。這樣，可以利用模塊之間的依賴(lài)關(guān)系，盡量復用容納底層模塊的“層”。
在開(kāi)源的世界里，我們用 Docker image 支持分層的特點(diǎn)，一個(gè)基礎層可能只包括某個(gè) Linux distribution（比如 CentOS）的 userland programs，如 ls、cat、grep 等。
在其上，可以有一個(gè)層包括 CUDA。再其上安裝 Python 和 PyTorch。再再之上的一層里是 GPT-3 模型的訓練程序。
這樣，如果我們只是修改了 GPT-3 訓練程序，則不需要重新打包和傳輸下面三層。
這里的邏輯核心是：存在“項目”（project）的概念。每個(gè)項目可以有自己的 repo，自己的 building system（GNU make、CMake、Buck、Bazel 等），自己的發(fā)行版本（release）。
所以每個(gè)項目的 release 裝進(jìn) Docker image 的一層 layer。與其前置多層合稱(chēng)為一個(gè) image。
為什么 Google 和 Facebook 不需要 Docker
經(jīng)過(guò)上述這么多知識準備，請我們終于可以點(diǎn)題了。
因為 Google 和 Facebook 使用 monolithic repository，使用統一的 build system（Google Blaze 或者 Facebook Buck）。
雖然也可以利用“項目”的概念，把每個(gè)項目的 build result 裝入 Docker image 的一層。但是實(shí)際上并不需要。
利用 Blaze 和 Buck 的 build rules 定義的模塊，以及模塊之間依賴(lài)關(guān)系，我們可以完全去打包和解包的概念。
沒(méi)有了包，當然就不需要 zip、tarball、以及 Docker image 和 layers 了。
直接把每個(gè)模塊當做一個(gè) layer 既可。如果 D.so 因為我們修改了 D.cpp 被重新編譯，那么只重新傳輸 D.so 既可，而不需要去傳輸一個(gè) layer 其中包括 D.so。
于是，在 Google 和 Facebook 里，受益于 monolithic repository 和統一的 build 工具。
我們把上述四個(gè)步驟省略成了兩個(gè)：
Google 和 Facebook 沒(méi)在用 Docker
上一節說(shuō)了 monolithic repo 可以讓 Google 和 Facebook 不需要 Docker image。
現實(shí)是 Google 和 Facebook 沒(méi)有在使用 Docker。這兩個(gè)概念有區別。
我們先說(shuō)“沒(méi)在用”。歷史上，Google 和 Facebook 使用超大規模集群先于 Docker 和 Kubernetes 的出現。當時(shí)為了打包方便，連 tarball 都沒(méi)有。
對于 C/C++ 程序，直接全靜態(tài)鏈接，根本沒(méi)有 *.so。于是一個(gè) executable binary file 就是“包”了。
直到今天，大家用開(kāi)源的 Bazel 和 Buck 的時(shí)候，仍然可以看到默認鏈接方式就是全靜態(tài)鏈接。
Java 語(yǔ)言雖然是一種“全動(dòng)態(tài)鏈接”的語(yǔ)言，不過(guò)其誕生和演進(jìn)扣準了互聯(lián)網(wǎng)歷史機遇，其開(kāi)發(fā)者發(fā)明 jar 文件格式，從而支持了全靜態(tài)鏈接。
Python 語(yǔ)言本身沒(méi)有 jar 包，所以 Blaze 和 Bazel 發(fā)明了 PAR 文件格式（英語(yǔ)叫 subpar），相當于為 Python 設計了一個(gè) jar。開(kāi)源實(shí)現在這里[8]。
類(lèi)似的，Buck 發(fā)明了 XAR 格式，也就是我上文所說(shuō)的 squashfs image 前面加了一個(gè) header。其開(kāi)源實(shí)現在這里[9]。
Go 語(yǔ)言默認就是全靜態(tài)鏈接的。在 Rob Pike 早期的一些總結里提到，Go 的設計，包括全靜態(tài)鏈接，基本就是繞坑而行，繞開(kāi) Google C/C++ 實(shí)踐中遇到過(guò)的各種坑。
熟悉 Google C++ style guide 的朋友們應該感覺(jué)到了 Go 語(yǔ)法覆蓋了 guide 說(shuō)的“應該用的 C++ 語(yǔ)法”，而不支持 guide 說(shuō)的 “不應該用的 C++ 的部分”。
簡(jiǎn)單的說(shuō)，歷史上 Google 和 Facebook 沒(méi)有在用 Docker image，很重要的一個(gè)原因是，其 build system 對各種常見(jiàn)語(yǔ)言的程序都可以全靜態(tài)鏈接，所以可執行文件就是“包”。
但這并不是最好的解法，畢竟這樣就沒(méi)有分層了。哪怕我只是修改了 main 函數里的一行代碼，重新編譯和發(fā)布，都需要很長(cháng)時(shí)間，十分鐘甚至數十分鐘，要知道全靜態(tài)鏈接得到的可執行文件往往大小以 GB 計。
所以全靜態(tài)鏈接雖然是 Google 和 Facebook 沒(méi)有在用 Docker 的原因之一，但是并不是一個(gè)好選擇。
所以也沒(méi)被其他公司效仿。大家還是更愿意用支持分層 cache 的 Docker image。
完美解法的技術(shù)挑戰
完美的解法應該支持分層 cache（或者更精確的說(shuō)是分塊 cache）。所以還是應該用上文介紹的 monolithic repo 和統一 build system 的特點(diǎn)。
但是這里有一個(gè)技術(shù)挑戰，build system 描述的模塊，而模塊通常比“項目”細粒度太多了。
以 C/C++ 語(yǔ)言為例，如果每個(gè)模塊生成一個(gè) .so 文件，當做一個(gè)“層”或者“塊”以便作為 cache 的單元，那么一個(gè)應用程序可能需要的 .so 數量就太多了。
啟動(dòng)應用的時(shí)候，恐怕要花幾十分鐘來(lái) resolve symbols 并且完成鏈接。
所以呢，雖然 monolithic repo 有很多好處，它也有一個(gè)缺點(diǎn)，不像開(kāi)源世界里，大家人力的把代碼分解成“項目”。
每個(gè)項目通常是一個(gè) GitHub repo，其中可以有很多模塊，但是每個(gè)項目里所有模塊 build 成一個(gè) *.so 作為一個(gè) cache 的單元。
因為一個(gè)應用程序依賴(lài)的項目數量總不會(huì )太多，從而控制了 layer 的總數。
好在這個(gè)問(wèn)題并非無(wú)解。既然一個(gè)應用程序對各個(gè)模塊的依賴(lài)關(guān)系是一個(gè) DAG，那么我們總可以想辦法做一個(gè) graph partitioning，把這個(gè) DAG 分解成不那么多的幾個(gè)子圖。
仍然以 C/C++ 程序為例，我們可以把每個(gè)子圖里的每個(gè)模塊編譯成一個(gè) .a，而每個(gè)子圖里的所有 .a 鏈接成一個(gè) *.so，作為一個(gè) cache 的單元。
于是，如何設計這個(gè) graph partitioning 算法就成了眼前最重要的問(wèn)題了。
相關(guān)鏈接：
https://engineering.fb.com/2019/06/06/data-center-engineering/twine/
https://zhuanlan.zhihu.com/p/55452964
https://bazel.build/
https://buck.build/
https://github.com/facebookincubator/xar
https://tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html
https://docs.docker.com/storage/storagedriver/select-storage-driver/
https://github.com/google/subpar
https://github.com/facebookincubator/xar
到此這篇關(guān)于Google和Facebook不使用Docker的原理解析的文章就介紹到這了,更多相關(guān)Google和Facebook不使用Docker內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
免責聲明：本站發(fā)布的內容（圖片、視頻和文字）以原創(chuàng )、來(lái)自本網(wǎng)站內容采集于網(wǎng)絡(luò )互聯(lián)網(wǎng)轉載等其它媒體和分享為主，內容觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如侵犯了原作者的版權，請告知一經(jīng)查實(shí)，將立刻刪除涉嫌侵權內容，聯(lián)系我們QQ:712375056，同時(shí)歡迎投稿傳遞力量。
Copyright ? 2009-2022 56dr.com. All Rights Reserved. 特網(wǎng)科技 特網(wǎng)云 版權所有 特網(wǎng)科技 粵ICP備16109289號
域名注冊服務(wù)機構:阿里云計算有限公司（萬(wàn)網(wǎng)） 域名服務(wù)機構：煙臺帝思普網(wǎng)絡(luò )科技有限公司（DNSPod） CDN服務(wù)：阿里云計算有限公司 百度云 中國互聯(lián)網(wǎng)舉報中心 增值電信業(yè)務(wù)經(jīng)營(yíng)許可證B2
建議您使用Chrome、Firefox、Edge、IE10及以上版本和360等主流瀏覽器瀏覽本網(wǎng)站
