Docker源码分析（八）：Docker Container网络（下）
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開(kāi)發(fā)者可以根據(jù)自己的需求來(lái)確定最適合自己應(yīng)用場(chǎng)景的網(wǎng)絡(luò)模式。
從Docker Container網(wǎng)絡(luò)創(chuàng)建流程圖中可以看到，創(chuàng)建流程第一個(gè)涉及的Docker模塊即為Docker Client。當(dāng)然，這也十分好理解，畢竟Docker Container網(wǎng)絡(luò)環(huán)境的創(chuàng)建需要由用戶發(fā)起，用戶根據(jù)自身對(duì)容器的需求，選擇網(wǎng)絡(luò)模式，并將其通過(guò)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)境指用戶通過(guò)向Docker Client傳遞網(wǎng)絡(luò)參數(shù)，實(shí)現(xiàn)Docker Container網(wǎng)絡(luò)環(huán)境參數(shù)的配置，這部分配置由Docker Client傳遞至Docker Daemon，并由Docker Daemon保存；創(chuàng)建網(wǎng)絡(luò)環(huán)境指，用戶通過(guò)Docker Client向Docker Daemon發(fā)送容器啟動(dòng)命令之后，Docker Daemon根據(jù)之前保存的網(wǎng)絡(luò)參數(shù)，實(shí)現(xiàn)Docker Container的啟動(dòng)，并在啟動(dòng)過(guò)程中完成Docker Container網(wǎng)絡(luò)環(huán)境的創(chuàng)建。
以上的基本知識(shí)，理解下文的Docker Container網(wǎng)絡(luò)環(huán)境創(chuàng)建流程。
1.1 Docker Client使用
Docker架構(gòu)中，用戶可以通過(guò)Docker Client來(lái)配置Docker Container的網(wǎng)絡(luò)模式。配置過(guò)程主要通過(guò)docker run命令來(lái)完成，實(shí)現(xiàn)配置的方式是在docker run命令中添加網(wǎng)絡(luò)參數(shù)。使用方式如下（其中NETWORKMODE為四種網(wǎng)絡(luò)模式之一，ubuntu為鏡像名稱(chēng)，/bin/bash為執(zhí)行指令）:
docker run -d --net NETWORKMODE ubuntu /bin/bash運(yùn)行以上命令時(shí)，首先創(chuàng)建一個(gè)Docker Client，然后Docker Client會(huì)解析整條命令的請(qǐng)求內(nèi)容，接著解析出為run請(qǐng)求，意為運(yùn)行一個(gè)Docker Container，最終通過(guò)Docker Client端的API接口，調(diào)用CmdRun函數(shù)完成run請(qǐng)求執(zhí)行。（詳情可以查閱《Docker源碼分析》系列的第二篇——Docker Client篇）。
Docker Client解析出run命令之后，立即調(diào)用相應(yīng)的處理函數(shù)CmdRun進(jìn)行處理關(guān)于run請(qǐng)求的具體內(nèi)容。CmdRun的作用主要可以歸納為三點(diǎn)：
- 解析Docker Client傳入的參數(shù)，解析出config、hostconfig和cmd對(duì)象等；
- 發(fā)送請(qǐng)求至Docker Daemon，創(chuàng)建一個(gè)container對(duì)象，完成Docker Container啟動(dòng)前的準(zhǔn)備工作；
- 發(fā)送請(qǐng)求至Docker Daemon，啟動(dòng)相應(yīng)的Docker Container（包含創(chuàng)建Docker Container網(wǎng)絡(luò)環(huán)境創(chuàng)建）。
1.2 runconfig包解析
CmdRun函數(shù)的實(shí)現(xiàn)位于./docker/api/client/commands.go。CmdRun執(zhí)行的第一個(gè)步驟為：通過(guò)runconfig包中ParseSubcommand函數(shù)解析Docker Client傳入的參數(shù)，并從中解析出相應(yīng)的config，hostConfig以及cmd對(duì)象，實(shí)現(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的類(lèi)型為Config結(jié)構(gòu)體，hostConfig的類(lèi)型為HostConfig結(jié)構(gòu)體，兩種類(lèi)型的定義均位于runconfig包。Config與HostConfig類(lèi)型同用以描述Docker Container的配置信息，然而兩者之間又有著本質(zhì)的區(qū)別，最大的區(qū)別在于兩者各自的作用范疇：
- Config結(jié)構(gòu)體：描述Docker Container獨(dú)立的配置信息。獨(dú)立的含義是：Config這部分信息描述的是容器本身，而不會(huì)與容器所在host宿主機(jī)相關(guān)；
- HostConfig結(jié)構(gòu)體：描述Docker Container與宿主機(jī)相關(guān)的配置信息。
1.2.1 Config結(jié)構(gòu)體
Config結(jié)構(gòu)體描述Docker Container本身的屬性信息，這些信息與容器所在的host宿主機(jī)無(wú)關(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)體中各屬性的詳細(xì)解釋如下表：
| Config結(jié)構(gòu)體屬性名 | 類(lèi)型 | 代表含義 |
| Hostname | string | 容器主機(jī)名 |
| Domainname | string | 域名名稱(chēng) |
| User | string | 用戶名 |
| Memory | int64 | 容器內(nèi)存使用上限（單位：字節(jié)） |
| MemorySwap | int64 | 容器所有的內(nèi)存使用上限（物理內(nèi)存+交互區(qū)），關(guān)閉交互區(qū)支持置為-1 |
| CpuShares | int64 | 容器CPU使用share值，其他容器的相對(duì)值 |
| Cpuset | string | CPU核的使用集合 |
| AttachStdin | bool | 是否附加標(biāo)準(zhǔn)輸入 |
| AttachStdout | bool | 是否附加標(biāo)準(zhǔn)輸出 |
| AttachStderr | bool | 是否附加標(biāo)準(zhǔn)錯(cuò)誤輸出 |
| PortsSpecs | []string | 目前已被遺棄 |
| ExposedPorts | map[nat.Port]struct{} | 容器內(nèi)部暴露的端口號(hào) |
| Tty | bool | 是否分配一個(gè)偽終端tty |
| OpenStdin | bool | 在沒(méi)有附加標(biāo)準(zhǔn)輸入時(shí)，是否依然打開(kāi)標(biāo)準(zhǔn)輸入 |
| StdinOnce | bool | 若為真，表示第一個(gè)客戶關(guān)閉標(biāo)準(zhǔn)輸入后關(guān)閉標(biāo)準(zhǔn)輸入功能 |
| Env | []string | 容器進(jìn)程運(yùn)行的環(huán)境變量 |
| Cmd | []string | 容器內(nèi)通過(guò)ENTRYPOINT運(yùn)行的指令 |
| Image | string | 容器rootfs所依賴(lài)的鏡像名稱(chēng) |
| Volumes | map[string]struct{} | 容器需要從host宿主機(jī)上掛載的目錄 |
| WorkingDir | string | 容器內(nèi)部的指定工作目錄 |
| Entrypoint | []string | 覆蓋鏡像屬性中默認(rèn)的ENTRYPOINT |
| NetworkDisabled | bool | 是否關(guān)閉容器網(wǎng)絡(luò)功能 |
| OnBuild | []string | ? |
1.2.2 HostConfig結(jié)構(gòu)體
HostConfig結(jié)構(gòu)體描述Docker Container與宿主機(jī)相關(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)體中各屬性的詳細(xì)解釋如下表：
| HostConfig結(jié)構(gòu)體屬性名 | 類(lèi)型 | 代表含義 |
| Binds | []string | 從宿主機(jī)上綁定到容器的volumes |
| ContainerIDFile | string | 文件名，文件用以寫(xiě)入容器的ID |
| LxcConf | []utils.KeyValuePair | 添加自定義的lxc選項(xiàng) |
| Privileged | bool | 是否賦予該容器擴(kuò)展權(quán)限 |
| PortBindings | nat.PortMap | 容器綁定到host宿主機(jī)的端口 |
| Links | []string | 添加其他容器的鏈接到該容器 |
| PublishAllPorts | bool | 是否向宿主機(jī)暴露所有端口信息 |
| Dns | []string | 自定義的DNS服務(wù)器地址 |
| DnsSearch | []string | 自定義的DNS查找服務(wù)器地址 |
| VolumesFrom | []string | 從指定的容器中掛載到該容器的volumes |
| Devices | []DeviceMapping | 為容器添加一個(gè)或多個(gè)宿主機(jī)設(shè)備 |
| NetworkMode | NetworkMode | 為容器設(shè)置的網(wǎng)絡(luò)模式 |
| CapAdd | []string | 為容器用戶添加一個(gè)或多個(gè)Linux Capabilities |
| CapDrop | []string | 為容器用戶禁用一個(gè)或多個(gè)Linux Capabilities |
| RestartPolicy | RestartPolicy | 當(dāng)一個(gè)容器異常退出時(shí)采取的重啟策略 |
1.2.3 runconfig解析網(wǎng)絡(luò)模式
講述完Config與HostConfig結(jié)構(gòu)體之后，回到runconfig包中分析如何解析與Docker Container網(wǎng)絡(luò)模式相關(guān)的配置信息，并將這部分信息傳遞給config實(shí)例與hostConfig實(shí)例。
runconfig包中的ParseSubcommand函數(shù)調(diào)用parseRun函數(shù)完成命令請(qǐng)求的分析，實(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) }進(jìn)入parseRun函數(shù)即可發(fā)現(xiàn)：該函數(shù)完成了四方面的工作：
- 定義與容器配置信息相關(guān)的flag參數(shù)；
- 解析docker run命令后緊跟的請(qǐng)求內(nèi)容，將請(qǐng)求內(nèi)容全部保存至flag參數(shù)中，余下的內(nèi)容一個(gè)為鏡像image名，另一個(gè)為需要在容器內(nèi)執(zhí)行的cmd命令；
- 通過(guò)flag參數(shù)驗(yàn)證參數(shù)的有效性，并處理得到Config結(jié)構(gòu)體與HostConfig結(jié)構(gòu)體需要的屬性值；
- 創(chuàng)建并初始化Config類(lèi)型實(shí)例config、HostConfig類(lèi)型實(shí)例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.")
可見(jiàn)flag參數(shù)flNetwork表示是否開(kāi)啟容器的網(wǎng)絡(luò)模式，若為true則開(kāi)啟，說(shuō)明需要給容器創(chuàng)建網(wǎng)絡(luò)環(huán)境；否則不開(kāi)啟，說(shuō)明不給容器賦予網(wǎng)絡(luò)功能。該flag參數(shù)的默認(rèn)值為true，另外使用該flag的方式為：在docker run之后設(shè)定--networking或者-n，如：
docker run --networking true ubuntu /bin/bash另一個(gè)flag參數(shù)flNetMode則表示為容器設(shè)定的網(wǎng)絡(luò)模式，共有四種選項(xiàng)，分別是：bridge、none、container:<name|id>和host。四種模式的作用上文已經(jīng)詳細(xì)解釋，此處不再贅述。使用該flag的方式為：在docker run之后設(shè)定--net，如：
Docker run --net host ubuntu /bin/bash用戶使用docker run啟動(dòng)容器時(shí)設(shè)定了以上兩個(gè)flag參數(shù)（--networking和--net），則runconfig包會(huì)解析出這兩個(gè)flag的值。最終，通過(guò)flag參數(shù)flNetwork，得到Config類(lèi)型實(shí)例config的屬性NetworkDisabled；通過(guò)flag參數(shù)flNetMode，得到HostConfig類(lèi)型實(shí)例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對(duì)象與hostConfig對(duì)象，故在CmdRun函數(shù)的執(zhí)行中，更多的是基于config對(duì)象與hostConfig參數(shù)處理配置信息，而沒(méi)有其他的容器網(wǎng)絡(luò)處理部分。
CmdRun后續(xù)主要工作是：利用Docker Daemon暴露的RESTful API接口，將docker run的請(qǐng)求發(fā)送至Docker Daemon。以下是CmdRun執(zhí)行過(guò)程中Docker Client與Docker Daemon的簡(jiǎn)易交互圖。
圖1.1 CmdRun中Docker Client與Docker Daemon交互圖
具體分析CmdRun的執(zhí)行流程可以發(fā)現(xiàn)：在解析config、hostConfig與cmd之后，Docker Client首先發(fā)起請(qǐng)求create container。若Docker Daemon節(jié)點(diǎn)上已經(jīng)存在該容器所需的鏡像，則立即執(zhí)行create container操作并返回請(qǐng)求響應(yīng)；Docker Client收到響應(yīng)后，再發(fā)起請(qǐng)求start container。若容器鏡像還不存在，Docker Daemon返回一個(gè)404的錯(cuò)誤，表示鏡像不存在；Docker Client收到錯(cuò)誤響應(yīng)之后，再發(fā)起一個(gè)請(qǐng)求pull image，使Docker Daemon首先下載鏡像，下載完畢之后Docker Client再次發(fā)起請(qǐng)求create container，Docker Daemon創(chuàng)建完畢之后，Docker Client最終發(fā)起請(qǐng)求start container。
總結(jié)而言，Docker Client負(fù)責(zé)創(chuàng)建容器請(qǐng)求的發(fā)起。關(guān)于Docker Container網(wǎng)絡(luò)環(huán)境的配置參數(shù)存儲(chǔ)于config與hostConfig對(duì)象之中，在請(qǐng)求create container和start container發(fā)起時(shí)，隨請(qǐng)求一起發(fā)送至Docker Daemon。
2.Docker Daemon創(chuàng)建容器網(wǎng)絡(luò)流程
Docker Daemon接收到Docker Client的請(qǐng)求大致可以分為兩次，第一次為create container，第二次為start container。這兩次請(qǐng)求的執(zhí)行過(guò)程中，都與Docker Container的網(wǎng)絡(luò)相關(guān)。以下按照這兩個(gè)請(qǐng)求的執(zhí)行，具體分析Docker Container網(wǎng)絡(luò)模式的創(chuàng)建。Docker Daemon如何通過(guò)Docker Server解析RESTful請(qǐng)求，并完成分發(fā)調(diào)度處理，在《Docker源碼分析》系列的第五篇——Docker Server篇中已經(jīng)詳細(xì)分析過(guò)，本文不再贅述。
2.1創(chuàng)建容器并配置網(wǎng)絡(luò)參數(shù)
Docker Daemon首先接收并處理create container請(qǐng)求。需要注意的是：create container并非創(chuàng)建了一個(gè)運(yùn)行的容器，而是完成了以下三個(gè)主要的工作：
- 通過(guò)runconfig包解析出create container請(qǐng)求中與Docker Container息息相關(guān)的config對(duì)象；
- 在Docker Daemon內(nèi)部創(chuàng)建了與Docker Container對(duì)應(yīng)的container對(duì)象；
- 完成Docker Container啟動(dòng)前的準(zhǔn)備化工作，如準(zhǔn)備所需鏡像、創(chuàng)建rootfs等。
創(chuàng)建容器過(guò)程中，Docker Daemon首先通過(guò)runconfig包中ContainerConfigFromJob函數(shù)，解析出請(qǐng)求中的config對(duì)象，解析過(guò)程代碼如下：
config := runconfig.ContainerConfigFromJob(job)
至此，Docker Client處理得到的config對(duì)象，已經(jīng)傳遞至Docker Daemon的config對(duì)象，config對(duì)象中已經(jīng)含有屬性NetworkDisabled具體值。
處理得到config對(duì)象之后，Docker Daemon緊接著創(chuàng)建container對(duì)象，并為Docker Container作相應(yīng)的準(zhǔn)備工作。具體的實(shí)現(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對(duì)象中。newContainer函數(shù)的定義位于./docker/daemon/daemon.go#L516-L550，具體的container對(duì)象如下：
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對(duì)象中，config對(duì)象直接賦值給container對(duì)象的Config屬性，另外hostConfig屬性與NetworkSeeetings屬性均為空。其中hostConfig對(duì)象將在start container請(qǐng)求執(zhí)行過(guò)程中被賦值，NetworkSettings類(lèi)型的作用是描述容器的網(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類(lèi)型的各屬性的詳細(xì)解釋如下表：
?
| NetworkSettings屬性名稱(chēng) | 類(lèi)型 | 含義 |
| IPAddress | string | IP網(wǎng)絡(luò)地址 |
| IPPrefixLen | int | 網(wǎng)絡(luò)標(biāo)識(shí)位長(zhǎng)度 |
| Gateway | string | 網(wǎng)關(guān)地址 |
| Bridge | string | 網(wǎng)橋地址 |
| PortMapping | map[string]PortMapping | 端口映射 |
| Ports | nat.PortMap | 端口號(hào) |
總結(jié)而言，Docker Daemon關(guān)于create container請(qǐng)求的執(zhí)行，先實(shí)現(xiàn)了容器配置信息從Docker Client至Docker Daemon的轉(zhuǎn)移，再完成了啟動(dòng)容器前所需的準(zhǔn)備工作。
2.2啟動(dòng)容器之網(wǎng)絡(luò)配置
創(chuàng)建容器階段，Docker Daemon創(chuàng)建了容器對(duì)象container，container對(duì)象內(nèi)部的Config屬性含有NetworkDisabled。創(chuàng)建容器完成之后，Docker Daemon還需要接收Docker Client的請(qǐng)求，并執(zhí)行start container的操作，即啟動(dòng)容器。
啟動(dòng)容器過(guò)程中，Docker Daemon首先通過(guò)runconfig包中ContainerHostConfigFromJob函數(shù)，解析出請(qǐng)求中的hostConfig對(duì)象，解析過(guò)程代碼如下：
hostConfig := runconfig.ContainerHostConfigFromJob(job)至此，Docker Client處理得到的hostConfig對(duì)象，已經(jīng)傳遞至Docker Daemon的hostConfig對(duì)象，hostConfig對(duì)象中已經(jīng)含有屬性NetworkMode具體值。
容器啟動(dòng)的所有工作，均由以下的Start函數(shù)來(lái)完成，代碼位于./docker/daemon/start.go#L36-L38，如下：
if err := container.Start(); err != nil {return job.Errorf("Cannot start container %s: %s", name, err)}Start函數(shù)實(shí)現(xiàn)了容器的啟動(dòng)。更為具體的描述是：Start函數(shù)實(shí)現(xiàn)了進(jìn)程的啟動(dòng)，另外在啟動(dòng)進(jìn)程的同時(shí)為進(jìn)程設(shè)定了命名空間（namespace），啟動(dòng)完畢之后為進(jìn)程完成了資源使用的控制，從而保證進(jìn)程以及之后進(jìn)程的子進(jìn)程都會(huì)在同一個(gè)命名空間內(nèi)，且受到相同的資源控制。如此一來(lái)，Start函數(shù)創(chuàng)建的進(jìn)程，以及該進(jìn)程的子進(jìn)程，形成一個(gè)進(jìn)程組，該進(jìn)程組處于資源隔離和資源控制的環(huán)境，我們習(xí)慣將這樣的進(jìn)程組環(huán)境稱(chēng)為容器，也就是這里的Docker Container。
回到Start函數(shù)的執(zhí)行，位于./docker/daemon/container.go#L275-L320。Start函數(shù)執(zhí)行過(guò)程中，與Docker Container網(wǎng)絡(luò)模式相關(guān)的部分主要有三部分：
- initializeNetwork()，初始化container對(duì)象中與網(wǎng)絡(luò)相關(guān)的屬性；
- populateCommand，填充Docker Container內(nèi)部需要執(zhí)行的命令，Command中含有進(jìn)程啟動(dòng)命令，還含有容器環(huán)境的配置信息，也包括網(wǎng)絡(luò)配置；
- container.waitForStart()，實(shí)現(xiàn)Docker Container內(nèi)部進(jìn)程的啟動(dòng)，進(jìn)程啟動(dòng)之后，為進(jìn)程創(chuàng)建網(wǎng)絡(luò)環(huán)境等。
2.2.1初始化容器網(wǎng)絡(luò)配置
容器對(duì)象container中有屬性hostConfig，屬性hostConfig中有屬性NetworkMode，初始化容器網(wǎng)絡(luò)配置initializeNetworking()的主要工作就是，通過(guò)NetworkMode屬性為Docker Container的網(wǎng)絡(luò)作相應(yīng)的初始化配置工作。
Docker Container的網(wǎng)絡(luò)模式有四種，分別為：host、other container、none以及bridge。initializeNetworking函數(shù)的執(zhí)行完全覆蓋了這四種模式。
initializeNetworking()函數(shù)的實(shí)現(xiàn)位于./docker/daemon/container.go#L881-L933。
2.2.1.1 初始化host網(wǎng)絡(luò)模式配置
Docker Container網(wǎng)絡(luò)的host模式意味著容器使用宿主機(jī)的網(wǎng)絡(luò)環(huán)境。雖然Docker Container使用宿主機(jī)的網(wǎng)絡(luò)環(huán)境，但這并不代表Docker Container可以擁有宿主機(jī)文件系統(tǒng)的視角，而host宿主機(jī)上有很多信息標(biāo)識(shí)的是網(wǎng)絡(luò)信息，故Docker Daemon需要將這部分標(biāo)識(shí)網(wǎng)絡(luò)的信息，從host宿主機(jī)添加到Docker Container內(nèi)部的指定位置。這樣的網(wǎng)絡(luò)信息，主要有以下兩種：
- host宿主機(jī)的主機(jī)名（hostname）；
- host宿主機(jī)上/etc/hosts文件，用于配置IP地址以及主機(jī)名。
其中，宿主機(jī)的主機(jī)名hostname用于創(chuàng)建container.Config中的Hostname與Domainname屬性。
另外，Docker Daemon在Docker Container的rootfs內(nèi)部創(chuàng)建hostname文件，并在文件中寫(xiě)入Hostname與Domainname；同時(shí)創(chuàng)建hosts文件，并寫(xiě)入host宿主機(jī)上/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對(duì)象的hostConfig屬性中找出NetworkMode，并找到相應(yīng)的容器，即17adef的容器對(duì)象container，實(shí)現(xiàn)代碼如下：
nc, err := container.getNetworkedContainer()第二步，將17adef容器對(duì)象的HostsPath、ResolveConfPath、Hostname和Domainname賦值給當(dāng)前容器對(duì)象container，實(shí)現(xiàn)代碼如下：
container.HostsPath = nc.HostsPath container.ResolvConfPath = nc.ResolvConfPath container.Config.Hostname = nc.Config.Hostname container.Config.Domainname = nc.Config.Domainname2.2.1.3 初始化none網(wǎng)絡(luò)模式配置
Docker Container的none網(wǎng)絡(luò)模式意味著不給該容器創(chuàng)建任何網(wǎng)絡(luò)環(huán)境，容器只能使用127.0.0.1的本機(jī)網(wǎng)絡(luò)。
Docker Daemon通過(guò)config屬性的DisableNetwork來(lái)判斷是否為none網(wǎng)絡(luò)模式。實(shí)現(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)建獨(dú)立的網(wǎng)絡(luò)環(huán)境，并通過(guò)“橋接”的方式實(shí)現(xiàn)Docker Container與外界的網(wǎng)絡(luò)通信。
初始化bridge網(wǎng)絡(luò)模式的配置，實(shí)現(xiàn)代碼如下：
if err := container.allocateNetwork(); err != nil {return err } return container.buildHostnameAndHostsFiles(container.NetworkSettings.IPAddress)以上代碼完成的內(nèi)容主要也是兩部分：第一，通過(guò)allocateNetwork函數(shù)為容器分配網(wǎng)絡(luò)接口設(shè)備需要的資源信息（包括IP、bridge、Gateway等），并賦值給container對(duì)象的NetworkSettings；第二，為容器創(chuàng)建hostname以及創(chuàng)建Hosts等文件。
2.2.2創(chuàng)建容器Command信息
Docker在實(shí)現(xiàn)容器時(shí)，使用了Command類(lèi)型。Command在Docker Container概念中是一個(gè)非常重要的概念。幾乎可以認(rèn)為Command是Docker Container生命周期的源頭。Command的概念會(huì)貫穿以后的《Docker源碼分析》系列，比如Docker Daemon與dockerinit的關(guān)系，dockerinit和entrypoint.sh的關(guān)系，entrypoint.sh與CMD的關(guān)系，以及namespace在這些內(nèi)容中扮演的角色。
簡(jiǎn)單來(lái)說(shuō)，Command類(lèi)型包含了兩部分的內(nèi)容：第一，運(yùn)行容器內(nèi)進(jìn)程的外部命令exec.Cmd；第二，運(yùn)行容器時(shí)啟動(dòng)進(jìn)程需要的所有環(huán)境基礎(chǔ)信息：包括容器進(jìn)程組的使用資源、網(wǎng)絡(luò)環(huán)境、使用設(shè)備、工作路徑等。通過(guò)這兩部分的內(nèi)容，我們可以清楚，如何啟動(dòng)容器內(nèi)的進(jìn)程，同時(shí)也清楚為容器創(chuàng)建什么樣的環(huán)境。
首先，我們先來(lái)看Command類(lèi)型的定義，位于./docker/daemon/execdriver/driver.go#L84，通過(guò)分析Command類(lèi)型以及其他相關(guān)的數(shù)據(jù)結(jié)構(gòu)類(lèi)型，可以得到以下簡(jiǎn)要類(lèi)型關(guān)系圖：
圖 2.1 Command類(lèi)型關(guān)系圖
從Command類(lèi)型關(guān)系圖中可以看到，Command類(lèi)型中重新包裝了exec.Cmd類(lèi)型，即代表需要?jiǎng)?chuàng)建的進(jìn)程具體的外部命令；同時(shí)，關(guān)于網(wǎng)絡(luò)方面的屬性有Network，Network的類(lèi)型為指向Network類(lèi)型的指針；關(guān)于Docker Container資源使用方面的屬性為Resources，從Resource的類(lèi)型來(lái)看，Docker目前能做的資源限制有4個(gè)維度，分別為內(nèi)存，內(nèi)存+Swap，CPU使用，CPU核使用；關(guān)于掛載的內(nèi)容，有屬性Mounts；等等。
簡(jiǎn)單介紹Command類(lèi)型之后，回到Docker Daemon啟動(dòng)容器網(wǎng)絡(luò)的源碼分析。在Start函數(shù)的執(zhí)行流程中，緊接initializeNetworking()之后，與Docker Container網(wǎng)絡(luò)相關(guān)的是populateCommand環(huán)節(jié)。populateCommand的函數(shù)實(shí)現(xiàn)位于./docker/daemon/container.go#L191-L274。上文已經(jīng)提及，populateCommand的作用是創(chuàng)建包execdriver的對(duì)象Command，該Command中既有啟動(dòng)容器進(jìn)程的外部命令，同時(shí)也有眾多為容器環(huán)境的配置信息，包括網(wǎng)絡(luò)。
本小節(jié)，更多的分析populateCommand如何填充Command對(duì)象中的網(wǎng)絡(luò)信息，其他信息的分析會(huì)在《源碼分析系列》的后續(xù)進(jìn)行展開(kāi)。
Docker總共有四種網(wǎng)絡(luò)模式，故populateCommand自然需要判斷容器屬于哪種網(wǎng)絡(luò)模式，隨后將具體的網(wǎng)絡(luò)模式信息，寫(xiě)入Command對(duì)象的Network屬性中。查驗(yàn)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首先通過(guò)hostConfig對(duì)象中的NetworkMode判斷容器屬于哪種網(wǎng)絡(luò)模式。該部分內(nèi)容涉及到execdriver包中的Network類(lèi)型，可參見(jiàn)Command類(lèi)型關(guān)系圖中的Network類(lèi)型。若為none模式，則對(duì)于Network對(duì)象（即en，*execdriver.Network）不做任何操作。若為host模式，則將Network對(duì)象的HostNetworking置為true；若為bridge橋接模式，則首先創(chuàng)建一個(gè)NetworkInterface對(duì)象，完善該對(duì)象的Gateway、Bridge、IPAddress和IPPrefixLen信息，最后將NetworkInterface對(duì)象作為Network對(duì)象的Interface屬性的值；若為other container模式，則首先通過(guò)getNetworkedContainer()函數(shù)獲知被分享網(wǎng)絡(luò)命名空間的容器，最后將容器ID，賦值給Network對(duì)象的ContainerID。由于bridge模式、host模式、none模式以及other container模式彼此互斥，故Network對(duì)象中Interface屬性、ContainerID屬性以及HostNetworking三者之中只有一個(gè)被賦值。當(dāng)Docker Container的網(wǎng)絡(luò)查驗(yàn)之后，populateCommand將en實(shí)例Network屬性的值，傳遞給Command對(duì)象。
至此，populateCommand關(guān)于網(wǎng)絡(luò)方面的信息已經(jīng)完成配置，網(wǎng)絡(luò)配置信息已經(jīng)成功賦值于Command的Network屬性。。
2.2.3啟動(dòng)容器內(nèi)部進(jìn)程
當(dāng)為容器做好所有的準(zhǔn)備與配置之后，Docker Daemon需要真正意義上的啟動(dòng)容器。根據(jù)Docker Daemon啟動(dòng)容器流程涉及的Docker模塊中可以看到，這樣的請(qǐng)求，會(huì)被發(fā)送至execdriver，再經(jīng)過(guò)libcontainer，最后實(shí)現(xiàn)真正啟動(dòng)進(jìn)程，創(chuàng)建完容器。
回到Docker Daemon的啟動(dòng)容器，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 }以上代碼運(yùn)行過(guò)程中首先通過(guò)newContainerMonitor返回一個(gè)初始化的containerMonitor對(duì)象，該對(duì)象中帶有容器進(jìn)程的重啟策略（RestartPolicy）。這里簡(jiǎn)單介紹containerMonitor對(duì)象?？傮w而言，containerMonitor對(duì)象用以監(jiān)視容器中第一個(gè)進(jìn)程的執(zhí)行。如果containerMonitor中指定了一種進(jìn)程重啟策略，那么一旦容器內(nèi)部進(jìn)程沒(méi)有啟動(dòng)成功，Docker Daemon會(huì)使用重啟策略來(lái)重啟容器。如果在重啟策略下，容器依然沒(méi)有成功啟動(dòng)，那么containerMonitor對(duì)象會(huì)負(fù)責(zé)重置以及清除所有已經(jīng)為容器準(zhǔn)備好的資源，例如已經(jīng)為容器分配好的網(wǎng)絡(luò)資源（即IP地址），還有為容器準(zhǔn)備的rootfs等。
waitForStart()函數(shù)通過(guò)container.monitor.Start來(lái)實(shí)現(xiàn)容器的啟動(dòng)，進(jìn)入./docker/daemon/monitor.go#L100，可以發(fā)現(xiàn)啟動(dòng)容器進(jìn)程位于./docker/daemon/monitor.go#L136，代碼如下：
exitStatus, err = m.container.daemon.Run(m.container, pipes, m.callback)以上代碼實(shí)際調(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ù)來(lái)執(zhí)行Docker Container的啟動(dòng)命令。
至此，網(wǎng)絡(luò)部分在Docker Daemon內(nèi)部的執(zhí)行已經(jīng)結(jié)束，緊接著程序運(yùn)行邏輯陷入execdriver，進(jìn)一步完成容器啟動(dòng)的相關(guān)步驟。
3.execdriver網(wǎng)絡(luò)執(zhí)行流程
Docker架構(gòu)中execdriver的作用是啟動(dòng)容器內(nèi)部進(jìn)程，最終啟動(dòng)容器。目前，在Docker中execdriver作為執(zhí)行驅(qū)動(dòng)，可以有兩種選項(xiàng)：lxc與native。其中，lxc驅(qū)動(dòng)會(huì)調(diào)用lxc工具實(shí)現(xiàn)容器的啟動(dòng)，而native驅(qū)動(dòng)會(huì)使用Docker官方發(fā)布的libcontainer來(lái)啟動(dòng)容器。
Docker Daemon啟動(dòng)過(guò)程中，execdriver的類(lèi)型默認(rèn)為native，故本文主要分析native驅(qū)動(dòng)在執(zhí)行啟動(dòng)容器時(shí)，如何處理網(wǎng)絡(luò)部分。
在Docker Daemon啟動(dòng)容器的最后一步，即調(diào)用了execdriver的Run函數(shù)來(lái)執(zhí)行。通過(guò)分析Run函數(shù)的具體實(shí)現(xiàn)，關(guān)于Docker Container的網(wǎng)絡(luò)執(zhí)行流程主要包括兩個(gè)環(huán)節(jié)：
(1) 創(chuàng)建libcontainer的Config對(duì)象
(2) 通過(guò)libcontainer中的namespaces包執(zhí)行啟動(dòng)容器
將execdriver.Run函數(shù)的運(yùn)行流程具體展開(kāi)，與Docker Container網(wǎng)絡(luò)相關(guān)的流程，可以得到以下示意圖：
圖3.1 execdriver.Run執(zhí)行流程圖
3.1創(chuàng)建libcontainer的Config對(duì)象
Run函數(shù)位于./docker/daemon/execdriver/native/driver.go#L62-L168，進(jìn)入Run函數(shù)的實(shí)現(xiàn)，立即可以發(fā)現(xiàn)該函數(shù)通過(guò)createContainer創(chuàng)建了一個(gè)container對(duì)象，代碼如下：
container, err := d.createContainer(c)其中c為Docker Daemon創(chuàng)建的execdriver.Command類(lèi)型實(shí)例。以上代碼的createContainer函數(shù)的作用是：使用execdriver.Command來(lái)填充libcontainer.Config。
libcontainer.Config的作用是，定義在一個(gè)容器化的環(huán)境中執(zhí)行一個(gè)進(jìn)程所需要的所有配置項(xiàng)。createContainer函數(shù)的存在，使用Docker Daemon層創(chuàng)建的execdriver.Command，創(chuàng)建更下層libcontainer所需要的Config對(duì)象。這個(gè)角度來(lái)看，execdriver更像是封裝了libcontainer對(duì)外的接口，實(shí)現(xiàn)了將Docker Daemon認(rèn)識(shí)的容器啟動(dòng)信息轉(zhuǎn)換為底層libcontainer能真正使用的容器啟動(dòng)配置選項(xiàng)。libcontainer.Config類(lèi)型與其內(nèi)部對(duì)象的關(guān)聯(lián)圖如下：
圖3.2 libcontainer.Config類(lèi)型關(guān)系圖
進(jìn)入createContainer的源碼實(shí)現(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模板實(shí)例
從createContainer函數(shù)的實(shí)現(xiàn)以及execdriver.Run執(zhí)行流程圖中都可以看到，createContainer所做的第一個(gè)操作就是即為執(zhí)行template.New()，意為創(chuàng)建一個(gè)libcontainer.Config的實(shí)例container。其中，template.New()的定義位于./docker/daemon/execdriver/native/template/default_template.go，主要的作用為返回libcontainer關(guān)于Docker Container的默認(rèn)配置選項(xiàng)。
Template.New()的代碼實(shí)現(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默認(rèn)的模板對(duì)象，從源碼實(shí)現(xiàn)中可以看到，首先設(shè)定了Capabilities的默認(rèn)項(xiàng)，如CHOWN、DAC_OVERRIDE、FSETID等；其次又將Docker Container所需要的設(shè)定的namespaces添加默認(rèn)值，即需要?jiǎng)?chuàng)建5個(gè)NAMESPACE，如NEWNS、NEWUTS、NEWIPC、NEWPID和NEWNET，其中不包括user namespace，另外與網(wǎng)絡(luò)相關(guān)的namespace為NEWNET；最后設(shè)定了一些關(guān)于cgroup以及apparmor的默認(rèn)配置。
Template.New()函數(shù)最后返回類(lèi)型為libcontainer.Config的實(shí)例container，該實(shí)例中只含有默認(rèn)配置項(xiàng)，其他的配置項(xiàng)的添加需要createContainer的后續(xù)操作來(lái)完成。
3.1.2 createNetwork實(shí)現(xiàn)
在createContainer的實(shí)現(xiàn)流程中，為了完成container對(duì)象（類(lèi)型為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對(duì)象完善網(wǎng)絡(luò)配置項(xiàng)。
createNetwork函數(shù)的定義位于./docker/daemon/execdriver/native/create.go#L79-L124，該函數(shù)主要利用execdriver.Command中Network屬性中的內(nèi)容，來(lái)判斷如何創(chuàng)建libcontainer.Config中Network屬性（關(guān)于兩中Network屬性，可以參見(jiàn)圖3.1和圖3.2）。由于Docker Container的4種網(wǎng)絡(luò)模式彼此互斥，故以上Network類(lèi)型中Interface、ContainerID與HostNetworking最多只有一項(xiàng)會(huì)被賦值。
由于execdriver.Command中Network的類(lèi)型定義如下：
type Network struct {Interface *NetworkInterfaceMtu int ContainerID string HostNetworking bool }分析createNetwork函數(shù)，其具體實(shí)現(xiàn)可以歸納為4部分內(nèi)容：
(1) 判斷網(wǎng)絡(luò)是否為host模式；
(2) 判斷是否為bridge橋接模式；
(3) 判斷是否為other container模式；
(4) 為Docker Container添加loopback網(wǎng)絡(luò)設(shè)備。
首先來(lái)看execdriver判斷是否為host模式的代碼：
if c.Network.HostNetworking {container.Namespaces["NEWNET"] = falsereturn nil }當(dāng)execdriver.Command類(lèi)型實(shí)例中Network屬性的HostNetworking為true，則說(shuō)明需要為Docker Container創(chuàng)建host網(wǎng)絡(luò)模式，使得容器與宿主機(jī)共享同樣的網(wǎng)絡(luò)命名空間。關(guān)于host模式的具體介紹中，已經(jīng)闡明，只須在創(chuàng)建進(jìn)程進(jìn)行CLONE系統(tǒng)調(diào)用時(shí)，不傳入CLONE_NEWNET參數(shù)標(biāo)志即可實(shí)現(xiàn)。這里的代碼正好準(zhǔn)確的驗(yàn)證了這一點(diǎn)，將container對(duì)象中NEWNET的Namespace設(shè)為false，最終在libcontainer中可以達(dá)到效果。
再看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)}當(dāng)execdriver.Command類(lèi)型實(shí)例中Network屬性的Interface不為nil值，則說(shuō)明需要為Docker Container創(chuàng)建bridge橋接模式，使得容器使用隔離的網(wǎng)絡(luò)環(huán)境。于是這里為類(lèi)型為libcontainer.Config的container對(duì)象添加Networks屬性vethNetwork，網(wǎng)絡(luò)類(lèi)型為“veth”，以便libcontainer在執(zhí)行時(shí)，可以為Docker Container創(chuàng)建veth pair。
接著來(lái)看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,})}當(dāng)execdriver.Command類(lèi)型實(shí)例中Network屬性的ContainerID不為空字符串時(shí)，則說(shuō)明需要為Docker Container創(chuàng)建other container模式，使得創(chuàng)建容器使用其他容器的網(wǎng)絡(luò)環(huán)境。實(shí)現(xiàn)過(guò)程中，execdriver需要首先在activeContainers中查找需要被共享網(wǎng)絡(luò)環(huán)境的容器active；并通過(guò)active容器的啟動(dòng)執(zhí)行命令cmd找到容器第一進(jìn)程在宿主機(jī)上的PID；隨后在proc文件系統(tǒng)中找到該進(jìn)程PID的關(guān)于網(wǎng)絡(luò)namespace的路徑nspath；最后為類(lèi)型為libcontainer.Config的container對(duì)象添加Networks屬性，Network的類(lèi)型為“netns”。
此外，createNetwork函數(shù)還實(shí)現(xiàn)為Docker Container創(chuàng)建一個(gè)loopback回環(huán)設(shè)備，以便容器可以實(shí)現(xiàn)內(nèi)部通信。實(shí)現(xiàn)過(guò)程中，同樣為類(lèi)型libcontainer.Config的container對(duì)象添加Networks屬性，Network的類(lèi)型為“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)建在類(lèi)型為libcontainer.Config的container對(duì)象中了，就等著啟動(dòng)容器進(jìn)程時(shí)使用。
3.2 調(diào)用libcontainer的namespaces啟動(dòng)容器
回到execdriver.Run函數(shù)，創(chuàng)建完libcontainer.Config實(shí)例container，經(jīng)過(guò)一系列其他方面的處理之后，最終execdriver執(zhí)行namespaces.Exec函數(shù)實(shí)現(xiàn)啟動(dòng)容器，container對(duì)象依然是namespace.Exec函數(shù)中一個(gè)非常重要的參數(shù)。這一環(huán)節(jié)代表著execdriver把啟動(dòng)Docker Container的工作交給libcontainer，以后的執(zhí)行陷入libcontainer。
調(diào)用namespaces.Exec的代碼位于./docker/daemon/execdriver/native/driver.go#L102-L127，為了便于理解，簡(jiǎn)化的代碼如下：
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這兩個(gè)函數(shù)均會(huì)在libcontainer的namespaces中發(fā)揮很大的重要。
至此，execdriver模塊的執(zhí)行部分已經(jīng)完結(jié)，Docker Daemon的程序運(yùn)行邏輯陷入libcontainer。
4.libcontainer實(shí)現(xiàn)內(nèi)核態(tài)網(wǎng)絡(luò)配置
libcontainer是一個(gè)Linux操作系統(tǒng)上容器的實(shí)現(xiàn)包。libcontainer指定了創(chuàng)建一個(gè)容器時(shí)所需要的配置選項(xiàng)，同時(shí)它利用Linux namespace和cgroup等技術(shù)為使用者提供了一套Golang原生態(tài)的容器實(shí)現(xiàn)方案，并且沒(méi)有使用任何外部依賴(lài)。用戶借助libcontainer，可以感受到眾多操縱namespaces，網(wǎng)絡(luò)等資源的便利。
當(dāng)execdriver調(diào)用libcontainer中namespaces包的Exec函數(shù)時(shí)，libcontainer開(kāi)始發(fā)揮其實(shí)現(xiàn)容器功能的作用。Exec函數(shù)位于./libcontainer/namespaces/exec.go#L24-L113。本文更多的關(guān)心Docker Container的網(wǎng)絡(luò)創(chuàng)建，因此從這個(gè)角度來(lái)看Exec的實(shí)現(xiàn)可以分為三個(gè)步驟：
(1) 通過(guò)createCommand創(chuàng)建一個(gè)Golang語(yǔ)言內(nèi)的exec.Cmd對(duì)象；
(2) 啟動(dòng)命令exec.Cmd，執(zhí)行容器內(nèi)第一個(gè)進(jìn)程；
(3) 通過(guò)InitializeNetworking函數(shù)為容器進(jìn)程初始化網(wǎng)絡(luò)環(huán)境。
以下詳細(xì)分析這三個(gè)部分，源碼的具體實(shí)現(xiàn)。
4.1創(chuàng)建exec.Cmd
提到exec.Cmd，就不得不提Go語(yǔ)言標(biāo)準(zhǔn)庫(kù)中的包os以及包os/exec。前者提供了與平臺(tái)無(wú)關(guān)的操作系統(tǒng)功能集，后者則提供了功能集里與命令執(zhí)行相關(guān)的部分。
首先來(lái)看一下在Go語(yǔ)言中exec.Cmd的定義，如下：
type Cmd struct {Path string //所需執(zhí)行命令在系統(tǒng)中的路徑Args []string //傳入命令的參數(shù)Env []string //進(jìn)程運(yùn)行時(shí)的環(huán)境變量Dir string //命令運(yùn)行的工作目錄Stdin io.ReaderStdout io.WriterStderr io.WriterExtraFiles []*os.File //進(jìn)程所需打開(kāi)的文件描述符資源SysProcAttr *syscall.SysProcAttr //可選的操作系統(tǒng)屬性Process *os.Process //代表Cmd啟動(dòng)后，操作系統(tǒng)底層的具體進(jìn)程ProcessState *os.ProcessState //進(jìn)程退出后保留的信息 }清楚Cmd的定義之后，再來(lái)分析namespaces包的Exec函數(shù)中，是如何來(lái)創(chuàng)建exec.Cmd的。在Exec函數(shù)的實(shí)現(xiàn)過(guò)程中，使用了以下代碼實(shí)現(xiàn)Exec.Cmd的創(chuàng)建：
command := createCommand(container, console, rootfs, dataPath, os.Args[0], syncPipe.Child(), args)其中createCommand為namespace.Exec函數(shù)中傳入的倒數(shù)第二個(gè)參數(shù)，類(lèi)型為CreateCommand。而createCommand只是namespaces.Exec函數(shù)的形參，真正的實(shí)參則為execdriver調(diào)用namespaces.Exec時(shí)的參數(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的定義之后，分析以上代碼的實(shí)現(xiàn)就顯得較為簡(jiǎn)單。為Cmd賦值的對(duì)象有Path，Args，SysProcAttr，ExtraFiles，Env和Dir。其中需要特別注意的是Path的值d.initPath，該路徑下存放的是dockerinit的二進(jìn)制文件，Docker 1.2.0版本下，路徑一般為“/var/lib/docker/init/dockerinit-1.2.0”。另外SysProcAttr使用以下的代碼來(lái)賦值：
&syscall.SysProcAttr{Cloneflags: uintptr(namespaces.GetNamespaceFlags(container.Namespaces)),}syscall.SysProAttr對(duì)象中的Cloneflags屬性中，即保留了libcontainer.Config類(lèi)型的實(shí)例container中的Namespace屬性。換言之，通過(guò)exec.Cmd創(chuàng)建進(jìn)程時(shí)，正是通過(guò)Cloneflags實(shí)現(xiàn)Clone系統(tǒng)調(diào)用中傳入namespace參數(shù)標(biāo)志。
回到函數(shù)執(zhí)行中，在函數(shù)的最后返回了c.Cmd，命令創(chuàng)建完畢。
4.2啟動(dòng)exec.Cmd創(chuàng)建進(jìn)程
創(chuàng)建完exec.Cmd，當(dāng)然需要將該執(zhí)行命令運(yùn)行起來(lái)，namespaces.Exec函數(shù)中直接使用以下代碼實(shí)現(xiàn)進(jìn)程的啟動(dòng)：
if err := command.Start(); err != nil {return -1, err}這一部分的內(nèi)容簡(jiǎn)單直接， Start()函數(shù)用以完成指定命令exec.Cmd的啟動(dòng)執(zhí)行，同時(shí)并不等待其啟動(dòng)完畢便返回。Start()函數(shù)的定義位于os/exec包。
進(jìn)入os/exec包，查看Start()函數(shù)的實(shí)現(xiàn)，可以看到執(zhí)行過(guò)程中，會(huì)對(duì)command.Process進(jìn)行賦值，此時(shí)command.Process中會(huì)含有剛才啟動(dòng)進(jìn)程的PID進(jìn)程號(hào)，該P(yáng)ID號(hào)屬于在宿主機(jī)pid namespace下，而并非是新創(chuàng)建namespace下的PID號(hào)。
4.3為容器進(jìn)程初始化網(wǎng)絡(luò)環(huán)境
上一環(huán)節(jié)實(shí)現(xiàn)了容器進(jìn)程的啟動(dòng)，然而卻還沒(méi)有為之配置相應(yīng)的網(wǎng)絡(luò)環(huán)境。namespaces.Exec在之后的InitializeNetworing中實(shí)現(xiàn)了為容器進(jìn)程初始化網(wǎng)絡(luò)環(huán)境。初始化網(wǎng)絡(luò)環(huán)境需要兩個(gè)非常重要的參數(shù)：container對(duì)象以及容器進(jìn)程的Pid號(hào)。類(lèi)型為libcontainer.Config的實(shí)例container中包含用戶對(duì)Docker Container的網(wǎng)絡(luò)配置需求，另外容器進(jìn)程的Pid可以使得創(chuàng)建的網(wǎng)絡(luò)環(huán)境與進(jìn)程新創(chuàng)建的namespace進(jìn)行關(guān)聯(lián)。
namespaces.Exec中為容器進(jìn)程初始化網(wǎng)絡(luò)環(huán)境的代碼實(shí)現(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)建的容器進(jìn)程初始化網(wǎng)絡(luò)環(huán)境。更為底層的實(shí)現(xiàn)包含兩個(gè)步驟：
(1) 先在容器進(jìn)程的namespace外部，創(chuàng)建容器所需的網(wǎng)絡(luò)棧；
(2) 將創(chuàng)建的網(wǎng)絡(luò)棧遷移進(jìn)入容器的net namespace。
IntializeNetworking的源代碼實(shí)現(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) }以上源碼實(shí)現(xiàn)過(guò)程中，首先通過(guò)一個(gè)循環(huán)，遍歷libcontainer.Config類(lèi)型實(shí)例container中的網(wǎng)絡(luò)屬性Networks；隨后使用GetStrategy函數(shù)處理Networks中每一個(gè)對(duì)象的Type屬性，得出Network的類(lèi)型，這里的類(lèi)型有3種，分別為“l(fā)oopback”、“veth”、“netns”。除host網(wǎng)絡(luò)模式之外，loopback對(duì)于其他每一種網(wǎng)絡(luò)模式的Docker Container都需要使用；veth針對(duì)bridge橋接模式，而netns針對(duì)other container模式。
得到Network類(lèi)型的類(lèi)型之后，libcontainer創(chuàng)建相應(yīng)的網(wǎng)絡(luò)棧，具體實(shí)現(xiàn)使用每種網(wǎng)絡(luò)棧類(lèi)型下的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è)備的實(shí)現(xiàn)代碼位于./libcontainer/network/loopback.go#L13-L15，如下：
func (l *Loopback) Create(n *Network, nspid int, networkState *NetworkState) error {return nil }令人費(fèi)解的是，libcontainer在loopback設(shè)備的創(chuàng)建函數(shù)Create中，并沒(méi)有作實(shí)質(zhì)性的內(nèi)容，而是直接返回nil。
其實(shí)關(guān)于loopback設(shè)備的創(chuàng)建，要回到Linux內(nèi)核為進(jìn)程新建namespace的階段。當(dāng)libcontainer執(zhí)行command.Start()時(shí)，由于創(chuàng)建了一個(gè)新的網(wǎng)絡(luò)namespace，故Linux內(nèi)核會(huì)自動(dòng)為新的net namespace創(chuàng)建loopback設(shè)備。當(dāng)Linux內(nèi)核創(chuàng)建完loopback設(shè)備之后，libcontainer所做的工作即只要保留loopback設(shè)備的默認(rèn)配置，并在Initialize函數(shù)中實(shí)現(xiàn)啟動(dòng)該設(shè)備。
4.3.2 veth網(wǎng)絡(luò)棧的創(chuàng)建
Veth是Docker Container實(shí)際使用的網(wǎng)絡(luò)策略之一，其使用網(wǎng)橋docker0并創(chuàng)建veth pair虛擬網(wǎng)絡(luò)設(shè)備對(duì)，最終使一個(gè)veth配置在宿主機(jī)上，而另一個(gè)veth安置在容器網(wǎng)絡(luò)namespace內(nèi)部。
libcontainer中實(shí)現(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}主要的流程包含的四個(gè)步驟：
(1) 在宿主機(jī)上創(chuàng)建veth pair；
(2) 將一個(gè)veth附加至docker0網(wǎng)橋上；
(3) 啟動(dòng)第一個(gè)veth；
(4) 將第二個(gè)veth附加至libcontainer創(chuàng)建進(jìn)程的namespace下。
使用Create函數(shù)實(shí)現(xiàn)veth pair的創(chuàng)建之后，在Initialize函數(shù)中實(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專(zhuān)門(mén)為Docker Container的other container網(wǎng)絡(luò)模式服務(wù)。netns完成的工作是將其他容器的namespace路徑傳遞給需要?jiǎng)?chuàng)建other container網(wǎng)絡(luò)模式的容器使用。
libcontainer中實(shí)現(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ù)中實(shí)現(xiàn)將網(wǎng)絡(luò)namespace的文件描述符交由新創(chuàng)建容器使用，最終實(shí)現(xiàn)兩個(gè)Docker Container共享同一個(gè)網(wǎng)絡(luò)棧。
通過(guò)Create以及Initialize的實(shí)現(xiàn)之后，Docker Container相應(yīng)的網(wǎng)絡(luò)棧環(huán)境即已經(jīng)完成創(chuàng)建，容器內(nèi)部的應(yīng)用進(jìn)程可以使用不同的網(wǎng)絡(luò)棧環(huán)境與外界或者內(nèi)部進(jìn)行通信。關(guān)于Initialize函數(shù)何時(shí)被調(diào)用，需要清楚Docker Daemon與dockerinit的關(guān)系，以及如何實(shí)現(xiàn)Docker Daemon進(jìn)程與dockerinit進(jìn)程跨namespace進(jìn)行通信，這部分內(nèi)容會(huì)在《Docker源碼分析》系列后續(xù)專(zhuān)文分析。
5.總結(jié)
如何使用Docker Container的網(wǎng)絡(luò)，一直是工業(yè)界倍加關(guān)心的問(wèn)題。本文將從Linux內(nèi)核原理的角度闡述了什么是Docker Container，并對(duì)Docker Container 4種不同的網(wǎng)絡(luò)模式進(jìn)行了初步的介紹，最終貫穿Docker 架構(gòu)中的多個(gè)模塊，如Docker Client、Docker Daemon、execdriver以及l(fā)ibcontainer，深入分析Docker Container網(wǎng)絡(luò)的實(shí)現(xiàn)步驟。
目前，若只談?wù)揇ocker，那么它還是只停留在單host宿主機(jī)的場(chǎng)景上。如何面對(duì)跨host的場(chǎng)景、如何實(shí)現(xiàn)分布式Docker Container的管理，目前為止還沒(méi)有一個(gè)一勞永逸的解決方案。再者，一個(gè)解決方案的存在，總是會(huì)適應(yīng)于一個(gè)應(yīng)用場(chǎng)景。Docker這種容器技術(shù)的發(fā)展，大大改善了傳統(tǒng)模式下使用諸如虛擬機(jī)等傳統(tǒng)計(jì)算單位存在的多數(shù)弊端，卻在網(wǎng)絡(luò)方面使得自身的使用過(guò)程中存在瑕疵。希望本文是一個(gè)引子，介紹Docker Container網(wǎng)絡(luò)，以及從源碼的角度分析Docker Container網(wǎng)絡(luò)之后，能有更多的愛(ài)好者思考Docker Container網(wǎng)絡(luò)的前世今生，并為Docker乃至容器技術(shù)的發(fā)展做出貢獻(xiàn)。
6.作者介紹
孫宏亮，DaoCloud初創(chuàng)團(tuán)隊(duì)成員，軟件工程師，浙江大學(xué)VLIS實(shí)驗(yàn)室應(yīng)屆研究生。讀研期間活躍在PaaS和Docker開(kāi)源社區(qū)，對(duì)Cloud Foundry有深入研究和豐富實(shí)踐，擅長(zhǎng)底層平臺(tái)代碼分析，對(duì)分布式平臺(tái)的架構(gòu)有一定經(jīng)驗(yàn)，撰寫(xiě)了大量有深度的技術(shù)博客。2014年末以合伙人身份加入DaoCloud團(tuán)隊(duì)，致力于傳播以Docker為主的容器的技術(shù)，推動(dòng)互聯(lián)網(wǎng)應(yīng)用的容器化步伐。郵箱：allen.sun@daocloud.io
7.參考文獻(xiàn)
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网络（下）的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Docker源码分析（七）：Docker
- 下一篇： Docker源码分析（十）：Docker