1. Docker的4種網路模式

我們在使用docker run建立Docker容器時，可以用--net選項指定容器的網路模式，Docker有以下4種網路模式：

• host模式，使用--net=host指定。
• container模式，使用--net=container:NAME_or_ID指定。
• none模式，使用--net=none指定。
• bridge模式，使用--net=bridge指定，預設設定。

下面分別介紹一下Docker的各個網路模式。

1.1 host模式

例如，我們在10.10.101.105/24的機器上用host模式啟動一個含有web應用的Docker容器，監聽tcp80埠。當我們在容器中執行任何類似ifconfig命令檢視網路環境時，看到的都是宿主機上的資訊。而外界訪問容器中的應用，則直接使用10.10.101.105:80即可，不用任何NAT轉換，就如直接跑在宿主機中一樣。但是，容器的其他方面，如檔案系統、程序列表等還是和宿主機隔離的。

眾所周知，Docker使用了Linux的Namespaces技術來進行資源隔離，如PID Namespace隔離程序，Mount Namespace隔離檔案系統，Network Namespace隔離網路等。一個Network Namespace提供了一份獨立的網路環境，包括網絡卡、路由、Iptable規則等都與其他的Network Namespace隔離。一個Docker容器一般會分配一個獨立的Network Namespace。但如果啟動容器的時候使用host模式，那麼這個容器將不會獲得一個獨立的Network Namespace，而是和宿主機共用一個Network Namespace。容器將不會虛擬出自己的網絡卡，配置自己的IP等，而是使用宿主機的IP和埠。

1.2 container模式

在理解了host模式後，這個模式也就好理解了。這個模式指定新建立的容器和已經存在的一個容器共享一個Network Namespace，而不是和宿主機共享。新建立的容器不會建立自己的網絡卡，配置自己的IP，而是和一個指定的容器共享IP、埠範圍等。同樣，兩個容器除了網路方面，其他的如檔案系統、程序列表等還是隔離的。兩個容器的程序可以通過lo網絡卡裝置通訊。

1.3 none模式

這個模式和前兩個不同。在這種模式下，Docker容器擁有自己的Network Namespace，但是，並不為Docker容器進行任何網路配置。也就是說，這個Docker容器沒有網絡卡、IP、路由等資訊。需要我們自己為Docker容器新增網絡卡、配置IP等。

1.4 bridge模式

bridge模式是Docker預設的網路設定，此模式會為每一個容器分配Network Namespace、設定IP等，並將一個主機上的Docker容器連線到一個虛擬網橋上。下面著重介紹一下此模式。

1.4.1 bridge模式的拓撲

當Docker server啟動時，會在主機上建立一個名為docker0的虛擬網橋，此主機上啟動的Docker容器會連線到這個虛擬網橋上。虛擬網橋的工作方式和物理交換機類似，這樣主機上的所有容器就通過交換機連在了一個二層網路中。接下來就要為容器分配IP了，Docker會從RFC1918所定義的私有IP網段中，選擇一個和宿主機不同的IP地址和子網分配給docker0，連線到docker0的容器就從這個子網中選擇一個未佔用的IP使用。如一般Docker會使用172.17.0.0/16這個網段，並將172.17.42.1/16分配給docker0網橋（在主機上使用ifconfig命令是可以看到docker0的，可以認為它是網橋的管理介面，在宿主機上作為一塊虛擬網絡卡使用）。單機環境下的網路拓撲如下，主機地址為10.10.101.105/24。

Docker完成以上網路配置的過程大致是這樣的：

1. 在主機上建立一對虛擬網絡卡veth pair裝置。veth裝置總是成對出現的，它們組成了一個數據的通道，資料從一個裝置進入，就會從另一個裝置出來。因此，veth裝置常用來連線兩個網路裝置。

2. Docker將veth pair裝置的一端放在新建立的容器中，並命名為eth0。另一端放在主機中，以veth65f9這樣類似的名字命名，並將這個網路裝置加入到docker0網橋中，可以通過brctl show命令檢視。

   

3. 從docker0子網中分配一個IP給容器使用，並設定docker0的IP地址為容器的預設閘道器。

網路拓撲介紹完後，接著介紹一下bridge模式下容器是如何通訊的。

1.4.2 bridge模式下容器的通訊

在bridge模式下，連在同一網橋上的容器可以相互通訊（若出於安全考慮，也可以禁止它們之間通訊，方法是在DOCKER_OPTS變數中設定--icc=false，這樣只有使用--link才能使兩個容器通訊）。

容器也可以與外部通訊，我們看一下主機上的Iptable規則，可以看到這麼一條

-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE

這條規則會將源地址為172.17.0.0/16的包（也就是從Docker容器產生的包），並且不是從docker0網絡卡發出的，進行源地址轉換，轉換成主機網絡卡的地址。這麼說可能不太好理解，舉一個例子說明一下。假設主機有一塊網絡卡為eth0，IP地址為10.10.101.105/24，閘道器為10.10.101.254。從主機上一個IP為172.17.0.1/16的容器中ping百度（180.76.3.151）。IP包首先從容器發往自己的預設閘道器docker0，包到達docker0後，也就到達了主機上。然後會查詢主機的路由表，發現包應該從主機的eth0發往主機的閘道器10.10.105.254/24。接著包會轉發給eth0，並從eth0發出去（主機的ip_forward轉發應該已經開啟）。這時候，上面的Iptable規則就會起作用，對包做SNAT轉換，將源地址換為eth0的地址。這樣，在外界看來，這個包就是從10.10.101.105上發出來的，Docker容器對外是不可見的。

那麼，外面的機器是如何訪問Docker容器的服務呢？我們首先用下面命令建立一個含有web應用的容器，將容器的80埠對映到主機的80埠。

docker run -d --name web -p 80:80 fmzhen/simpleweb

然後檢視Iptable規則的變化，發現多了這樣一條規則：

-A DOCKER ! -i docker0 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.17.0.5:80

此條規則就是對主機eth0收到的目的埠為80的tcp流量進行DNAT轉換，將流量發往172.17.0.5:80，也就是我們上面建立的Docker容器。所以，外界只需訪問10.10.101.105:80就可以訪問到容器中得服務。

除此之外，我們還可以自定義Docker使用的IP地址、DNS等資訊，甚至使用自己定義的網橋，但是其工作方式還是一樣的。

2. pipework的使用以及原始碼分析

Docker自身的網路功能比較簡單，不能滿足很多複雜的應用場景。因此，有很多開源專案用來改善Docker的網路功能，如pipework、weave、flannel等。這裡，就先介紹一下pipework的使用和工作原理。

pipework是由Docker的工程師Jérôme Petazzoni開發的一個Docker網路配置工具，由200多行shell實現，方便易用。下面用三個場景來演示pipework的使用和工作原理。

2.1 將Docker容器配置到本地網路環境中

為了使本地網路中的機器和Docker容器更方便的通訊，我們經常會有將Docker容器配置到和主機同一網段的需求。這個需求其實很容易實現，我們只要將Docker容器和主機的網絡卡橋接起來，再給Docker容器配上IP就可以了。

下面我們來操作一下，我主機A地址為10.10.101.105/24,閘道器為10.10.101.254,需要給Docker容器的地址配置為10.10.101.150/24。在主機A上做如下操作：

#安裝pipework
git clone https://github.com/jpetazzo/pipework
cp ~/pipework/pipework /usr/local/bin/
#啟動Docker容器。
docker run -itd --name test1 ubuntu /bin/bash
#配置容器網路，並連到網橋br0上。閘道器在IP地址後面加@指定。
#若主機環境中存在dhcp伺服器，也可以通過dhcp的方式獲取IP
#pipework br0 test1 dhcp
pipework br0 test1 10.10.101.150/[email protected]
#將主機eth0橋接到br0上，並把eth0的IP配置在br0上。這裡由於是遠端操作，中間網路會斷掉，所以放在一條命令中執行。
ip addr add 10.10.101.105/24 dev br0; \
    ip addr del 10.10.101.105/24 dev eth0; \
    brctl addif br0 eth0; \
    ip route del default; \
    ip route add default gw 10.10.101.254 dev br0

完成上述步驟後，我們發現Docker容器已經可以使用新的IP和主機網路裡的機器相互通訊了。

pipework工作原理分析

那麼容器到底發生了哪些變化呢？我們docker attach到test1上，發現容器中多了一塊eth1的網絡卡，並且配置了10.10.101.150/24的IP，而且預設路由也改為了10.10.101.254。這些都是pipework幫我們配置的。通過檢視原始碼，可以發現pipework br0 test1 10.10.101.150/[email protected]是由以下命令完成的（這裡只列出了具體執行操作的程式碼）。

#建立br0網橋
#若ovs開頭，則建立OVS網橋 ovs-vsctl add-br ovs*
brctl addbr $IFNAME
#建立veth pair,用於連線容器和br0
ip link add name $LOCAL_IFNAME mtu $MTU type veth peer name $GUEST_IFNAME mtu $MTU
#找到Docker容器test1在主機上的PID,建立容器網路名稱空間的軟連線
DOCKERPID=$(docker inspect --format='{{ .State.Pid }}' $GUESTNAME)
ln -s /proc/$NSPID/ns/net /var/run/netns/$NSPID
#將veth pair一端放入Docker容器中，並設定正確的名字eth1
ip link set $GUEST_IFNAME netns $NSPID
ip netns exec $NSPID ip link set $GUEST_IFNAME name $CONTAINER_IFNAME
#將veth pair另一端加入網橋
#若為OVS網橋則為 ovs-vsctl add-port $IFNAME $LOCAL_IFNAME ${VLAN:+"tag=$VLAN"}
brctl addif $IFNAME $LOCAL_IFNAME
#為新增加的容器配置IP和路由
ip netns exec $NSPID ip addr add $IPADDR dev $CONTAINER_IFNAME
ip netns exec $NSPID ip link set $CONTAINER_IFNAME up
ip netns exec $NSPID ip route delete default
ip netns exec $NSPID ip route add $GATEWAY/32 dev $CONTAINER_IFNAME

1. 首先pipework檢查是否存在br0網橋，若不存在，就自己建立。若以"ovs"開頭，就會建立OpenVswitch網橋，以"br"開頭，建立Linux bridge。
2. 建立veth pair裝置，用於為容器提供網絡卡並連線到br0網橋。
3. 使用docker inspect找到容器在主機中的PID，然後通過PID將容器的網路名稱空間連結到/var/run/netns/目錄下。這麼做的目的是，方便在主機上使用ip netns命令配置容器的網路。因為，在Docker容器中，我們沒有許可權配置網路環境。
4. 將之前建立的veth pair裝置分別加入容器和網橋中。在容器中的名稱預設為eth1，可以通過pipework的-i引數修改該名稱。
5. 然後就是配置新網絡卡的IP。若在IP地址的後面加上閘道器地址，那麼pipework會重新配置預設路由。這樣容器通往外網的流量會經由新配置的eth1出去，而不是通過eth0和docker0。(若想完全拋棄自帶的網路設定，在啟動容器的時候可以指定--net=none)

以上就是pipework配置Docker網路的過程，這和Docker的bridge模式有著相似的步驟。事實上，Docker在實現上也採用了相同的底層機制。

通過原始碼，可以看出，pipework通過封裝Linux上的ip、brctl等命令，簡化了在複雜場景下對容器連線的操作命令，為我們配置複雜的網路拓撲提供了一個強有力的工具。當然，如果想了解底層的操作，我們也可以直接使用這些Linux命令來完成工作，甚至可以根據自己的需求，新增額外的功能。

2.2 單主機Docker容器VLAN劃分

pipework不僅可以使用Linux bridge連線Docker容器，還可以與OpenVswitch結合，實現Docker容器的VLAN劃分。下面，就來簡單演示一下，在單機環境下，如何實現Docker容器間的二層隔離。

為了演示隔離效果，我們將4個容器放在了同一個IP網段中。但實際他們是二層隔離的兩個網路，有不同的廣播域。

#在主機A上建立4個Docker容器，test1、test2、test3、test4
docker run -itd --name test1 ubuntu /bin/bash
docker run -itd --name test2 ubuntu /bin/bash
docker run -itd --name test3 ubuntu /bin/bash
docker run -itd --name test4 ubuntu /bin/bash
#將test1，test2劃分到一個vlan中，vlan在mac地址後加@指定，此處mac地址省略。
pipework ovs0 test1 192.168.0.1/24 @100
pipework ovs0 test2 192.168.0.2/24 @100
#將test3，test4劃分到另一個vlan中
pipework ovs0 test3 192.168.0.3/24 @200
pipework ovs0 test4 192.168.0.4/24 @200

完成上述操作後，使用docker attach連到容器中，然後用ping命令測試連通性，發現test1和test2可以相互通訊，但與test3和test4隔離。這樣，一個簡單的VLAN隔離容器網路就已經完成。

由於OpenVswitch本身支援VLAN功能，所以這裡pipework所做的工作和之前介紹的基本一樣，只不過將Linux bridge替換成了OpenVswitch，在將veth pair的一端加入ovs0網橋時，指定了tag。底層操作如下：

ovs-vsctl add-port ovs0 veth* tag=100

2.3 多主機Docker容器的VLAN劃分

上面介紹完了單主機上VLAN的隔離，下面我們將情況延伸到多主機的情況。有了前面兩個例子做鋪墊，這個也就不難了。為了實現這個目的，我們把宿主機上的網絡卡橋接到各自的OVS網橋上，然後再為容器配置IP和VLAN就可以了。我們實驗環境如下，主機A和B各有一塊網絡卡eth0，IP地址分別為10.10.101.105/24、10.10.101.106/24。在主機A上建立兩個容器test1、test2，分別在VLAN 100和VLAN 200上。在主機B上建立test3、test4，分別在VLAN 100和VLAN 200 上。最終，test1可以和test3通訊，test2可以和test4通訊。

#在主機A上
#建立Docker容器
docker run -itd --name test1 ubuntu /bin/bash
docker run -itd --name test2 ubuntu /bin/bash
#劃分VLAN
pipework ovs0 test1 192.168.0.1/24 @100
pipework ovs0 test2 192.168.0.2/24 @200
#將eth0橋接到ovs0上
ip addr add 10.10.101.105/24 dev ovs0; \
    ip addr del 10.10.101.105/24 dev eth0; \
    ovs-vsctl add-port ovs0 eth0; \
    ip route del default; \
    ip route add default gw 10.10.101.254 dev ovs0
    
#在主機B上
#建立Docker容器
docker run -itd --name test3 ubuntu /bin/bash
docker run -itd --name test4 ubuntu /bin/bash
#劃分VLAN
pipework ovs0 test1 192.168.0.3/24 @100
pipework ovs0 test2 192.168.0.4/24 @200
#將eth0橋接到ovs0上
ip addr add 10.10.101.106/24 dev ovs0; \
    ip addr del 10.10.101.106/24 dev eth0; \
    ovs-vsctl add-port ovs0 eth0; \
    ip route del default; \
    ip route add default gw 10.10.101.254 dev ovs0

完成上面的步驟後，主機A上的test1和主機B上的test3容器就劃分到了一個VLAN中，並且與主機A上的test2和主機B上的test4隔離（主機eth0網絡卡需要設定為混雜模式，連線主機的交換機埠應設定為trunk模式，即允許VLAN 100和VLAN 200的包通過）。拓撲圖如下所示（省去了Docker預設的eth0網絡卡和主機上的docker0網橋）：

除此之外，pipework還支援使用macvlan裝置、設定網絡卡MAC地址等功能。不過，pipework有一個缺陷，就是配置的容器在關掉重啟後，之前的設定會丟失。

3. 總結

通過上面的介紹，我相信大家對Docker的網路已經有了一定的瞭解。對於一個基本應用而言，Docker的網路模型已經很不錯了。然而，隨著雲端計算和微服務的興起，我們不能永遠停留在使用基本應用的級別上，我們需要效能更好且更靈活的網路功能。pipework正好滿足了我們這樣的需求，從上面的樣例中，我們可以看到pipework的方便之處。但是，同時也應注意到，pipework並不是一套解決方案，它只是一個網路配置工具，我們可以利用它提供的強大功能，幫助我們構建自己的解決方案。