Docker源码分析（七）：Docker Container网络 （上）
http://www.infoq.com/cn/articles/docker-source-code-analysis-part7
1.前言(什么是Docker Container)
如今，Docker技術(shù)大行其道，大家在嘗試以及玩轉(zhuǎn)Docker的同時，肯定離不開一個概念，那就是“容器”或者“Docker Container”。那么我們首先從實現(xiàn)的角度來看看“容器”或者“Docker Container”到底為何物。
逐漸熟悉Docker之后，大家肯定會深深得感受到：應(yīng)用程序在Docker Container內(nèi)部的部署與運行非常便捷，只要有Dockerfile，應(yīng)用一鍵式的部署運行絕對不是天方夜譚； Docker Container內(nèi)運行的應(yīng)用程序可以受到資源的控制與隔離，大大滿足云計算時代應(yīng)用的要求。毋庸置疑，Docker的這些特性，傳統(tǒng)模式下應(yīng)用是完全不具備的。然而，這些令人眼前一亮的特性背后，到底是誰在“作祟”，到底是誰可以支撐Docker的這些特性？不知道這個時候，大家是否會聯(lián)想到強大的Linux內(nèi)核。
其實，這很大一部分功能都需要歸功于Linux內(nèi)核。那我們就從Linux內(nèi)核的角度來看看Docker到底為何物，先從Docker Container入手。關(guān)于Docker Container，體驗過的開發(fā)者第一感覺肯定有兩點：內(nèi)部可以跑應(yīng)用（進程），以及提供隔離的環(huán)境。當然，后者肯定也是工業(yè)界稱之為“容器”的原因之一。
既然Docker Container內(nèi)部可以運行進程，那么我們先來看Docker Container與進程的關(guān)系，或者容器與進程的關(guān)系。首先，我提出這樣一個問題供大家思考“容器是否可以脫離進程而存在”。換句話說，能否創(chuàng)建一個容器，而這個容器內(nèi)部沒有任何進程。
可以說答案是否定的。既然答案是否定的，那說明不可能先有容器，然后再有進程，那么問題又來了，“容器和進程是一起誕生，還是先有進程再有容器呢？”可以說答案是后者。以下將慢慢闡述其中的原因。
闡述問題“容器是否可以脫離進程而存在”的原因前，相信大家對于以下的一段話不會持有異議：通過Docker創(chuàng)建出的一個Docker Container是一個容器，而這個容器提供了進程組隔離的運行環(huán)境。那么問題在于，容器到底是通過何種途徑來實現(xiàn)進程組運行環(huán)境的“隔離”。這時，就輪到Linux內(nèi)核技術(shù)隆重登場了。
說到運行環(huán)境的“隔離”，相信大家肯定對Linux的內(nèi)核特性namespace和cgroup不會陌生。namespace主要負責命名空間的隔離，而cgroup主要負責資源使用的限制。其實，正是這兩個神奇的內(nèi)核特性聯(lián)合使用，才保證了Docker Container的“隔離”。那么，namespace和cgroup又和進程有什么關(guān)系呢？問題的答案可以用以下的次序來說明：
(1) 父進程通過fork創(chuàng)建子進程時，使用namespace技術(shù)，實現(xiàn)子進程與其他進程（包含父進程）的命名空間隔離；
(2) 子進程創(chuàng)建完畢之后，使用cgroup技術(shù)來處理子進程，實現(xiàn)進程的資源使用限制；
(3) 系統(tǒng)在子進程所處namespace內(nèi)部，創(chuàng)建需要的隔離環(huán)境，如隔離的網(wǎng)絡(luò)棧等；
(4) namespace和cgroup兩種技術(shù)都用上之后，進程所處的“隔離”環(huán)境才真正建立，這時“容器”才真正誕生！
從Linux內(nèi)核的角度分析容器的誕生，精簡的流程即如以上4步，而這4個步驟也恰好巧妙的闡述了namespace和cgroup這兩種技術(shù)和進程的關(guān)系，以及進程與容器的關(guān)系。進程與容器的關(guān)系，自然是：容器不能脫離進程而存在，先有進程，后有容器。然而，大家往往會說到“使用Docker創(chuàng)建Docker Container（容器），然后在容器內(nèi)部運行進程”。對此，從通俗易懂的角度來講，這完全可以理解，因為“容器”一詞的存在，本身就較為抽象。如果需要更為準確的表述，那么可以是：“使用Docker創(chuàng)建一個進程，為這個進程創(chuàng)建隔離的環(huán)境，這樣的環(huán)境可以稱為Docker Container（容器），然后再在容器內(nèi)部運行用戶應(yīng)用進程。”當然，筆者的本意不是想否定很多人對于Docker Container或者容器的認識，而是希望和讀者一起探討Docker Container底層技術(shù)實現(xiàn)的原理。
對于Docker Container或者容器有了更加具體的認識之后，相信大家的眼球肯定會很快定位到namespace和cgroup這兩種技術(shù)。Linux內(nèi)核的這兩種技術(shù)，竟然能起到如此重大的作用，不禁為之贊嘆。那么下面我們就從Docker Container實現(xiàn)流程的角度簡要介紹這兩者。
首先講述一下namespace在容器創(chuàng)建時的用法，首先從用戶創(chuàng)建并啟動容器開始。當用戶創(chuàng)建并啟動容器時，Docker Daemon 會fork出容器中的第一個進程A（暫且稱為進程A，也就是Docker Daemon的子進程）。Docker Daemon執(zhí)行fork時，在clone系統(tǒng)調(diào)用階段會傳入5個參數(shù)標志CLONE_NEWNS、CLONE_NEWUTS、CLONE_NEWIPC、CLONE_NEWPID和CLONE_NEWNET（目前Docker 1.2.0還沒有完全支持user namespace）。Clone系統(tǒng)調(diào)用一旦傳入了這些參數(shù)標志，子進程將不再與父進程共享相同的命名空間（namespace），而是由Linux為其創(chuàng)建新的命名空間（namespace），從而保證子進程與父進程使用隔離的環(huán)境。另外，如果子進程A再次fork出子進程B和C，而fork時沒有傳入相應(yīng)的namespace參數(shù)標志，那么此時子進程B和C將會與A共享同一個命令空間（namespace）。如果Docker Daemon再次創(chuàng)建一個Docker Container，容器內(nèi)第一個進程為D，而D又fork出子進程E和F，那么這三個進程也會處于另外一個新的namespace。兩個容器的namespace均與Docker Daemon所在的namespace不同。Docker關(guān)于namespace的簡易示意圖如下：
圖1.1 Docker中namespace示意圖
再說起cgroup，大家都知道可以使用cgroup為進程組做資源的控制。與namespace不同的是，cgroup的使用并不是在創(chuàng)建容器內(nèi)進程時完成的，而是在創(chuàng)建容器內(nèi)進程之后再使用cgroup，使得容器進程處于資源控制的狀態(tài)。換言之，cgroup的運用必須要等到容器內(nèi)第一個進程被真正創(chuàng)建出來之后才能實現(xiàn)。當容器內(nèi)進程被創(chuàng)建完畢，Docker Daemon可以獲知容器內(nèi)進程的PID信息，隨后將該PID放置在cgroup文件系統(tǒng)的指定位置，做相應(yīng)的資源限制。
可以說Linux內(nèi)核的namespace和cgroup技術(shù)，實現(xiàn)了資源的隔離與限制。那么對于這種隔離與受限的環(huán)境，是否還需要配置其他必需的資源呢。這回答案是肯定的，網(wǎng)絡(luò)棧資源就是在此時為容器添加。當為容器進程創(chuàng)建完隔離的運行環(huán)境時，發(fā)現(xiàn)容器雖然已經(jīng)處于一個隔離的網(wǎng)絡(luò)環(huán)境（即新的network namespace），但是進程并沒有獨立的網(wǎng)絡(luò)棧可以使用，如獨立的網(wǎng)絡(luò)接口設(shè)備等。此時，Docker Daemon會將Docker Container所需要的資源一一為其配備齊全。網(wǎng)絡(luò)方面，則需要按照用戶指定的網(wǎng)絡(luò)模式，配置Docker Container相應(yīng)的網(wǎng)絡(luò)資源。
2.Docker Container網(wǎng)絡(luò)分析內(nèi)容安排
Docker Container網(wǎng)絡(luò)篇將從源碼的角度，分析Docker Container從無到有的過程中，Docker Container網(wǎng)絡(luò)創(chuàng)建的來龍去脈。Docker Container網(wǎng)絡(luò)創(chuàng)建流程可以簡化如下圖：
圖2.1 Docker Container網(wǎng)絡(luò)創(chuàng)建流程圖
Docker Container網(wǎng)絡(luò)篇分析的主要內(nèi)容有以下5部分：
(1) Docker Container的網(wǎng)絡(luò)模式；
(2) Docker Client配置容器網(wǎng)絡(luò)；
(3) Docker Daemon創(chuàng)建容器網(wǎng)絡(luò)流程；
(4) execdriver網(wǎng)絡(luò)執(zhí)行流程；
(5) libcontainer實現(xiàn)內(nèi)核態(tài)網(wǎng)絡(luò)配置。
Docker Container網(wǎng)絡(luò)創(chuàng)建過程中，networkdriver模塊使用并非是重點，故分析內(nèi)容中不涉及networkdriver。這里不少讀者肯定會有疑惑。需要強調(diào)的是，networkdriver在Docker中的作用：第一，為Docker Daemon創(chuàng)建網(wǎng)絡(luò)環(huán)境的時候，初始化Docker Daemon的網(wǎng)絡(luò)環(huán)境（詳情可以查看《Docker源碼分析》系列第六篇），比如創(chuàng)建docker0網(wǎng)橋等；第二，為Docker Container分配IP地址，為Docker Container做端口映射等。而與Docker Container網(wǎng)絡(luò)創(chuàng)建有關(guān)的內(nèi)容極少，只有在橋接模式下，為Docker Container的網(wǎng)絡(luò)接口設(shè)備分配一個可用IP地址。
本文為《Docker源碼分析》系列第七篇——Docker Container網(wǎng)絡(luò)（上）。
3.Docker Container網(wǎng)絡(luò)模式
正如在上文提到的，Docker可以為Docker Container創(chuàng)建隔離的網(wǎng)絡(luò)環(huán)境，在隔離的網(wǎng)絡(luò)環(huán)境下，Docker Container獨立使用私有網(wǎng)絡(luò)。相信很多的Docker開發(fā)者也是體驗過Docker這方面的網(wǎng)絡(luò)特性。
其實，Docker除了可以為Docker Container創(chuàng)建隔離的網(wǎng)絡(luò)環(huán)境之外，同樣有能力為Docker Container創(chuàng)建共享的網(wǎng)絡(luò)環(huán)境。換言之，當開發(fā)者需要Docker Container與宿主機或者其他容器網(wǎng)絡(luò)隔離時，Docker可以滿足這樣的需求；而當開發(fā)者需要Docker Container與宿主機或者其他容器共享網(wǎng)絡(luò)時，Docker同樣可以滿足這樣的需求。另外，Docker還可以不為Docker Container創(chuàng)建網(wǎng)絡(luò)環(huán)境。
總結(jié)Docker Container的網(wǎng)絡(luò)，可以得出4種不同的模式：bridge橋接模式、host模式、other container模式和none模式。以下初步介紹4中不同的網(wǎng)絡(luò)模式。
3.1 bridge橋接模式
Docker Container的bridge橋接模式可以說是目前Docker開發(fā)者最常使用的網(wǎng)絡(luò)模式。Brdige橋接模式為Docker Container創(chuàng)建獨立的網(wǎng)絡(luò)棧，保證容器內(nèi)的進程組使用獨立的網(wǎng)絡(luò)環(huán)境，實現(xiàn)容器間、容器與宿主機之間的網(wǎng)絡(luò)棧隔離。另外，Docker通過宿主機上的網(wǎng)橋(docker0)來連通容器內(nèi)部的網(wǎng)絡(luò)棧與宿主機的網(wǎng)絡(luò)棧，實現(xiàn)容器與宿主機乃至外界的網(wǎng)絡(luò)通信。
Docker Container的bridge橋接模式可以參考下圖：
圖3.1 Docker Container Bridge橋接模式示意圖
Bridge橋接模式的實現(xiàn)步驟主要如下：
(1) Docker Daemon利用veth pair技術(shù)，在宿主機上創(chuàng)建兩個虛擬網(wǎng)絡(luò)接口設(shè)備，假設(shè)為veth0和veth1。而veth pair技術(shù)的特性可以保證無論哪一個veth接收到網(wǎng)絡(luò)報文，都會將報文傳輸給另一方。
(2) Docker Daemon將veth0附加到Docker Daemon創(chuàng)建的docker0網(wǎng)橋上。保證宿主機的網(wǎng)絡(luò)報文可以發(fā)往veth0；
(3) Docker Daemon將veth1添加到Docker Container所屬的namespace下，并被改名為eth0。如此一來，保證宿主機的網(wǎng)絡(luò)報文若發(fā)往veth0，則立即會被eth0接收，實現(xiàn)宿主機到Docker Container網(wǎng)絡(luò)的聯(lián)通性；同時，也保證Docker Container單獨使用eth0，實現(xiàn)容器網(wǎng)絡(luò)環(huán)境的隔離性。
Bridge橋接模式，從原理上實現(xiàn)了Docker Container到宿主機乃至其他機器的網(wǎng)絡(luò)連通性。然而，由于宿主機的IP地址與veth pair的 IP地址均不在同一個網(wǎng)段，故僅僅依靠veth pair和namespace的技術(shù)，還不足以是宿主機以外的網(wǎng)絡(luò)主動發(fā)現(xiàn)Docker Container的存在。為了使得Docker Container可以讓宿主機以外的世界感知到容器內(nèi)部暴露的服務(wù)，Docker采用NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）的方式，讓宿主機以外的世界可以主動將網(wǎng)絡(luò)報文發(fā)送至容器內(nèi)部。
具體來講，當Docker Container需要暴露服務(wù)時，內(nèi)部服務(wù)必須監(jiān)聽容器IP和端口號port_0，以便外界主動發(fā)起訪問請求。由于宿主機以外的世界，只知道宿主機eth0的網(wǎng)絡(luò)地址，而并不知道Docker Container的IP地址，哪怕就算知道Docker Container的IP地址，從二層網(wǎng)絡(luò)的角度來講，外界也無法直接通過Docker Container的IP地址訪問容器內(nèi)部應(yīng)用。因此，Docker使用NAT方法，將容器內(nèi)部的服務(wù)監(jiān)聽的端口與宿主機的某一個端口port_1進行“綁定”。
如此一來，外界訪問Docker Container內(nèi)部服務(wù)的流程為：
(1) 外界訪問宿主機的IP以及宿主機的端口port_1；
(2) 當宿主機接收到這樣的請求之后，由于DNAT規(guī)則的存在，會將該請求的目的IP（宿主機eth0的IP）和目的端口port_1進行轉(zhuǎn)換，轉(zhuǎn)換為容器IP和容器的端口port_0;
(3) 由于宿主機認識容器IP，故可以將請求發(fā)送給veth pair；
(4) veth pair的veth0將請求發(fā)送至容器內(nèi)部的eth0，最終交給內(nèi)部服務(wù)進行處理。
使用DNAT方法，可以使得Docker宿主機以外的世界主動訪問Docker Container內(nèi)部服務(wù)。那么Docker Container如何訪問宿主機以外的世界呢。以下簡要分析Docker Container訪問宿主機以外世界的流程：
(1) Docker Container內(nèi)部進程獲悉宿主機以外服務(wù)的IP地址和端口port_2，于是Docker Container發(fā)起請求。容器的獨立網(wǎng)絡(luò)環(huán)境保證了請求中報文的源IP地址為容器IP（即容器內(nèi)部eth0），另外Linux內(nèi)核會自動為進程分配一個可用源端口（假設(shè)為port_3）;
(2) 請求通過容器內(nèi)部eth0發(fā)送至veth pair的另一端，到達veth0，也就是到達了網(wǎng)橋（docker0）處；
(3) docker0網(wǎng)橋開啟了數(shù)據(jù)報轉(zhuǎn)發(fā)功能（/proc/sys/net/ipv4/ip_forward），故將請求發(fā)送至宿主機的eth0處；
(4) 宿主機處理請求時，使用SNAT對請求進行源地址IP轉(zhuǎn)換，即將請求中源地址IP（容器IP地址）轉(zhuǎn)換為宿主機eth0的IP地址；
(5) 宿主機將經(jīng)過SNAT轉(zhuǎn)換后的報文通過請求的目的IP地址（宿主機以外世界的IP地址）發(fā)送至外界。
在這里，很多人肯定會問：對于Docker Container內(nèi)部主動發(fā)起對外的網(wǎng)絡(luò)請求，當請求到達宿主機進行SNAT處理后發(fā)給外界，當外界響應(yīng)請求時，響應(yīng)報文中的目的IP地址肯定是Docker宿主機的IP地址，那響應(yīng)報文回到宿主機的時候，宿主機又是如何轉(zhuǎn)給Docker Container的呢？關(guān)于這樣的響應(yīng)，由于port_3端口并沒有在宿主機上做相應(yīng)的DNAT轉(zhuǎn)換，原則上不會被發(fā)送至容器內(nèi)部。為什么說對于這樣的響應(yīng)，不會做DNAT轉(zhuǎn)換呢。原因很簡單，DNAT轉(zhuǎn)換是針對容器內(nèi)部服務(wù)監(jiān)聽的特定端口做的，該端口是供服務(wù)監(jiān)聽使用，而容器內(nèi)部發(fā)起的請求報文中，源端口號肯定不會占用服務(wù)監(jiān)聽的端口，故容器內(nèi)部發(fā)起請求的響應(yīng)不會在宿主機上經(jīng)過DNAT處理。
其實，這一環(huán)節(jié)的內(nèi)容是由iptables規(guī)則來完成，具體的iptables規(guī)則如下：
iptables -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT這條規(guī)則的意思是，在宿主機上發(fā)往docker0網(wǎng)橋的網(wǎng)絡(luò)數(shù)據(jù)報文，如果是該數(shù)據(jù)報文所處的連接已經(jīng)建立的話，則無條件接受，并由Linux內(nèi)核將其發(fā)送到原來的連接上，即回到Docker Container內(nèi)部。
以上便是Docker Container中bridge橋接模式的簡要介紹。可以說，bridger橋接模式從功能的角度實現(xiàn)了兩個方面：第一，讓容器擁有獨立、隔離的網(wǎng)絡(luò)棧；第二，讓容器和宿主機以外的世界通過NAT建立通信。
然而，bridge橋接模式下的Docker Container在使用時，并非為開發(fā)者包辦了一切。最明顯的是，該模式下Docker Container不具有一個公有IP，即和宿主機的eth0不處于同一個網(wǎng)段。導(dǎo)致的結(jié)果是宿主機以外的世界不能直接和容器進行通信。雖然NAT模式經(jīng)過中間處理實現(xiàn)了這一點，但是NAT模式仍然存在問題與不便，如：容器均需要在宿主機上競爭端口，容器內(nèi)部服務(wù)的訪問者需要使用服務(wù)發(fā)現(xiàn)獲知服務(wù)的外部端口等。另外NAT模式由于是在三層網(wǎng)絡(luò)上的實現(xiàn)手段，故肯定會影響網(wǎng)絡(luò)的傳輸效率。
3.2 host模式
Docker Container中的host模式與bridge橋接模式有很大的不同。最大的區(qū)別當屬，host模式并沒有為容器創(chuàng)建一個隔離的網(wǎng)絡(luò)環(huán)境。而之所以稱之為host模式，是因為該模式下的Docker Container會和host宿主機共享同一個網(wǎng)絡(luò)namespace，故Docker Container可以和宿主機一樣，使用宿主機的eth0，實現(xiàn)和外界的通信。換言之，Docker Container的IP地址即為宿主機eth0的IP地址。
Docker Container的host網(wǎng)絡(luò)模式可以參考下圖：
圖3.2 Docker Container host網(wǎng)絡(luò)模式示意圖
上圖最左側(cè)的Docker Container，即采用了host網(wǎng)絡(luò)模式，而其他兩個Docker Container依然沿用brdige橋接模式，兩種模式同時存在于宿主機上并不矛盾。
Docker Container的host網(wǎng)絡(luò)模式在實現(xiàn)過程中，由于不需要額外的網(wǎng)橋以及虛擬網(wǎng)卡，故不會涉及docker0以及veth pair。上文namespace的介紹中曾經(jīng)提到，父進程在創(chuàng)建子進程時，如果不使用CLONE_NEWNET這個參數(shù)標志，那么創(chuàng)建出的子進程會與父進程共享同一個網(wǎng)絡(luò)namespace。Docker就是采用了這個簡單的原理，在創(chuàng)建進程啟動容器的過程中，沒有傳入CLONE_NEWNET參數(shù)標志，實現(xiàn)Docker Container與宿主機共享同一個網(wǎng)絡(luò)環(huán)境，即實現(xiàn)host網(wǎng)絡(luò)模式。
可以說，Docker Container的網(wǎng)絡(luò)模式中，host模式是bridge橋接模式很好的補充。采用host模式的Docker Container，可以直接使用宿主機的IP地址與外界進行通信，若宿主機的eth0是一個公有IP，那么容器也擁有這個公有IP。同時容器內(nèi)服務(wù)的端口也可以使用宿主機的端口，無需額外進行NAT轉(zhuǎn)換。當然，有這樣的方便，肯定會損失部分其他的特性，最明顯的是Docker Container網(wǎng)絡(luò)環(huán)境隔離性的弱化，即容器不再擁有隔離、獨立的網(wǎng)絡(luò)棧。另外，使用host模式的Docker Container雖然可以讓容器內(nèi)部的服務(wù)和傳統(tǒng)情況無差別、無改造的使用，但是由于網(wǎng)絡(luò)隔離性的弱化，該容器會與宿主機共享競爭網(wǎng)絡(luò)棧的使用；另外，容器內(nèi)部將不再擁有所有的端口資源，原因是部分端口資源已經(jīng)被宿主機本身的服務(wù)占用，還有部分端口已經(jīng)用以bridge網(wǎng)絡(luò)模式容器的端口映射。
3.3 other container模式
Docker Container的other container網(wǎng)絡(luò)模式是Docker中一種較為特別的網(wǎng)絡(luò)的模式。之所以稱為“other container模式”，是因為這個模式下的Docker Container，會使用其他容器的網(wǎng)絡(luò)環(huán)境。之所以稱為“特別”，是因為這個模式下容器的網(wǎng)絡(luò)隔離性會處于bridge橋接模式與host模式之間。Docker Container共享其他容器的網(wǎng)絡(luò)環(huán)境，則至少這兩個容器之間不存在網(wǎng)絡(luò)隔離，而這兩個容器又與宿主機以及除此之外其他的容器存在網(wǎng)絡(luò)隔離。
Docker Container的other container網(wǎng)絡(luò)模式可以參考下圖：
圖3.3 Docker Container other container網(wǎng)絡(luò)模式示意圖
上圖右側(cè)的Docker Container即采用了other container網(wǎng)絡(luò)模式，它能使用的網(wǎng)絡(luò)環(huán)境即為左側(cè)Docker Container brdige橋接模式下的網(wǎng)絡(luò)。
Docker Container的other container網(wǎng)絡(luò)模式在實現(xiàn)過程中，不涉及網(wǎng)橋，同樣也不需要創(chuàng)建虛擬網(wǎng)卡veth pair。完成other container網(wǎng)絡(luò)模式的創(chuàng)建只需要兩個步驟：
(1) 查找other container（即需要被共享網(wǎng)絡(luò)環(huán)境的容器）的網(wǎng)絡(luò)namespace；
(2) 將新創(chuàng)建的Docker Container（也是需要共享其他網(wǎng)絡(luò)的容器）的namespace，使用other container的namespace。
Docker Container的other container網(wǎng)絡(luò)模式，可以用來更好的服務(wù)于容器間的通信。
在這種模式下的Docker Container可以通過localhost來訪問namespace下的其他容器，傳輸效率較高。雖然多個容器共享網(wǎng)絡(luò)環(huán)境，但是多個容器形成的整體依然與宿主機以及其他容器形成網(wǎng)絡(luò)隔離。另外，這種模式還節(jié)約了一定數(shù)量的網(wǎng)絡(luò)資源。但是需要注意的是，它并沒有改善容器與宿主機以外世界通信的情況。
3.4 none模式
Docker Container的第四種網(wǎng)絡(luò)模式是none模式。顧名思義，網(wǎng)絡(luò)環(huán)境為none，即不為Docker Container任何的網(wǎng)絡(luò)環(huán)境。一旦Docker Container采用了none網(wǎng)絡(luò)模式，那么容器內(nèi)部就只能使用loopback網(wǎng)絡(luò)設(shè)備，不會再有其他的網(wǎng)絡(luò)資源。
可以說none模式為Docker Container做了極少的網(wǎng)絡(luò)設(shè)定，但是俗話說得好“少即是多”，在沒有網(wǎng)絡(luò)配置的情況下，作為Docker開發(fā)者，才能在這基礎(chǔ)做其他無限多可能的網(wǎng)絡(luò)定制開發(fā)。這也恰巧體現(xiàn)了Docker設(shè)計理念的開放。
轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9602936.html
《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀總結(jié)
以上是生活随笔為你收集整理的Docker源码分析（七）：Docker Container网络 （上）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Docker源码分析（六）：Docker
- 下一篇： Docker源码分析（八）：Docker