當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

Docker源码分析（八）：Docker Container网络（下）

發(fā)布時間：2025/4/5 编程问答 41 豆豆

生活随笔收集整理的這篇文章主要介紹了 Docker源码分析（八）：Docker Container网络（下）小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

http://www.infoq.com/cn/articles/docker-source-code-analysis-part8

1.Docker Client配置容器網(wǎng)絡(luò)模式

Docker目前支持4種網(wǎng)絡(luò)模式，分別是bridge、host、container、none，Docker開發(fā)者可以根據(jù)自己的需求來確定最適合自己應(yīng)用場景的網(wǎng)絡(luò)模式。

從Docker Container網(wǎng)絡(luò)創(chuàng)建流程圖中可以看到，創(chuàng)建流程第一個涉及的Docker模塊即為Docker Client。當然，這也十分好理解，畢竟Docker Container網(wǎng)絡(luò)環(huán)境的創(chuàng)建需要由用戶發(fā)起，用戶根據(jù)自身對容器的需求，選擇網(wǎng)絡(luò)模式，并將其通過Docker Client傳遞給Docker Daemon。本節(jié)，即從Docker Client源碼的角度，分析如何配置Docker Container的網(wǎng)絡(luò)模式，以及Docker Client內(nèi)部如何處理這些網(wǎng)絡(luò)模式參數(shù)。

需要注意的是：配置Docker Container網(wǎng)絡(luò)環(huán)境與創(chuàng)建Docker Container網(wǎng)絡(luò)環(huán)境有一些區(qū)別。區(qū)別是：配置網(wǎng)絡(luò)環(huán)境指用戶通過向Docker Client傳遞網(wǎng)絡(luò)參數(shù)，實現(xiàn)Docker Container網(wǎng)絡(luò)環(huán)境參數(shù)的配置，這部分配置由Docker Client傳遞至Docker Daemon，并由Docker Daemon保存；創(chuàng)建網(wǎng)絡(luò)環(huán)境指，用戶通過Docker Client向Docker Daemon發(fā)送容器啟動命令之后，Docker Daemon根據(jù)之前保存的網(wǎng)絡(luò)參數(shù)，實現(xiàn)Docker Container的啟動，并在啟動過程中完成Docker Container網(wǎng)絡(luò)環(huán)境的創(chuàng)建。

以上的基本知識，理解下文的Docker Container網(wǎng)絡(luò)環(huán)境創(chuàng)建流程。

1.1 Docker Client使用

Docker架構(gòu)中，用戶可以通過Docker Client來配置Docker Container的網(wǎng)絡(luò)模式。配置過程主要通過docker run命令來完成，實現(xiàn)配置的方式是在docker run命令中添加網(wǎng)絡(luò)參數(shù)。使用方式如下（其中NETWORKMODE為四種網(wǎng)絡(luò)模式之一，ubuntu為鏡像名稱，/bin/bash為執(zhí)行指令）:

docker run -d --net NETWORKMODE ubuntu /bin/bash

運行以上命令時，首先創(chuàng)建一個Docker Client，然后Docker Client會解析整條命令的請求內(nèi)容，接著解析出為run請求，意為運行一個Docker Container，最終通過Docker Client端的API接口，調(diào)用CmdRun函數(shù)完成run請求執(zhí)行。（詳情可以查閱《Docker源碼分析》系列的第二篇——Docker Client篇）。

Docker Client解析出run命令之后，立即調(diào)用相應(yīng)的處理函數(shù)CmdRun進行處理關(guān)于run請求的具體內(nèi)容。CmdRun的作用主要可以歸納為三點：

解析Docker Client傳入的參數(shù)，解析出config、hostconfig和cmd對象等；
發(fā)送請求至Docker Daemon，創(chuàng)建一個container對象，完成Docker Container啟動前的準備工作；
發(fā)送請求至Docker Daemon，啟動相應(yīng)的Docker Container（包含創(chuàng)建Docker Container網(wǎng)絡(luò)環(huán)境創(chuàng)建）。

1.2 runconfig包解析

CmdRun函數(shù)的實現(xiàn)位于./docker/api/client/commands.go。CmdRun執(zhí)行的第一個步驟為：通過runconfig包中ParseSubcommand函數(shù)解析Docker Client傳入的參數(shù)，并從中解析出相應(yīng)的config，hostConfig以及cmd對象，實現(xiàn)代碼如下：

config, hostConfig, cmd, err := runconfig.ParseSubcommand (cli.Subcmd("run", "[OPTIONS] IMAGE [COMMAND] [ARG...]", "Run a command in a new container"), args, nil)

其中，config的類型為Config結(jié)構(gòu)體，hostConfig的類型為HostConfig結(jié)構(gòu)體，兩種類型的定義均位于runconfig包。Config與HostConfig類型同用以描述Docker Container的配置信息，然而兩者之間又有著本質(zhì)的區(qū)別，最大的區(qū)別在于兩者各自的作用范疇：

Config結(jié)構(gòu)體：描述Docker Container獨立的配置信息。獨立的含義是：Config這部分信息描述的是容器本身，而不會與容器所在host宿主機相關(guān)；
HostConfig結(jié)構(gòu)體：描述Docker Container與宿主機相關(guān)的配置信息。

1.2.1 Config結(jié)構(gòu)體

Config結(jié)構(gòu)體描述Docker Container本身的屬性信息，這些信息與容器所在的host宿主機無關(guān)。結(jié)構(gòu)體的定義如下：

type Config struct {Hostname stringDomainname stringUser stringMemory int64 // Memory limit (in bytes)MemorySwap int64 // Total memory usage (memory + swap); set `-1' to disable swapCpuShares int64 // CPU shares (relative weight vs. other containers)Cpuset string // Cpuset 0-2, 0,1AttachStdin boolAttachStdout boolAttachStderr boolPortSpecs []string // Deprecated - Can be in the format of 8080/tcpExposedPorts map[nat.Port]struct{}Tty bool // Attach standard streams to a tty, including stdin if it is not closed.OpenStdin bool // Open stdinStdinOnce bool // If true, close stdin after the 1 attached client disconnects.Env []stringCmd []stringImage string // Name of the image as it was passed by the operator (eg. could be symbolic)Volumes map[string]struct{}WorkingDir stringEntrypoint []stringNetworkDisabled boolOnBuild []string }

Config結(jié)構(gòu)體中各屬性的詳細解釋如下表：

Config結(jié)構(gòu)體屬性名	類型	代表含義
Hostname	string	容器主機名
Domainname	string	域名名稱
User	string	用戶名
Memory	int64	容器內(nèi)存使用上限（單位：字節(jié)）
MemorySwap	int64	容器所有的內(nèi)存使用上限（物理內(nèi)存+交互區(qū)），關(guān)閉交互區(qū)支持置為-1
CpuShares	int64	容器CPU使用share值，其他容器的相對值
Cpuset	string	CPU核的使用集合
AttachStdin	bool	是否附加標準輸入
AttachStdout	bool	是否附加標準輸出
AttachStderr	bool	是否附加標準錯誤輸出
PortsSpecs	[]string	目前已被遺棄
ExposedPorts	map[nat.Port]struct{}	容器內(nèi)部暴露的端口號
Tty	bool	是否分配一個偽終端tty
OpenStdin	bool	在沒有附加標準輸入時，是否依然打開標準輸入
StdinOnce	bool	若為真，表示第一個客戶關(guān)閉標準輸入后關(guān)閉標準輸入功能
Env	[]string	容器進程運行的環(huán)境變量
Cmd	[]string	容器內(nèi)通過ENTRYPOINT運行的指令
Image	string	容器rootfs所依賴的鏡像名稱
Volumes	map[string]struct{}	容器需要從host宿主機上掛載的目錄
WorkingDir	string	容器內(nèi)部的指定工作目錄
Entrypoint	[]string	覆蓋鏡像屬性中默認的ENTRYPOINT
NetworkDisabled	bool	是否關(guān)閉容器網(wǎng)絡(luò)功能
OnBuild	[]string	?

1.2.2 HostConfig結(jié)構(gòu)體

HostConfig結(jié)構(gòu)體描述Docker Container與宿主機相關(guān)的屬性信息，結(jié)構(gòu)體的定義如下：

type HostConfig struct {Binds []stringContainerIDFile stringLxcConf []utils.KeyValuePairPrivileged boolPortBindings nat.PortMapLinks []stringPublishAllPorts boolDns []stringDnsSearch []stringVolumesFrom []stringDevices []DeviceMappingNetworkMode NetworkModeCapAdd []stringCapDrop []stringRestartPolicy RestartPolicy }

Config結(jié)構(gòu)體中各屬性的詳細解釋如下表：

HostConfig結(jié)構(gòu)體屬性名	類型	代表含義
Binds	[]string	從宿主機上綁定到容器的volumes
ContainerIDFile	string	文件名，文件用以寫入容器的ID
LxcConf	[]utils.KeyValuePair	添加自定義的lxc選項
Privileged	bool	是否賦予該容器擴展權(quán)限
PortBindings	nat.PortMap	容器綁定到host宿主機的端口
Links	[]string	添加其他容器的鏈接到該容器
PublishAllPorts	bool	是否向宿主機暴露所有端口信息
Dns	[]string	自定義的DNS服務(wù)器地址
DnsSearch	[]string	自定義的DNS查找服務(wù)器地址
VolumesFrom	[]string	從指定的容器中掛載到該容器的volumes
Devices	[]DeviceMapping	為容器添加一個或多個宿主機設(shè)備
NetworkMode	NetworkMode	為容器設(shè)置的網(wǎng)絡(luò)模式
CapAdd	[]string	為容器用戶添加一個或多個Linux Capabilities
CapDrop	[]string	為容器用戶禁用一個或多個Linux Capabilities
RestartPolicy	RestartPolicy	當一個容器異常退出時采取的重啟策略

1.2.3 runconfig解析網(wǎng)絡(luò)模式

講述完Config與HostConfig結(jié)構(gòu)體之后，回到runconfig包中分析如何解析與Docker Container網(wǎng)絡(luò)模式相關(guān)的配置信息，并將這部分信息傳遞給config實例與hostConfig實例。

runconfig包中的ParseSubcommand函數(shù)調(diào)用parseRun函數(shù)完成命令請求的分析，實現(xiàn)代碼位于./docker/runconfig/parse.go#L37-L39，如下：

func ParseSubcommand(cmd *flag.FlagSet, args []string,sysInfo *sysinfo.SysInfo) (*Config, *HostConfig, *flag.FlagSet, error) {return parseRun(cmd, args, sysInfo) }

進入parseRun函數(shù)即可發(fā)現(xiàn)：該函數(shù)完成了四方面的工作：

定義與容器配置信息相關(guān)的flag參數(shù)；
解析docker run命令后緊跟的請求內(nèi)容，將請求內(nèi)容全部保存至flag參數(shù)中，余下的內(nèi)容一個為鏡像image名，另一個為需要在容器內(nèi)執(zhí)行的cmd命令；
通過flag參數(shù)驗證參數(shù)的有效性，并處理得到Config結(jié)構(gòu)體與HostConfig結(jié)構(gòu)體需要的屬性值；
創(chuàng)建并初始化Config類型實例config、HostConfig類型實例hostConfig，最總返回config、hostConfig與cmd。

本文主要分析Docker Container的網(wǎng)絡(luò)模式，而parseRun函數(shù)中有關(guān)容器網(wǎng)絡(luò)模式的flag參數(shù)有flNetwork與flNetMode，兩者的定義分別位于./docker/runconfig/parse.go#L62與./docker/runconfig/parse.go#L75，如下：

flNetwork = cmd.Bool([]string{"#n", "#-networking"}, true, "Enable networking for this container")

flNetMode = cmd.String([]string{"-net"}, "bridge", "Set the Network mode for the container\n'bridge': creates a new network stack for the container on the docker bridge\n'none': no networking for this container\n'container:<name|id>': reuses another container network stack\n'host': use the host network stack inside the container. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.")

可見flag參數(shù)flNetwork表示是否開啟容器的網(wǎng)絡(luò)模式，若為true則開啟，說明需要給容器創(chuàng)建網(wǎng)絡(luò)環(huán)境；否則不開啟，說明不給容器賦予網(wǎng)絡(luò)功能。該flag參數(shù)的默認值為true，另外使用該flag的方式為：在docker run之后設(shè)定--networking或者-n，如：

docker run --networking true ubuntu /bin/bash

另一個flag參數(shù)flNetMode則表示為容器設(shè)定的網(wǎng)絡(luò)模式，共有四種選項，分別是：bridge、none、container:<name|id>和host。四種模式的作用上文已經(jīng)詳細解釋，此處不再贅述。使用該flag的方式為：在docker run之后設(shè)定--net，如：

Docker run --net host ubuntu /bin/bash

用戶使用docker run啟動容器時設(shè)定了以上兩個flag參數(shù)（--networking和--net），則runconfig包會解析出這兩個flag的值。最終，通過flag參數(shù)flNetwork，得到Config類型實例config的屬性NetworkDisabled；通過flag參數(shù)flNetMode，得到HostConfig類型實例hostConfig的屬性NetworkMode。

函數(shù)parseRun返回config、hostConfig與cmd，代表著runconfig包解析配置參數(shù)工作的完成，CmdRun得到返回內(nèi)容之后，繼續(xù)向下執(zhí)行。

1.3 CmdRun執(zhí)行

在runconfig包中已經(jīng)將有關(guān)容器網(wǎng)絡(luò)模式的配置置于config對象與hostConfig對象，故在CmdRun函數(shù)的執(zhí)行中，更多的是基于config對象與hostConfig參數(shù)處理配置信息，而沒有其他的容器網(wǎng)絡(luò)處理部分。

CmdRun后續(xù)主要工作是：利用Docker Daemon暴露的RESTful API接口，將docker run的請求發(fā)送至Docker Daemon。以下是CmdRun執(zhí)行過程中Docker Client與Docker Daemon的簡易交互圖。

圖1.1 CmdRun中Docker Client與Docker Daemon交互圖

具體分析CmdRun的執(zhí)行流程可以發(fā)現(xiàn)：在解析config、hostConfig與cmd之后，Docker Client首先發(fā)起請求create container。若Docker Daemon節(jié)點上已經(jīng)存在該容器所需的鏡像，則立即執(zhí)行create container操作并返回請求響應(yīng)；Docker Client收到響應(yīng)后，再發(fā)起請求start container。若容器鏡像還不存在，Docker Daemon返回一個404的錯誤，表示鏡像不存在；Docker Client收到錯誤響應(yīng)之后，再發(fā)起一個請求pull image，使Docker Daemon首先下載鏡像，下載完畢之后Docker Client再次發(fā)起請求create container，Docker Daemon創(chuàng)建完畢之后，Docker Client最終發(fā)起請求start container。

總結(jié)而言，Docker Client負責創(chuàng)建容器請求的發(fā)起。關(guān)于Docker Container網(wǎng)絡(luò)環(huán)境的配置參數(shù)存儲于config與hostConfig對象之中，在請求create container和start container發(fā)起時，隨請求一起發(fā)送至Docker Daemon。

2.Docker Daemon創(chuàng)建容器網(wǎng)絡(luò)流程

Docker Daemon接收到Docker Client的請求大致可以分為兩次，第一次為create container，第二次為start container。這兩次請求的執(zhí)行過程中，都與Docker Container的網(wǎng)絡(luò)相關(guān)。以下按照這兩個請求的執(zhí)行，具體分析Docker Container網(wǎng)絡(luò)模式的創(chuàng)建。Docker Daemon如何通過Docker Server解析RESTful請求，并完成分發(fā)調(diào)度處理，在《Docker源碼分析》系列的第五篇——Docker Server篇中已經(jīng)詳細分析過，本文不再贅述。

2.1創(chuàng)建容器并配置網(wǎng)絡(luò)參數(shù)

Docker Daemon首先接收并處理create container請求。需要注意的是：create container并非創(chuàng)建了一個運行的容器，而是完成了以下三個主要的工作：

通過runconfig包解析出create container請求中與Docker Container息息相關(guān)的config對象；
在Docker Daemon內(nèi)部創(chuàng)建了與Docker Container對應(yīng)的container對象；
完成Docker Container啟動前的準備化工作，如準備所需鏡像、創(chuàng)建rootfs等。

創(chuàng)建容器過程中，Docker Daemon首先通過runconfig包中ContainerConfigFromJob函數(shù)，解析出請求中的config對象，解析過程代碼如下：

config := runconfig.ContainerConfigFromJob(job)

至此，Docker Client處理得到的config對象，已經(jīng)傳遞至Docker Daemon的config對象，config對象中已經(jīng)含有屬性NetworkDisabled具體值。

處理得到config對象之后，Docker Daemon緊接著創(chuàng)建container對象，并為Docker Container作相應(yīng)的準備工作。具體的實現(xiàn)代碼位于./docker/daemon/create.go#L73-L78，如下：

if container, err = daemon.newContainer(name, config, img); err != nil {return nil, nil, err } if err := daemon.createRootfs(container, img); err != nil {return nil, nil, err }

與Docker Container網(wǎng)絡(luò)模式配置相關(guān)的內(nèi)容主要位于創(chuàng)建container對象中。newContainer函數(shù)的定義位于./docker/daemon/daemon.go#L516-L550，具體的container對象如下：

container := &Container{ID: id,Created: time.Now().UTC(),Path: entrypoint,Args: args, //FIXME: de-duplicate from configConfig: config,hostConfig: &runconfig.HostConfig{},Image: img.ID, // Always use the resolved image idNetworkSettings: &NetworkSettings{},Name: name,Driver: daemon.driver.String(),ExecDriver: daemon.execDriver.Name(),State: NewState(), }

在container對象中，config對象直接賦值給container對象的Config屬性，另外hostConfig屬性與NetworkSeeetings屬性均為空。其中hostConfig對象將在start container請求執(zhí)行過程中被賦值，NetworkSettings類型的作用是描述容器的網(wǎng)絡(luò)具體信息，定義位于./docker/daemon/network_settings.go#L11-L18，代碼如下：

type NetworkSettings struct {IPAddress stringIPPrefixLen intGateway stringBridge stringPortMapping map[string]PortMapping // DeprecatedPorts nat.PortMap }

Networksettings類型的各屬性的詳細解釋如下表：

NetworkSettings屬性名稱	類型	含義
IPAddress	string	IP網(wǎng)絡(luò)地址
IPPrefixLen	int	網(wǎng)絡(luò)標識位長度
Gateway	string	網(wǎng)關(guān)地址
Bridge	string	網(wǎng)橋地址
PortMapping	map[string]PortMapping	端口映射
Ports	nat.PortMap	端口號

總結(jié)而言，Docker Daemon關(guān)于create container請求的執(zhí)行，先實現(xiàn)了容器配置信息從Docker Client至Docker Daemon的轉(zhuǎn)移，再完成了啟動容器前所需的準備工作。

2.2啟動容器之網(wǎng)絡(luò)配置

創(chuàng)建容器階段，Docker Daemon創(chuàng)建了容器對象container，container對象內(nèi)部的Config屬性含有NetworkDisabled。創(chuàng)建容器完成之后，Docker Daemon還需要接收Docker Client的請求，并執(zhí)行start container的操作，即啟動容器。

啟動容器過程中，Docker Daemon首先通過runconfig包中ContainerHostConfigFromJob函數(shù)，解析出請求中的hostConfig對象，解析過程代碼如下：

hostConfig := runconfig.ContainerHostConfigFromJob(job)

至此，Docker Client處理得到的hostConfig對象，已經(jīng)傳遞至Docker Daemon的hostConfig對象，hostConfig對象中已經(jīng)含有屬性NetworkMode具體值。

容器啟動的所有工作，均由以下的Start函數(shù)來完成，代碼位于./docker/daemon/start.go#L36-L38，如下：

if err := container.Start(); err != nil {return job.Errorf("Cannot start container %s: %s", name, err)}

Start函數(shù)實現(xiàn)了容器的啟動。更為具體的描述是：Start函數(shù)實現(xiàn)了進程的啟動，另外在啟動進程的同時為進程設(shè)定了命名空間（namespace），啟動完畢之后為進程完成了資源使用的控制，從而保證進程以及之后進程的子進程都會在同一個命名空間內(nèi)，且受到相同的資源控制。如此一來，Start函數(shù)創(chuàng)建的進程，以及該進程的子進程，形成一個進程組，該進程組處于資源隔離和資源控制的環(huán)境，我們習慣將這樣的進程組環(huán)境稱為容器，也就是這里的Docker Container。

回到Start函數(shù)的執(zhí)行，位于./docker/daemon/container.go#L275-L320。Start函數(shù)執(zhí)行過程中，與Docker Container網(wǎng)絡(luò)模式相關(guān)的部分主要有三部分：

initializeNetwork()，初始化container對象中與網(wǎng)絡(luò)相關(guān)的屬性；
populateCommand，填充Docker Container內(nèi)部需要執(zhí)行的命令，Command中含有進程啟動命令，還含有容器環(huán)境的配置信息，也包括網(wǎng)絡(luò)配置；
container.waitForStart()，實現(xiàn)Docker Container內(nèi)部進程的啟動，進程啟動之后，為進程創(chuàng)建網(wǎng)絡(luò)環(huán)境等。

2.2.1初始化容器網(wǎng)絡(luò)配置

容器對象container中有屬性hostConfig，屬性hostConfig中有屬性NetworkMode，初始化容器網(wǎng)絡(luò)配置initializeNetworking()的主要工作就是，通過NetworkMode屬性為Docker Container的網(wǎng)絡(luò)作相應(yīng)的初始化配置工作。

Docker Container的網(wǎng)絡(luò)模式有四種，分別為：host、other container、none以及bridge。initializeNetworking函數(shù)的執(zhí)行完全覆蓋了這四種模式。

initializeNetworking()函數(shù)的實現(xiàn)位于./docker/daemon/container.go#L881-L933。

2.2.1.1 初始化host網(wǎng)絡(luò)模式配置

Docker Container網(wǎng)絡(luò)的host模式意味著容器使用宿主機的網(wǎng)絡(luò)環(huán)境。雖然Docker Container使用宿主機的網(wǎng)絡(luò)環(huán)境，但這并不代表Docker Container可以擁有宿主機文件系統(tǒng)的視角，而host宿主機上有很多信息標識的是網(wǎng)絡(luò)信息，故Docker Daemon需要將這部分標識網(wǎng)絡(luò)的信息，從host宿主機添加到Docker Container內(nèi)部的指定位置。這樣的網(wǎng)絡(luò)信息，主要有以下兩種：

host宿主機的主機名（hostname）；
host宿主機上/etc/hosts文件，用于配置IP地址以及主機名。

其中，宿主機的主機名hostname用于創(chuàng)建container.Config中的Hostname與Domainname屬性。

另外，Docker Daemon在Docker Container的rootfs內(nèi)部創(chuàng)建hostname文件，并在文件中寫入Hostname與Domainname；同時創(chuàng)建hosts文件，并寫入host宿主機上/etc/hosts內(nèi)的所有內(nèi)容。

2.2.1.2 初始化other container網(wǎng)絡(luò)模式配置

Docker Container的other container網(wǎng)絡(luò)模式意味著：容器使用其他已經(jīng)創(chuàng)建容器的網(wǎng)絡(luò)環(huán)境。

Docker Daemon首先判斷host網(wǎng)絡(luò)模式之后，若不為host網(wǎng)絡(luò)模式，則繼續(xù)判斷Docker Container網(wǎng)絡(luò)模式是否為other container。如果Docker Container的網(wǎng)絡(luò)模式為other container（假設(shè)使用的-net參數(shù)為--net=container:17adef，其中17adef為容器ID）。Docker Daemon所做的執(zhí)行操作包括兩部分。

第一步，從container對象的hostConfig屬性中找出NetworkMode，并找到相應(yīng)的容器，即17adef的容器對象container，實現(xiàn)代碼如下：

nc, err := container.getNetworkedContainer()

第二步，將17adef容器對象的HostsPath、ResolveConfPath、Hostname和Domainname賦值給當前容器對象container，實現(xiàn)代碼如下：

container.HostsPath = nc.HostsPath container.ResolvConfPath = nc.ResolvConfPath container.Config.Hostname = nc.Config.Hostname container.Config.Domainname = nc.Config.Domainname

2.2.1.3 初始化none網(wǎng)絡(luò)模式配置

Docker Container的none網(wǎng)絡(luò)模式意味著不給該容器創(chuàng)建任何網(wǎng)絡(luò)環(huán)境，容器只能使用127.0.0.1的本機網(wǎng)絡(luò)。

Docker Daemon通過config屬性的DisableNetwork來判斷是否為none網(wǎng)絡(luò)模式。實現(xiàn)代碼如下：

if container.daemon.config.DisableNetwork {container.Config.NetworkDisabled = truereturn container.buildHostnameAndHostsFiles("127.0.1.1")}

2.2.1.4 初始化bridge網(wǎng)絡(luò)模式配置

Docker Container的bridge網(wǎng)絡(luò)模式意味著為容器創(chuàng)建橋接網(wǎng)絡(luò)模式。橋接模式使得Docker Container創(chuàng)建獨立的網(wǎng)絡(luò)環(huán)境，并通過“橋接”的方式實現(xiàn)Docker Container與外界的網(wǎng)絡(luò)通信。

初始化bridge網(wǎng)絡(luò)模式的配置，實現(xiàn)代碼如下：

if err := container.allocateNetwork(); err != nil {return err } return container.buildHostnameAndHostsFiles(container.NetworkSettings.IPAddress)

以上代碼完成的內(nèi)容主要也是兩部分：第一，通過allocateNetwork函數(shù)為容器分配網(wǎng)絡(luò)接口設(shè)備需要的資源信息（包括IP、bridge、Gateway等），并賦值給container對象的NetworkSettings；第二，為容器創(chuàng)建hostname以及創(chuàng)建Hosts等文件。

2.2.2創(chuàng)建容器Command信息

Docker在實現(xiàn)容器時，使用了Command類型。Command在Docker Container概念中是一個非常重要的概念。幾乎可以認為Command是Docker Container生命周期的源頭。Command的概念會貫穿以后的《Docker源碼分析》系列，比如Docker Daemon與dockerinit的關(guān)系，dockerinit和entrypoint.sh的關(guān)系，entrypoint.sh與CMD的關(guān)系，以及namespace在這些內(nèi)容中扮演的角色。

簡單來說，Command類型包含了兩部分的內(nèi)容：第一，運行容器內(nèi)進程的外部命令exec.Cmd；第二，運行容器時啟動進程需要的所有環(huán)境基礎(chǔ)信息：包括容器進程組的使用資源、網(wǎng)絡(luò)環(huán)境、使用設(shè)備、工作路徑等。通過這兩部分的內(nèi)容，我們可以清楚，如何啟動容器內(nèi)的進程，同時也清楚為容器創(chuàng)建什么樣的環(huán)境。

首先，我們先來看Command類型的定義，位于./docker/daemon/execdriver/driver.go#L84，通過分析Command類型以及其他相關(guān)的數(shù)據(jù)結(jié)構(gòu)類型，可以得到以下簡要類型關(guān)系圖：

圖 2.1 Command類型關(guān)系圖

從Command類型關(guān)系圖中可以看到，Command類型中重新包裝了exec.Cmd類型，即代表需要創(chuàng)建的進程具體的外部命令；同時，關(guān)于網(wǎng)絡(luò)方面的屬性有Network，Network的類型為指向Network類型的指針；關(guān)于Docker Container資源使用方面的屬性為Resources，從Resource的類型來看，Docker目前能做的資源限制有4個維度，分別為內(nèi)存，內(nèi)存+Swap，CPU使用，CPU核使用；關(guān)于掛載的內(nèi)容，有屬性Mounts；等等。

簡單介紹Command類型之后，回到Docker Daemon啟動容器網(wǎng)絡(luò)的源碼分析。在Start函數(shù)的執(zhí)行流程中，緊接initializeNetworking()之后，與Docker Container網(wǎng)絡(luò)相關(guān)的是populateCommand環(huán)節(jié)。populateCommand的函數(shù)實現(xiàn)位于./docker/daemon/container.go#L191-L274。上文已經(jīng)提及，populateCommand的作用是創(chuàng)建包execdriver的對象Command，該Command中既有啟動容器進程的外部命令，同時也有眾多為容器環(huán)境的配置信息，包括網(wǎng)絡(luò)。

本小節(jié)，更多的分析populateCommand如何填充Command對象中的網(wǎng)絡(luò)信息，其他信息的分析會在《源碼分析系列》的后續(xù)進行展開。

Docker總共有四種網(wǎng)絡(luò)模式，故populateCommand自然需要判斷容器屬于哪種網(wǎng)絡(luò)模式，隨后將具體的網(wǎng)絡(luò)模式信息，寫入Command對象的Network屬性中。查驗Docker Container網(wǎng)絡(luò)模式的代碼位于./docker/daemon/container.go#L204-L227，如下：

parts := strings.SplitN(string(c.hostConfig.NetworkMode), ":", 2)switch parts[0] {case "none":case "host":en.HostNetworking = truecase "bridge", "": // empty string to support existing containersif !c.Config.NetworkDisabled {network := c.NetworkSettingsen.Interface = &execdriver.NetworkInterface{Gateway: network.Gateway,Bridge: network.Bridge,IPAddress: network.IPAddress,IPPrefixLen: network.IPPrefixLen,}}case "container":nc, err := c.getNetworkedContainer()if err != nil {return err}en.ContainerID = nc.IDdefault:return fmt.Errorf("invalid network mode: %s", c.hostConfig.NetworkMode)}

populateCommand首先通過hostConfig對象中的NetworkMode判斷容器屬于哪種網(wǎng)絡(luò)模式。該部分內(nèi)容涉及到execdriver包中的Network類型，可參見Command類型關(guān)系圖中的Network類型。若為none模式，則對于Network對象（即en，*execdriver.Network）不做任何操作。若為host模式，則將Network對象的HostNetworking置為true；若為bridge橋接模式，則首先創(chuàng)建一個NetworkInterface對象，完善該對象的Gateway、Bridge、IPAddress和IPPrefixLen信息，最后將NetworkInterface對象作為Network對象的Interface屬性的值；若為other container模式，則首先通過getNetworkedContainer()函數(shù)獲知被分享網(wǎng)絡(luò)命名空間的容器，最后將容器ID，賦值給Network對象的ContainerID。由于bridge模式、host模式、none模式以及other container模式彼此互斥，故Network對象中Interface屬性、ContainerID屬性以及HostNetworking三者之中只有一個被賦值。當Docker Container的網(wǎng)絡(luò)查驗之后，populateCommand將en實例Network屬性的值，傳遞給Command對象。

至此，populateCommand關(guān)于網(wǎng)絡(luò)方面的信息已經(jīng)完成配置，網(wǎng)絡(luò)配置信息已經(jīng)成功賦值于Command的Network屬性。。

2.2.3啟動容器內(nèi)部進程

當為容器做好所有的準備與配置之后，Docker Daemon需要真正意義上的啟動容器。根據(jù)Docker Daemon啟動容器流程涉及的Docker模塊中可以看到，這樣的請求，會被發(fā)送至execdriver，再經(jīng)過libcontainer，最后實現(xiàn)真正啟動進程，創(chuàng)建完容器。

回到Docker Daemon的啟動容器，daemon包中start函數(shù)的最后一步即為執(zhí)行container.waitForStart()。waitForStart函數(shù)的定義位于./docker/daemon/container.go#L1070-L1082，代碼如下：

func (container *Container) waitForStart() error {container.monitor = newContainerMonitor(container, container.hostConfig.RestartPolicy)select {case <-container.monitor.startSignal:case err := <-utils.Go(container.monitor.Start):return err}return nil }

以上代碼運行過程中首先通過newContainerMonitor返回一個初始化的containerMonitor對象，該對象中帶有容器進程的重啟策略（RestartPolicy）。這里簡單介紹containerMonitor對象。總體而言，containerMonitor對象用以監(jiān)視容器中第一個進程的執(zhí)行。如果containerMonitor中指定了一種進程重啟策略，那么一旦容器內(nèi)部進程沒有啟動成功，Docker Daemon會使用重啟策略來重啟容器。如果在重啟策略下，容器依然沒有成功啟動，那么containerMonitor對象會負責重置以及清除所有已經(jīng)為容器準備好的資源，例如已經(jīng)為容器分配好的網(wǎng)絡(luò)資源（即IP地址），還有為容器準備的rootfs等。

waitForStart()函數(shù)通過container.monitor.Start來實現(xiàn)容器的啟動，進入./docker/daemon/monitor.go#L100，可以發(fā)現(xiàn)啟動容器進程位于./docker/daemon/monitor.go#L136，代碼如下：

exitStatus, err = m.container.daemon.Run(m.container, pipes, m.callback)

以上代碼實際調(diào)用了daemon包中的Run函數(shù)，位于./docker/daemon/daemon.go#L969-L971，代碼如下：

func (daemon *Daemon) Run(c *Container, pipes *execdriver.Pipes, startCallback execdriver.StartCallback) (int, error) {return daemon.execDriver.Run(c.command, pipes, startCallback) }

最終，Run函數(shù)中調(diào)用了execdriver中的Run函數(shù)來執(zhí)行Docker Container的啟動命令。

至此，網(wǎng)絡(luò)部分在Docker Daemon內(nèi)部的執(zhí)行已經(jīng)結(jié)束，緊接著程序運行邏輯陷入execdriver，進一步完成容器啟動的相關(guān)步驟。

3.execdriver網(wǎng)絡(luò)執(zhí)行流程

Docker架構(gòu)中execdriver的作用是啟動容器內(nèi)部進程，最終啟動容器。目前，在Docker中execdriver作為執(zhí)行驅(qū)動，可以有兩種選項：lxc與native。其中，lxc驅(qū)動會調(diào)用lxc工具實現(xiàn)容器的啟動，而native驅(qū)動會使用Docker官方發(fā)布的libcontainer來啟動容器。

Docker Daemon啟動過程中，execdriver的類型默認為native，故本文主要分析native驅(qū)動在執(zhí)行啟動容器時，如何處理網(wǎng)絡(luò)部分。

在Docker Daemon啟動容器的最后一步，即調(diào)用了execdriver的Run函數(shù)來執(zhí)行。通過分析Run函數(shù)的具體實現(xiàn)，關(guān)于Docker Container的網(wǎng)絡(luò)執(zhí)行流程主要包括兩個環(huán)節(jié)：

(1) 創(chuàng)建libcontainer的Config對象

(2) 通過libcontainer中的namespaces包執(zhí)行啟動容器

將execdriver.Run函數(shù)的運行流程具體展開，與Docker Container網(wǎng)絡(luò)相關(guān)的流程，可以得到以下示意圖：

圖3.1 execdriver.Run執(zhí)行流程圖

3.1創(chuàng)建libcontainer的Config對象

Run函數(shù)位于./docker/daemon/execdriver/native/driver.go#L62-L168，進入Run函數(shù)的實現(xiàn)，立即可以發(fā)現(xiàn)該函數(shù)通過createContainer創(chuàng)建了一個container對象，代碼如下：

container, err := d.createContainer(c)

其中c為Docker Daemon創(chuàng)建的execdriver.Command類型實例。以上代碼的createContainer函數(shù)的作用是：使用execdriver.Command來填充libcontainer.Config。

libcontainer.Config的作用是，定義在一個容器化的環(huán)境中執(zhí)行一個進程所需要的所有配置項。createContainer函數(shù)的存在，使用Docker Daemon層創(chuàng)建的execdriver.Command，創(chuàng)建更下層libcontainer所需要的Config對象。這個角度來看，execdriver更像是封裝了libcontainer對外的接口，實現(xiàn)了將Docker Daemon認識的容器啟動信息轉(zhuǎn)換為底層libcontainer能真正使用的容器啟動配置選項。libcontainer.Config類型與其內(nèi)部對象的關(guān)聯(lián)圖如下：

圖3.2 libcontainer.Config類型關(guān)系圖

進入createContainer的源碼實現(xiàn)部分，位于./docker/daemon/execdriver/native/create.go#L23-L77，代碼如下：

func (d *driver) createContainer(c *execdriver.Command) (*libcontainer.Config, error) {container := template.New()……if err := d.createNetwork(container, c); err != nil {return nil, err}……return container, nil }

3.1.1 libcontainer.Config模板實例

從createContainer函數(shù)的實現(xiàn)以及execdriver.Run執(zhí)行流程圖中都可以看到，createContainer所做的第一個操作就是即為執(zhí)行template.New()，意為創(chuàng)建一個libcontainer.Config的實例container。其中，template.New()的定義位于./docker/daemon/execdriver/native/template/default_template.go，主要的作用為返回libcontainer關(guān)于Docker Container的默認配置選項。

Template.New()的代碼實現(xiàn)如下：

func New() *libcontainer.Config {container := &libcontainer.Config{Capabilities: []string{"CHOWN","DAC_OVERRIDE","FSETID","FOWNER","MKNOD","NET_RAW","SETGID","SETUID","SETFCAP","SETPCAP","NET_BIND_SERVICE","SYS_CHROOT","KILL","AUDIT_WRITE",},Namespaces: map[string]bool{"NEWNS": true,"NEWUTS": true,"NEWIPC": true,"NEWPID": true,"NEWNET": true,},Cgroups: &cgroups.Cgroup{Parent: "docker",AllowAllDevices: false,},MountConfig: &libcontainer.MountConfig{},}if apparmor.IsEnabled() {container.AppArmorProfile = "docker-default"}return container }

關(guān)于該libcontainer.Config默認的模板對象，從源碼實現(xiàn)中可以看到，首先設(shè)定了Capabilities的默認項，如CHOWN、DAC_OVERRIDE、FSETID等；其次又將Docker Container所需要的設(shè)定的namespaces添加默認值，即需要創(chuàng)建5個NAMESPACE，如NEWNS、NEWUTS、NEWIPC、NEWPID和NEWNET，其中不包括user namespace，另外與網(wǎng)絡(luò)相關(guān)的namespace為NEWNET；最后設(shè)定了一些關(guān)于cgroup以及apparmor的默認配置。

Template.New()函數(shù)最后返回類型為libcontainer.Config的實例container，該實例中只含有默認配置項，其他的配置項的添加需要createContainer的后續(xù)操作來完成。

3.1.2 createNetwork實現(xiàn)

在createContainer的實現(xiàn)流程中，為了完成container對象（類型為libcontainer.Config）的完善，最后有很多步驟，如與網(wǎng)絡(luò)相關(guān)的createNetwork函數(shù)調(diào)用，與Linux內(nèi)核Capabilities相關(guān)的setCapabilities函數(shù)調(diào)用，與cgroups相關(guān)的setupCgroups函數(shù)調(diào)用，以及與掛載目錄相關(guān)的setupMounts函數(shù)調(diào)用等。本小節(jié)主要分析createNetwork如何為container對象完善網(wǎng)絡(luò)配置項。

createNetwork函數(shù)的定義位于./docker/daemon/execdriver/native/create.go#L79-L124，該函數(shù)主要利用execdriver.Command中Network屬性中的內(nèi)容，來判斷如何創(chuàng)建libcontainer.Config中Network屬性（關(guān)于兩中Network屬性，可以參見圖3.1和圖3.2）。由于Docker Container的4種網(wǎng)絡(luò)模式彼此互斥，故以上Network類型中Interface、ContainerID與HostNetworking最多只有一項會被賦值。

由于execdriver.Command中Network的類型定義如下：

type Network struct {Interface *NetworkInterfaceMtu int ContainerID string HostNetworking bool }

分析createNetwork函數(shù)，其具體實現(xiàn)可以歸納為4部分內(nèi)容：

(1) 判斷網(wǎng)絡(luò)是否為host模式；

(2) 判斷是否為bridge橋接模式；

(3) 判斷是否為other container模式；

(4) 為Docker Container添加loopback網(wǎng)絡(luò)設(shè)備。

首先來看execdriver判斷是否為host模式的代碼：

if c.Network.HostNetworking {container.Namespaces["NEWNET"] = falsereturn nil }

當execdriver.Command類型實例中Network屬性的HostNetworking為true，則說明需要為Docker Container創(chuàng)建host網(wǎng)絡(luò)模式，使得容器與宿主機共享同樣的網(wǎng)絡(luò)命名空間。關(guān)于host模式的具體介紹中，已經(jīng)闡明，只須在創(chuàng)建進程進行CLONE系統(tǒng)調(diào)用時，不傳入CLONE_NEWNET參數(shù)標志即可實現(xiàn)。這里的代碼正好準確的驗證了這一點，將container對象中NEWNET的Namespace設(shè)為false，最終在libcontainer中可以達到效果。

再看execdriver判斷是否為bridge橋接模式的代碼：

if c.Network.Interface != nil {vethNetwork := libcontainer.Network{Mtu: c.Network.Mtu,Address: fmt.Sprintf("%s/%d", c.Network.Interface.IPAddress, c.Network.Interface.IPPrefixLen),Gateway: c.Network.Interface.Gateway,Type: "veth",Bridge: c.Network.Interface.Bridge,VethPrefix: "veth",}container.Networks = append(container.Networks, &vethNetwork)}

當execdriver.Command類型實例中Network屬性的Interface不為nil值，則說明需要為Docker Container創(chuàng)建bridge橋接模式，使得容器使用隔離的網(wǎng)絡(luò)環(huán)境。于是這里為類型為libcontainer.Config的container對象添加Networks屬性vethNetwork，網(wǎng)絡(luò)類型為“veth”，以便libcontainer在執(zhí)行時，可以為Docker Container創(chuàng)建veth pair。

接著來看execdriver判斷是否為other container模式的代碼：

if c.Network.ContainerID != "" {d.Lock()active := d.activeContainers[c.Network.ContainerID]d.Unlock()if active == nil || active.cmd.Process == nil {return fmt.Errorf("%s is not a valid running container to join", c.Network.ContainerID)}cmd := active.cmdnspath := filepath.Join("/proc", fmt.Sprint(cmd.Process.Pid), "ns", "net")container.Networks = append(container.Networks, &libcontainer.Network{Type: "netns",NsPath: nspath,})}

當execdriver.Command類型實例中Network屬性的ContainerID不為空字符串時，則說明需要為Docker Container創(chuàng)建other container模式，使得創(chuàng)建容器使用其他容器的網(wǎng)絡(luò)環(huán)境。實現(xiàn)過程中，execdriver需要首先在activeContainers中查找需要被共享網(wǎng)絡(luò)環(huán)境的容器active；并通過active容器的啟動執(zhí)行命令cmd找到容器第一進程在宿主機上的PID；隨后在proc文件系統(tǒng)中找到該進程PID的關(guān)于網(wǎng)絡(luò)namespace的路徑nspath；最后為類型為libcontainer.Config的container對象添加Networks屬性，Network的類型為“netns”。

此外，createNetwork函數(shù)還實現(xiàn)為Docker Container創(chuàng)建一個loopback回環(huán)設(shè)備，以便容器可以實現(xiàn)內(nèi)部通信。實現(xiàn)過程中，同樣為類型libcontainer.Config的container對象添加Networks屬性，Network的類型為“l(fā)oopback”，代碼如下：

container.Networks = []*libcontainer.Network{{Mtu: c.Network.Mtu,Address: fmt.Sprintf("%s/%d", "127.0.0.1", 0),Gateway: "localhost",Type: "loopback",},}

至此，createNetwork函數(shù)已經(jīng)把與網(wǎng)絡(luò)相關(guān)的配置，全部創(chuàng)建在類型為libcontainer.Config的container對象中了，就等著啟動容器進程時使用。

3.2 調(diào)用libcontainer的namespaces啟動容器

回到execdriver.Run函數(shù)，創(chuàng)建完libcontainer.Config實例container，經(jīng)過一系列其他方面的處理之后，最終execdriver執(zhí)行namespaces.Exec函數(shù)實現(xiàn)啟動容器，container對象依然是namespace.Exec函數(shù)中一個非常重要的參數(shù)。這一環(huán)節(jié)代表著execdriver把啟動Docker Container的工作交給libcontainer，以后的執(zhí)行陷入libcontainer。

調(diào)用namespaces.Exec的代碼位于./docker/daemon/execdriver/native/driver.go#L102-L127，為了便于理解，簡化的代碼如下：

namespaces.Exec(container, c.Stdin, c.Stdout, c.Stderr, c.Console,c.Rootfs, dataPath, args, parameter_1, parameter_2)

其中parameter_1為定義的函數(shù)，如下：

func(container *libcontainer.Config, console, rootfs, dataPath, init string, child *os.File, args []string) *exec.Cmd {c.Path = d.initPathc.Args = append([]string{DriverName,"-console", console,"-pipe", "3","-root", filepath.Join(d.root, c.ID),"--",}, args...)// set this to nil so that when we set the clone flags anything else is resetc.SysProcAttr = &syscall.SysProcAttr{Cloneflags: uintptr(namespaces.GetNamespaceFlags(container.Namespaces)),}c.ExtraFiles = []*os.File{child}c.Env = container.Envc.Dir = c.Rootfsreturn &c.Cmd}

同樣的，parameter_2也為定義的函數(shù)，如下：

func() {if startCallback != nil {c.ContainerPid = c.Process.PidstartCallback(c)}}

Parameter_1以及parameter_2這兩個函數(shù)均會在libcontainer的namespaces中發(fā)揮很大的重要。

至此，execdriver模塊的執(zhí)行部分已經(jīng)完結(jié)，Docker Daemon的程序運行邏輯陷入libcontainer。

4.libcontainer實現(xiàn)內(nèi)核態(tài)網(wǎng)絡(luò)配置

libcontainer是一個Linux操作系統(tǒng)上容器的實現(xiàn)包。libcontainer指定了創(chuàng)建一個容器時所需要的配置選項，同時它利用Linux namespace和cgroup等技術(shù)為使用者提供了一套Golang原生態(tài)的容器實現(xiàn)方案，并且沒有使用任何外部依賴。用戶借助libcontainer，可以感受到眾多操縱namespaces，網(wǎng)絡(luò)等資源的便利。

當execdriver調(diào)用libcontainer中namespaces包的Exec函數(shù)時，libcontainer開始發(fā)揮其實現(xiàn)容器功能的作用。Exec函數(shù)位于./libcontainer/namespaces/exec.go#L24-L113。本文更多的關(guān)心Docker Container的網(wǎng)絡(luò)創(chuàng)建，因此從這個角度來看Exec的實現(xiàn)可以分為三個步驟：

(1) 通過createCommand創(chuàng)建一個Golang語言內(nèi)的exec.Cmd對象；

(2) 啟動命令exec.Cmd，執(zhí)行容器內(nèi)第一個進程；

(3) 通過InitializeNetworking函數(shù)為容器進程初始化網(wǎng)絡(luò)環(huán)境。

以下詳細分析這三個部分，源碼的具體實現(xiàn)。

4.1創(chuàng)建exec.Cmd

提到exec.Cmd，就不得不提Go語言標準庫中的包os以及包os/exec。前者提供了與平臺無關(guān)的操作系統(tǒng)功能集，后者則提供了功能集里與命令執(zhí)行相關(guān)的部分。

首先來看一下在Go語言中exec.Cmd的定義，如下：

type Cmd struct {Path string //所需執(zhí)行命令在系統(tǒng)中的路徑Args []string //傳入命令的參數(shù)Env []string //進程運行時的環(huán)境變量Dir string //命令運行的工作目錄Stdin io.ReaderStdout io.WriterStderr io.WriterExtraFiles []*os.File //進程所需打開的文件描述符資源SysProcAttr *syscall.SysProcAttr //可選的操作系統(tǒng)屬性Process *os.Process //代表Cmd啟動后，操作系統(tǒng)底層的具體進程ProcessState *os.ProcessState //進程退出后保留的信息 }

清楚Cmd的定義之后，再來分析namespaces包的Exec函數(shù)中，是如何來創(chuàng)建exec.Cmd的。在Exec函數(shù)的實現(xiàn)過程中，使用了以下代碼實現(xiàn)Exec.Cmd的創(chuàng)建：

command := createCommand(container, console, rootfs, dataPath, os.Args[0], syncPipe.Child(), args)

其中createCommand為namespace.Exec函數(shù)中傳入的倒數(shù)第二個參數(shù)，類型為CreateCommand。而createCommand只是namespaces.Exec函數(shù)的形參，真正的實參則為execdriver調(diào)用namespaces.Exec時的參數(shù)parameter_1，即如下代碼：

func(container *libcontainer.Config, console, rootfs, dataPath,init string, child *os.File, args []string) *exec.Cmd {c.Path = d.initPathc.Args = append([]string{DriverName,"-console", console,"-pipe", "3","-root", filepath.Join(d.root, c.ID),"--",}, args...)// set this to nil so that when we set the clone flags anything else is resetc.SysProcAttr = &syscall.SysProcAttr{Cloneflags: uintptr(namespaces.GetNamespaceFlags(container.Namespaces)),}c.ExtraFiles = []*os.File{child}c.Env = container.Envc.Dir = c.Rootfsreturn &c.Cmd}

熟悉exec.Cmd的定義之后，分析以上代碼的實現(xiàn)就顯得較為簡單。為Cmd賦值的對象有Path，Args，SysProcAttr，ExtraFiles，Env和Dir。其中需要特別注意的是Path的值d.initPath，該路徑下存放的是dockerinit的二進制文件，Docker 1.2.0版本下，路徑一般為“/var/lib/docker/init/dockerinit-1.2.0”。另外SysProcAttr使用以下的代碼來賦值：

&syscall.SysProcAttr{Cloneflags: uintptr(namespaces.GetNamespaceFlags(container.Namespaces)),}

syscall.SysProAttr對象中的Cloneflags屬性中，即保留了libcontainer.Config類型的實例container中的Namespace屬性。換言之，通過exec.Cmd創(chuàng)建進程時，正是通過Cloneflags實現(xiàn)Clone系統(tǒng)調(diào)用中傳入namespace參數(shù)標志。

回到函數(shù)執(zhí)行中，在函數(shù)的最后返回了c.Cmd，命令創(chuàng)建完畢。

4.2啟動exec.Cmd創(chuàng)建進程

創(chuàng)建完exec.Cmd，當然需要將該執(zhí)行命令運行起來，namespaces.Exec函數(shù)中直接使用以下代碼實現(xiàn)進程的啟動：

if err := command.Start(); err != nil {return -1, err}

這一部分的內(nèi)容簡單直接， Start()函數(shù)用以完成指定命令exec.Cmd的啟動執(zhí)行，同時并不等待其啟動完畢便返回。Start()函數(shù)的定義位于os/exec包。

進入os/exec包，查看Start()函數(shù)的實現(xiàn)，可以看到執(zhí)行過程中，會對command.Process進行賦值，此時command.Process中會含有剛才啟動進程的PID進程號，該PID號屬于在宿主機pid namespace下，而并非是新創(chuàng)建namespace下的PID號。

4.3為容器進程初始化網(wǎng)絡(luò)環(huán)境

上一環(huán)節(jié)實現(xiàn)了容器進程的啟動，然而卻還沒有為之配置相應(yīng)的網(wǎng)絡(luò)環(huán)境。namespaces.Exec在之后的InitializeNetworing中實現(xiàn)了為容器進程初始化網(wǎng)絡(luò)環(huán)境。初始化網(wǎng)絡(luò)環(huán)境需要兩個非常重要的參數(shù)：container對象以及容器進程的Pid號。類型為libcontainer.Config的實例container中包含用戶對Docker Container的網(wǎng)絡(luò)配置需求，另外容器進程的Pid可以使得創(chuàng)建的網(wǎng)絡(luò)環(huán)境與進程新創(chuàng)建的namespace進行關(guān)聯(lián)。

namespaces.Exec中為容器進程初始化網(wǎng)絡(luò)環(huán)境的代碼實現(xiàn)位于./libcontainer/namespaces/exec.go#L75-L79，如下：

if err := InitializeNetworking(container, command.Process.Pid, syncPipe, &networkState); err != nil {command.Process.Kill()command.Wait()return -1, err}

InitializeNetworing的作用很明顯，即為創(chuàng)建的容器進程初始化網(wǎng)絡(luò)環(huán)境。更為底層的實現(xiàn)包含兩個步驟：

(1) 先在容器進程的namespace外部，創(chuàng)建容器所需的網(wǎng)絡(luò)棧；

(2) 將創(chuàng)建的網(wǎng)絡(luò)棧遷移進入容器的net namespace。

IntializeNetworking的源代碼實現(xiàn)位于./libcontainer/namespaces/exec.go#L176-L187，如下：

func InitializeNetworking(container *libcontainer.Config, nspid int, pipe *syncpipe.SyncPipe, networkState *network.NetworkState) error {for _, config := range container.Networks {strategy, err := network.GetStrategy(config.Type)if err != nil {return err}if err := strategy.Create((*network.Network)(config), nspid, networkState); err != nil {return err}}return pipe.SendToChild(networkState) }

以上源碼實現(xiàn)過程中，首先通過一個循環(huán)，遍歷libcontainer.Config類型實例container中的網(wǎng)絡(luò)屬性Networks；隨后使用GetStrategy函數(shù)處理Networks中每一個對象的Type屬性，得出Network的類型，這里的類型有3種，分別為“l(fā)oopback”、“veth”、“netns”。除host網(wǎng)絡(luò)模式之外，loopback對于其他每一種網(wǎng)絡(luò)模式的Docker Container都需要使用；veth針對bridge橋接模式，而netns針對other container模式。

得到Network類型的類型之后，libcontainer創(chuàng)建相應(yīng)的網(wǎng)絡(luò)棧，具體實現(xiàn)使用每種網(wǎng)絡(luò)棧類型下的Create函數(shù)。以下分析三種不同網(wǎng)絡(luò)棧各自的創(chuàng)建流程。

4.3.1 loopback網(wǎng)絡(luò)棧的創(chuàng)建

Loopback是一種本地環(huán)回設(shè)備，libcontainer創(chuàng)建loopback網(wǎng)絡(luò)設(shè)備的實現(xiàn)代碼位于./libcontainer/network/loopback.go#L13-L15，如下：

func (l *Loopback) Create(n *Network, nspid int, networkState *NetworkState) error {return nil }

令人費解的是，libcontainer在loopback設(shè)備的創(chuàng)建函數(shù)Create中，并沒有作實質(zhì)性的內(nèi)容，而是直接返回nil。

其實關(guān)于loopback設(shè)備的創(chuàng)建，要回到Linux內(nèi)核為進程新建namespace的階段。當libcontainer執(zhí)行command.Start()時，由于創(chuàng)建了一個新的網(wǎng)絡(luò)namespace，故Linux內(nèi)核會自動為新的net namespace創(chuàng)建loopback設(shè)備。當Linux內(nèi)核創(chuàng)建完loopback設(shè)備之后，libcontainer所做的工作即只要保留loopback設(shè)備的默認配置，并在Initialize函數(shù)中實現(xiàn)啟動該設(shè)備。

4.3.2 veth網(wǎng)絡(luò)棧的創(chuàng)建

Veth是Docker Container實際使用的網(wǎng)絡(luò)策略之一，其使用網(wǎng)橋docker0并創(chuàng)建veth pair虛擬網(wǎng)絡(luò)設(shè)備對，最終使一個veth配置在宿主機上，而另一個veth安置在容器網(wǎng)絡(luò)namespace內(nèi)部。

libcontainer中實現(xiàn)veth策略的代碼非常通俗易懂，代碼位于./libcontainer/network/veth.go#L19-L50，如下：

name1, name2, err := createVethPair(prefix)if err != nil {return err}if err := SetInterfaceMaster(name1, bridge); err != nil {return err}if err := SetMtu(name1, n.Mtu); err != nil {return err}if err := InterfaceUp(name1); err != nil {return err}if err := SetInterfaceInNamespacePid(name2, nspid); err != nil {return err}

主要的流程包含的四個步驟：

(1) 在宿主機上創(chuàng)建veth pair；

(2) 將一個veth附加至docker0網(wǎng)橋上；

(3) 啟動第一個veth；

(4) 將第二個veth附加至libcontainer創(chuàng)建進程的namespace下。

使用Create函數(shù)實現(xiàn)veth pair的創(chuàng)建之后，在Initialize函數(shù)中實現(xiàn)將網(wǎng)絡(luò)namespace中的veth改名為“eth0”，并設(shè)置網(wǎng)絡(luò)設(shè)備的MTU等。

4.3.3 netns網(wǎng)絡(luò)棧的創(chuàng)建

netns專門為Docker Container的other container網(wǎng)絡(luò)模式服務(wù)。netns完成的工作是將其他容器的namespace路徑傳遞給需要創(chuàng)建other container網(wǎng)絡(luò)模式的容器使用。

libcontainer中實現(xiàn)netns策略的代碼位于./libcontainer/network/netns.go#L17-L20，如下：

func (v *NetNS) Create(n *Network, nspid int, networkState *NetworkState) error {networkState.NsPath = n.NsPathreturn nil }

使用Create函數(shù)先將NsPath賦給新建容器之后，在Initialize函數(shù)中實現(xiàn)將網(wǎng)絡(luò)namespace的文件描述符交由新創(chuàng)建容器使用，最終實現(xiàn)兩個Docker Container共享同一個網(wǎng)絡(luò)棧。

通過Create以及Initialize的實現(xiàn)之后，Docker Container相應(yīng)的網(wǎng)絡(luò)棧環(huán)境即已經(jīng)完成創(chuàng)建，容器內(nèi)部的應(yīng)用進程可以使用不同的網(wǎng)絡(luò)棧環(huán)境與外界或者內(nèi)部進行通信。關(guān)于Initialize函數(shù)何時被調(diào)用，需要清楚Docker Daemon與dockerinit的關(guān)系，以及如何實現(xiàn)Docker Daemon進程與dockerinit進程跨namespace進行通信，這部分內(nèi)容會在《Docker源碼分析》系列后續(xù)專文分析。

5.總結(jié)

如何使用Docker Container的網(wǎng)絡(luò)，一直是工業(yè)界倍加關(guān)心的問題。本文將從Linux內(nèi)核原理的角度闡述了什么是Docker Container，并對Docker Container 4種不同的網(wǎng)絡(luò)模式進行了初步的介紹，最終貫穿Docker 架構(gòu)中的多個模塊，如Docker Client、Docker Daemon、execdriver以及l(fā)ibcontainer，深入分析Docker Container網(wǎng)絡(luò)的實現(xiàn)步驟。

目前，若只談?wù)揇ocker，那么它還是只停留在單host宿主機的場景上。如何面對跨host的場景、如何實現(xiàn)分布式Docker Container的管理，目前為止還沒有一個一勞永逸的解決方案。再者，一個解決方案的存在，總是會適應(yīng)于一個應(yīng)用場景。Docker這種容器技術(shù)的發(fā)展，大大改善了傳統(tǒng)模式下使用諸如虛擬機等傳統(tǒng)計算單位存在的多數(shù)弊端，卻在網(wǎng)絡(luò)方面使得自身的使用過程中存在瑕疵。希望本文是一個引子，介紹Docker Container網(wǎng)絡(luò)，以及從源碼的角度分析Docker Container網(wǎng)絡(luò)之后，能有更多的愛好者思考Docker Container網(wǎng)絡(luò)的前世今生，并為Docker乃至容器技術(shù)的發(fā)展做出貢獻。

6.作者介紹

孫宏亮，DaoCloud初創(chuàng)團隊成員，軟件工程師，浙江大學VLIS實驗室應(yīng)屆研究生。讀研期間活躍在PaaS和Docker開源社區(qū)，對Cloud Foundry有深入研究和豐富實踐，擅長底層平臺代碼分析，對分布式平臺的架構(gòu)有一定經(jīng)驗，撰寫了大量有深度的技術(shù)博客。2014年末以合伙人身份加入DaoCloud團隊，致力于傳播以Docker為主的容器的技術(shù)，推動互聯(lián)網(wǎng)應(yīng)用的容器化步伐。郵箱：allen.sun@daocloud.io

7.參考文獻

http://docs.studygolang.com/pkg/os/exec/#Cmd

https://github.com/docker/libcontainer/tree/v1.2.0

https://github.com/docker/libcontainer/issues/323

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/9602958.html

總結(jié)

以上是生活随笔為你收集整理的Docker源码分析（八）：Docker Container网络（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Docker源码分析（七）：Docker
下一篇： Docker源码分析（十）：Docker