Docker容器是近两年最 火的IT技术之一，用“火山爆发式“来形容Docker的成 长也不为过。Docker在产品服务的devops 运维、云 计算(CaaS)、大数据以及企业内部应用等领域正在被越来越多的接受和广泛应用。Docker技术的本质在于提升计算密度和提升部署效率，高屋 建瓴的讲，它的出现符合人类社会对绿色发展的追求，降低资源消耗，提升资源的单位利用率。不过经历了两年多的发展，Docker依旧年轻，尚未成 熟，在集群调度、存储、网络、安全等方面，Docker依旧有很长的路要走。

在一年多以前，也就是Docker发布1.0后没几个月时，我曾经学习过一段时间的Docker，主要学习Docker的概念和基本使用方法。由于当时docker 还相对“稚嫩”，在产品和项目中暂无用武之地，也就没有深入，但对Docker技术的跟踪倒是没有停下来。今年Docker 1.9发布，支持跨主机container netwoking；第三方容器集群调度和服务编织工具蓬勃发展，如Kubernetes 、mesos、 flannel以及rancher等；国内基于Docker的云服 务及产品也 如雨后春笋般发展开来。虽然不到2年，但Docker的演进速度是飞快的，要想跟的上Docker的步伐，仅仅跟踪技术信息是不够的，对伴生 Docker发展起来的一些新理念、新技术、新方案需要更深入的理解，这便是这篇文章（以及后续关于这个主题文章）编写的初衷。

我计划从容器网络开始，我们先来看看单机容器网络。

一、目标

Docker实质上是汇集了linux容器（各种namespaces）、cgroups以及“叠加”类文件系统等多种核心技术的一种复合技术。 其默认容器网络的建立和控制是一种结合了network namespace、iptables、linux网桥、route table等多种Linux内核技术的综合方案。理解Docker容器网络，首先是以对TCP/IP网络体系的理解为前提的，不过也不需要多深刻，大学本 科学的那套“计算机网络”足矣^_^，另外还要考虑Linux上对虚拟网络设备实现的独特性（区分于硬件网络设备）。

本篇文章主要针对单机Docker容器网络，目的是了解Docker容器网络中容器与容器间通信、容器与宿主机间通信、容器与宿主机所在的物理网 络中主机通信、容器网络控制等机制，为后续理解跨主机容器网络的理解打下基础。同时稍带利用工具对Docker容器网络的网络性能做初步测量，通 过直观数据初步评估容器网络的适用性。

二、试验环境以及拓扑

本文试验环境如下：

- 宿主机 Ubuntu 12.04 x86_64 3.13.0-61-generic
- 容器OS：基于Ubuntu 14.04 Server x86_64的自制image
- Docker版本 - v1.9.1 for linux/amd64

为了试验方便，这里基于官方ubuntu:14.04 image制作了带有traceroute、brctl以及tcpdump等网络调试工具的image，简单起见（考虑到公司内网代理），这里就没有写 Dockerfile(即便写也很简单)，而是直接z在容器内apt-get install后，再通过docker commit基于已经安装好上述工具的container创建的一个新image：

$sudo docker commit 0580adb079a3 dockernetworking/ubuntu:14.04
a692757cbb7bd7d8b70f393930e954cce625934485e93cf1b28c15efedb5f2d3
$ docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
dockernetworking/ubuntu   14.04               a692757cbb7b        5 seconds ago       302.1 MB

后续的container均是基于dockernetworking/ubuntu创建的。

另外试验环境的拓扑图如下：

从拓扑图中我们可以看到，物理宿主机为10.10.126.101，置于物理局域网10.10.126.0/24中。在宿主机上我们创建了两 个 Container：Container1和Container2，Container所用网段为172.17.0.0/16。

三、Docker Daemon初始网络

当你在一个clean环境下，启动Docker daemon后，比如在Ubuntu下，使用sudo service docker start，Docker Daemon就会初始化后续创建容器时所需的基础网络设备和配置。

以下是从宿主机的角度看到的：

// 网桥
$ brctl show
bridge name    bridge id        STP enabled    interfaces
docker0        8000.0242f9f8c9ad    no

// 网络设备
$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 2c:59:e5:01:98:28 brd ff:ff:ff:ff:ff:ff
... ...
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:f9:f8:c9:ad brd ff:ff:ff:ff:ff:ff

// 网络设备ip地址
$ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 2c:59:e5:01:98:28 brd ff:ff:ff:ff:ff:ff
    inet 10.10.126.101/24 brd 10.10.126.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::2e59:e5ff:fe01:9828/64 scope link
       valid_lft forever preferred_lft forever
... ...
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 02:42:f9:f8:c9:ad brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:f9ff:fef8:c9ad/64 scope link
       valid_lft forever preferred_lft forever

可以看出，与Docker Daemon启动前相比，宿主物理机中多出来一个虚拟网络设备：docker0。

docker0是一个标准Linux虚拟网桥设备。在Docker默认的桥接网络工作模式中，docker0网桥起到了至关重要的作用。物理网桥 是标准的二层网络设备，一般说，标准物理网桥只有两个网口，可以将两个物理网络（区分以IP为寻址单位的逻辑网络）连接在一起。但与物理层设备集 线器等相比，网桥具备隔离冲突域的功能。网桥通过MAC地址学习和泛洪的方式实现二层相对高效的通信。在今天，标准网桥设备已经基本被淘汰了，替 代网桥的是是二层交换机。二层交换机也可以看成一个多口网桥。在不划分vlan的前提下，可以将其当做两两端口间都是独立通道的”hub”使用。

前面说过docker0是一个标准Linux虚拟网桥设备，即一个以软件实现的网桥，由于其支持多口，实际上它算是一个虚拟交换机设备。与物理网 桥不同的是，它不但可以二层转发包，还可以将包送到用户层进行处理。在我们尚未创建container的时候，docker0以一个Linux网 络设 备的身份存在，并且Linux虚拟网桥可以配置IP，可以作为在三层网络上的一个Gateway，在主机眼中和物理网口设备eth0区别不大。与 Linux其他网络设备也可以在三层相互通信，前提是Docker Daemon打开了ip包转发功能：

$ cat /proc/sys/net/ipv4/ip_forward
1

宿主机的路由表也增加了一条路由(见最后一条)：

$ ip route
default via 10.10.126.1 dev eth0  proto static
10.10.126.0/24 dev eth0  proto kernel  scope link  src 10.10.126.101  metric 1
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1

除此之外，Docker Daemon还设置了若干iptables规则以管理containers间的通信以及辅助container访问外部网络（NAT转换）：

sudo iptables-save > ./iptables.init.rules

# Generated by iptables-save v1.4.12 on Wed Jan 13 17:25:55 2016
*raw
: PREROUTING ACCEPT [9469:2320376]
:OUTPUT ACCEPT [2990:1335235]
COMMIT
# Completed on Wed Jan 13 17:25:55 2016
# Generated by iptables-save v1.4.12 on Wed Jan 13 17:25:55 2016
*filter
:INPUT ACCEPT [1244:341290]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [483:153047]
: DOCKER - [0:0]
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
COMMIT
# Completed on Wed Jan 13 17:25:55 2016
# Generated by iptables-save v1.4.12 on Wed Jan 13 17:25:55 2016
*nat
: PREROUTING ACCEPT [189:88629]
:INPUT ACCEPT [111:60817]
:OUTPUT ACCEPT [23:1388]
: POSTROUTING ACCEPT [23:1388]
: DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
COMMIT
# Completed on Wed Jan 13 17:25:55 2016

iptables是Linux内核自带的包过滤防火墙，支持NAT等诸多功能。iptables由表和规则chain概念组成，Docker中所 用的表包括filter表和nat表（参见上述命令输出结果），这也是iptables中最常用的两个表。iptables是一个复杂的存在，曾 有一本书《linux firewalls》 专门讲解iptables，这里先借用本书 中的一幅图来描述一下ip packets在各个表和chain之间的流转过程：

网卡收到的数据包进入到iptables后，做路由选择，本地的包通过INPUT链送往user层应用；转发到其他网口的包通过FORWARD chain；本地产生的数据包在路由选择后，通过OUTPUT chain；最后POSTROUTING chain多用于source nat转换。

iptables在容器网络中最重要的两个功能：

1、限制container间的通信
2、将container到外部网络包的源地址换成宿主主机地址(MASQUERADE)

后续还会在详细描述容器通信流程中还会掺杂说明iptables的规则在容器通信中的作用。

四、准备工作：让iptables输出log

iptables在Docker单机容器默认网络工作模式下扮演着重要的角色，并且由于是虚拟设备网络，数据的流转是十分复杂的，为了便于跟踪 iptables在docker容器网络数据通信过程中起到的作用，这里在默认iptables规则的基础上，做一些调整，在关键位置输出一些 log，以便调试和理解，这些修改不会影响iptables对数据包的匹配和操作。注意：在操作iptables前，建议通过iptables- save命令备份一份iptables的配置数据。

iptables自身就支持LOG target，日志会输出到/var/log/syslog或kern.log中。我们的目标就是在关键节点输出iptables的数据日志。考虑到日志 量较大，我们仅拦截icmp包（ping)以及tcp 源端口或目的端口为12580的数据。

考虑到篇幅有限，这里仅给出配置后导出的iptables.final.rules，需要的同学可以通过iptables-restore < iptables.final.rules导入。

# Generated by iptables-save v1.4.12 on Thu Jan 14 09:28:43 2016
*raw
: PREROUTING ACCEPT [788:127290]
:OUTPUT ACCEPT [574:100918]
-A PREROUTING -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-RawPrerouting:" --log-level 7
-A PREROUTING -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-RawPrerouting:" --log-level 7
-A OUTPUT -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-RawOutput:" --log-level 7
-A OUTPUT -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-RawOutput:" --log-level 7
COMMIT
# Completed on Thu Jan 14 09:28:43 2016
# Generated by iptables-save v1.4.12 on Thu Jan 14 09:28:43 2016
*filter
:INPUT ACCEPT [284:49631]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [81:28047]
: DOCKER - [0:0]
:FwdId0Od0 - [0:0]
:FwdId0Ond0 - [0:0]
:FwdOd0 - [0:0]
-A INPUT ! -i lo -p icmp -j LOG --log-prefix "[TonyBai]-EnterFilterInput:" --log-level 7
-A INPUT -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-FilterInput:" --log-level 7
-A INPUT -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-FilterInput:" --log-level 7
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j FwdOd0
-A FORWARD -i docker0 ! -o docker0 -j FwdId0Ond0
-A FORWARD -i docker0 -o docker0 -j FwdId0Od0
-A OUTPUT ! -s 127.0.0.1/32 -p icmp -j LOG --log-prefix "[TonyBai]-EnterFilterOutput:" --log-level 7
-A OUTPUT -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-FilterOutput:" --log-level 7
-A OUTPUT -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-FilterOutput:" --log-level 7
-A FwdId0Od0 -i docker0 -o docker0 -j LOG --log-prefix "[TonyBai]-FwdId0Od0:" --log-level 7
-A FwdId0Od0 -i docker0 -o docker0 -j ACCEPT
-A FwdId0Ond0 -i docker0 ! -o docker0 -j LOG --log-prefix "[TonyBai]-FwdId0Ond0:" --log-level 7
-A FwdId0Ond0 -i docker0 ! -o docker0 -j ACCEPT
-A FwdOd0 -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j LOG --log-prefix "[TonyBai]-FwdOd0:" --log-level 7
-A FwdOd0 -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
COMMIT
# Completed on Thu Jan 14 09:28:43 2016
# Generated by iptables-save v1.4.12 on Thu Jan 14 09:28:43 2016
*nat
: PREROUTING ACCEPT [37:6070]
:INPUT ACCEPT [20:2585]
:OUTPUT ACCEPT [6:364]  OSTROUTING ACCEPT [6:364]
: DOCKER - [0:0]
:LogNatPostRouting - [0:0]
-A PREROUTING -p icmp -j LOG --log-prefix "[TonyBai]-Enter iptables:" --log-level 7
-A PREROUTING -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-NatPrerouting:" --log-level 7
-A PREROUTING -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-NatPrerouting:" --log-level 7
-A INPUT ! -i lo -p icmp -j LOG --log-prefix "[TonyBai]-EnterNatInput:" --log-level 7
-A INPUT -p tcp -m tcp --dport 12580 -j LOG --log-prefix "[TonyBai]-NatInput:" --log-level 7
-A INPUT -p tcp -m tcp --sport 12580 -j LOG --log-prefix "[TonyBai]-NatInput:" --log-level 7
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j LogNatPostRouting
-A LogNatPostRouting -s 172.17.0.0/16 ! -o docker0 -j LOG --log-prefix "[TonyBai]-NatPostRouting:" --log-level 7
-A LogNatPostRouting -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
COMMIT
# Completed on Thu Jan 14 09:28:43 2016

一切就绪，只待对docker网络的分析了。

五、容器网络

现在我们来启动容器。根据试验环境拓扑图，我们需要创建和启动两个容器：container1和container2。

$ docker run -it --name container1 dockernetworking/ubuntu:14.04 /bin/bash
$ docker run -it --name container2 dockernetworking/ubuntu:14.04 /bin/bash

$ docker ps
CONTAINER ID        IMAGE                           COMMAND             CREATED             STATUS              PORTS               NAMES
1104fc63c571        dockernetworking/ubuntu:14.04   "/bin/bash"         7 seconds ago       Up 6 seconds                            container2
8b38131deb28        dockernetworking/ubuntu:14.04   "/bin/bash"         16 seconds ago      Up 15 seconds                           container1

容器启动后，从宿主机的视角，可以看到网络配置有如下变化：

$ brctl show
bridge name    bridge id        STP enabled    interfaces
docker0        8000.0242f9f8c9ad    no        veth00855d7
                            vethee8659f

$ifconfig -a
... ...
veth00855d7 Link encap:以太网  硬件地址 ea:70:65:cf:28:6b
          inet6 地址: fe80::e870:65ff:fecf:286b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  跃点数:1
          接收数据包:8 错误:0 丢弃:0 过载:0 帧数:0
          发送数据包:37 错误:0 丢弃:0 过载:0 载波:0
          碰撞:0 发送队列长度:0
          接收字节:648 (648.0 B)  发送字节:5636 (5.6 KB)

vethee8659f Link encap:以太网  硬件地址 fa:30:bb:0b:1d:eb
          inet6 地址: fe80::f830:bbff:fe0b:1deb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  跃点数:1
          接收数据包:61 错误:0 丢弃:0 过载:0 帧数:0
          发送数据包:82 错误:0 丢弃:0 过载:0 载波:0
          碰撞:0 发送队列长度:0
          接收字节:5686 (5.6 KB)  发送字节:9678 (9.6 KB)
... ...

Docker Daemon创建了两个veth网络设备，并将veth挂接到docker0网桥上了。veth是一种虚拟网卡设备，创建时成对(veth pair)出现，从一个veth peer发出的数据包可以到达其pair peer。不过从上面命令输出来看，我们似乎并没有看到veth pair，这是因为每个pair的另一peer被放到container的network namespace中了，变成了container中的eth0。veth pair常用于在不同网络命名空间之间通信。在拓扑图中，container1中的eth0与veth-x是一个pair；container2中的 eth0与veth-y是另一个pair。veth-x和veth-y挂接在docker0网桥上，这对于container1和 container2来说，就好比用网线将本地网卡(eth0)与网桥设备docker0的网口连接起来一样。在docker容器网络默认桥接模式 中，veth只是在二层起作用。

下面是从container1内部看到的网络配置：

root@8b38131deb28:/# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
47: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.2/16 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:2/64 scope link
       valid_lft forever preferred_lft forever

root@8b38131deb28:/# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.17.0.1      0.0.0.0         UG        0 0          0 eth0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 eth0

container网络配置很简单，一个eth0网卡，一个loopback口，route表里将网桥作为默认Gateway。

至此，我们拓扑图中的环境已经全部就绪。接下来我们来探索和理解一下容器网络的几种通信流程。

六、Docker0的“双重身份”

在正式进入每个通信流程前，我们先来点预备性内容 – 如何理解Docker0。下图中我们给出了Docker0的双重身份，并对比物理交换机，我们来理解一下Docker0这个软网桥。

1、从容器视角，网桥（交换机）身份

docker0对于通过veth pair“插在”网桥上的container1和container2来说，首先就是一个二层的交换机的角色：泛洪、维护cam表，在二层转发数据包；同 时由于docker0自身也具有mac地址（这个与纯二层交换机不同），并且绑定了ip(这里是172.17.0.1)，因此在 container中还作为container default路由的默认Gateway而存在。

2、从宿主机视角，网卡身份

物理交换机提供了由硬件实现的高效的背板通道，供连接在交换机上的主机高效实现二层通信；对于开启了三层协议的物理交换机而言，其ip路由的处理 也是由物理交换机管理程序提供的。对于docker0而言，其负责处理二层交换机逻辑以及三层的处理程序其实就是宿主机上的Linux内核 tcp/ip协议栈程序。而从宿主机来看，所有docker0从veth（只是个二层的存在，没有绑定ipv4地址）接收到的数据包都会被宿主机 看成从docker0这块网卡（第二个身份，绑定172.17.0.1)接收进来的数据包，尤其是在进入三层时，宿主机上的iptables就会 对docker0进来的数据包按照rules进行相应处理（通过一些内核网络设置也可以忽略docker0 brigde数据的处理）。

在后续的Docker容器网络通信流程分析中，docker0将在这两种身份间来回切换。

七、容器网络通信流程

考虑到大部分tcp/ip实现都是在内核实现的ping服务器，这可能会导致iptables流程走不全，影响我们的理解，因此我这里通过tcp 连接建立的握手过程(sync, ack sync, ack)的通信包来理解container网络通信。我们可以简单在服务端启动一个python httpserver: python -m SimpleHTTPServer 12580或用Go写个简单的http server来监听12580端口；客户端用telnet ip port的方式与服务端建立连接。

iptables的log我们可以在宿主机(ubuntu 12.04)的/var/log/syslog中查看到。考虑到篇幅，头两个例子会作详细说明，后续将简要阐述。

1、container to container

场景：我们在container2(172.17.0.3)中启动监听12580的服务程序，并在container1(172.17.0.2) 中执行：telnet 172.17.0.3 12580。

分析：

我们首先从container1的视角去看。

在container1中无需考虑iptables过程，可以理解为未开启。container1的用户层的数据进入该网络名字空间 (network namespace)的网络协议栈处理。在route decision过程中，协议栈处理程序发现目的地址匹配172.17.0.0/16这条网络路由，该条路由的Flag为U，即该网络为直连链路上的网 络，即无需使用Gateway，直接可以将数据包发到eth0上并封包发出去即可。

由于可以在直连网路链路上找到目的主机，于是二层欲填写的目的mac地址为172.17.0.3这个ip对应的mac。container1在 arp缓存中查询172.17.0.3对应的mac地址。如没有发现172.17.0.3这个ip地址对应的缓存mac地址，则发起一个arp请 求，arp请求的二层目的mac地址填写为二层广播地址：bit全1的mac地址（48bit），并通过eth0发出去。

docker0在这个过程中二层交换机的作用。接收到来自veth上的广播arp请求后，将请求通过二层网络转发到其他docker0上的 veth口上。这时container2收到了arp请求，container2上的以太网驱动程序收到arp请求后，将其发给 container2上的arp协议处理程序(不走iptables)，arp协议处理程序封装arp reply后转出。container1收到reply后，处理二层封包，将container2的mac地址填入以太网数据帧的目的mac地址字段中， 并发出。

上一节提到过，docker0收到container1发来的ip数据包，交由其处理程序，也就是linux内核协议栈处理程序处理，这时 docker0的身份开始转换了。

我们现在转换到宿主机视角。

从宿主机视角，docker0是一个mac地址为02:42:f9:f8:c9:ad，ip为172.17.0.1的网卡（网卡身份）。 container1发出的进入到docker0的包，对于host来说，就好比从docker0这块网卡设备进入到宿主机的数据包。当数据包进 入到三层时，iptables的处理规则就起了作用。我们看到在raw prerouting中的日志：

Jan 14 10:08:12 pc-baim kernel: [830038.910054] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:ac:11:00:03:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=172.17.0.3 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=24284 DF PROTO=TCP SPT=43292 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

这是第一个ip包，承载着tcp sync数据。按照iptables的数据流转，接下来的route decision发现目的地址是172.17.0.3，不是自身绑定的172.17.0.1，不用送到user层（不走input链），在host的路由 表中继续匹配路由表项，匹配到如下路由表项：172.17.0.0/16 dev docker0，于是走forward链：

Jan 14 10:08:12 pc-baim kernel: [830038.910120] [TonyBai]-FwdId0Od0:IN=docker0 OUT=docker0 PHYSIN=vethd9f6465 PHYSOUT=vethfcceafa MAC=02:42:ac:11:00:03:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=172.17.0.3 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=24284 DF PROTO=TCP SPT=43292 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

这又是一个直连网络，无需Gateway作为下一跳，于是再从docker0将数据送出。

docker0送出时，docker0又回到二层功能范畴。在cam表中查找mac地址02:42:ac:11:00:03对应的网口 vethfcceafa，将数据从vethfcceafa送出去。根据veth pair的描述，container2中的eth0将收到这份数据。container2发现数据包中目的地址是172.17.0.3，就是自身eth0 的地址，于是送到user层处理。

接下来是container 3 回复ack sync的过程。与上面类似，container3通过直连网络将数据包发给docker0。从host视角看，数据包从docker0这个网卡设备进 来：

Jan 14 10:08:12 pc-baim kernel: [830038.910200] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethfcceafa MAC=02:42:ac:11:00:02:02:42:ac:11:00:03:08:00 SRC=172.17.0.3 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=43292 WINDOW=28960 RES=0x00 ACK SYN URGP=0

route decision，由于目的地址不是docker0自身的目的地址，匹配路由条目：172.17.0.0/16 dev docker0，于是走forward链。这次在iptables forward链中匹配到的rules是：FwdOd0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
6 328 DOCKER all — * docker0 0.0.0.0/0 0.0.0.0/0
5 268 FwdOd0 all — * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
… …

因为这次是conn established相关的链路上回包，日志如下：

Jan 14 10:08:12 pc-baim kernel: [830038.910230] [TonyBai]-FwdOd0:IN=docker0 OUT=docker0 PHYSIN=vethfcceafa PHYSOUT=vethd9f6465 MAC=02:42:ac:11:00:02:02:42:ac:11:00:03:08:00 SRC=172.17.0.3 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=43292 WINDOW=28960 RES=0x00 ACK SYN URGP=0

于是ack sync再从docker0送出。docker0送出时封装包时回到二层功能范畴。在cam表中查找mac地址02:42:ac:11:00:02对应的 网口vethd9f6465，将数据从vethd9f6465送出去。根据veth pair的描述，container1中的eth0将收到这份数据包。container1发现数据包中目的地址是172.17.0.2，就是自身 eth0的地址，于是送到user层处理。

container1接下来的回送ack过程与sync过程类似，这里就不赘述了。

2、container to docker0

场景：我在container1(172.17.0.2)中执行：telnet 172.17.0.1 12580。docker0所在宿主机上并没有程序在监听12580端口，因此这个tcp连接是无法建立起来的。sync过去后，对方返回ack rst，而不是ack sync。

分析：

我们首先从container1的视角去看。

container1向172.17.0.1建立连接，在路由decision后，发现目标主机在直连网络中，于是将对方mac地址封装到二层协 议帧中后通过eth0将包转出。docker0收到包后，送到宿主机网络协议栈，也就是docker0的管理程序去处理。

切换到宿主机视角。宿主机从网卡docker0获取数据包，宿主机网络协议栈处理数据包，进入iptables中：

Jan 14 12:53:02 pc-baim kernel: [839935.434253] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=172.17.0.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=29166 DF PROTO=TCP SPT=41362 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

路由decision后发现目的地址就是docker0自己的地址(172.17.0.1)，要送给user层，于是走filter input链：

Jan 14 12:53:02 pc-baim kernel: [839935.434309] [TonyBai]-FilterInput:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=172.17.0.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=29166 DF PROTO=TCP SPT=41362 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

送到user层后，user层发现没有程序监听12580端口，于是向下发出ack rst包。数据包重新路由后，发现是直连网络，从docker0口出。但出去之前需要先进入iptables的filter output链：

Jan 14 12:53:02 pc-baim kernel: [839935.434344] [TonyBai]-FilterOutput:IN= OUT=docker0 SRC=172.17.0.1 DST=172.17.0.2 LEN=40 TOS=0x10 PREC=0x00 TTL=64 ID=781 DF PROTO=TCP SPT=12580 DPT=41362 WINDOW=0 RES=0x00 ACK RST URGP=0

数据包从docker0进入后，docker0承担网桥角色，在二层转发给container1，结束处理。

3、container to host

场景：我在container1(172.17.0.2)中执行：telnet 10.10.126.101 12580。docker0所在宿主机上启动服务程序在监听12580端口，因此这是个标准tcp连接建立过程（sync, ack sync, ack）。

分析：

我们首先从container1的视角去看。

container1在经过路由判断后，匹配到default路由，需要走gateway(flags = UG)，于是将目的mac填写为Gateway 172.0.0.1的mac地址，将包通过eth0转给Gateway，即docker0。

切换到宿主机视角。

宿主机从网卡docker0收到一个数据包，进入iptables：

Jan 14 14:11:28 pc-baim kernel: [844644.563436] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.101 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=55780 DF PROTO=TCP SPT=59373 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

路由decision，由于目的地址是10.10.126.101，docker0的管理程序，也就是host的linux网络栈处理程序发现这 不是我自己么（虽然是从 docker0收到的，但网络栈程序知道172.0.0.1和10.10.126.101都是自己），于是user层收下了这个包。因此在路由 后，数据包走到filter input:

Jan 14 14:11:28 pc-baim kernel: [844644.563476] [TonyBai]-FilterInput:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.101 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=55780 DF PROTO=TCP SPT=59373 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

user层监听12580的服务程序收到包后，回复ack syn到172.17.0.2，路由Decision后，发现在直连网络中，通过docker0转出，于是走iptable filter output。

Jan 14 14:11:28 pc-baim kernel: [844644.563519] [TonyBai]-FilterOutput:IN= OUT=docker0 SRC=10.10.126.101 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=59373 WINDOW=28960 RES=0x00 ACK SYN URGP=0

container1收到ack syn后再回复ack，路径与sync一致，日志如下：

Jan 14 14:11:28 pc-baim kernel: [844644.563566] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.101 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=55781 DF PROTO=TCP SPT=59373 DPT=12580 WINDOW=229 RES=0x00 ACK URGP=0
Jan 14 14:11:28 pc-baim kernel: [844644.563584] [TonyBai]-FilterInput:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.101 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=55781 DF PROTO=TCP SPT=59373 DPT=12580 WINDOW=229 RES=0x00 ACK URGP=0

4、host to container

场景：我在宿主机(10.10.126.101)中执行：telnet 172.17.0.2 12580。container1上启动服务程序在监听12580端口，因此这是个标准tcp连接建立过程（sync, ack sync, ack）。

分析：

这次我们首先从宿主机角度出发。

host的telnet程序在用户层产生数据包，经路由decision，匹配直连网络路由，出口docker0，然后进入iptables的 filter output链：

Jan 14 14:19:25 pc-baim kernel: [845121.897441] [TonyBai]-FilterOutput:IN= OUT=docker0 SRC=172.17.0.1 DST=172.17.0.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=51756 DF PROTO=TCP SPT=44120 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

你会发现在这个log中，数据包的src ip地址为172.17.0.1，这是协议栈处理程序的选择，没有选择10.10.126.101，这些地址都标识host自己。

container1在收到sync后，回复ack sync，这就相当于container to host。host这次从docker0收到目的为172.17.0.1的ack sync包 , 走的是filer input，这里不赘述。

Jan 14 14:19:25 pc-baim kernel: [845121.897552] [TonyBai]-FilterInput:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=172.17.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=44120 WINDOW=28960 RES=0x00 ACK SYN URGP=0

host再回复ack，与sync相同，走filter output链，不赘述。

Jan 14 14:19:25 pc-baim kernel: [845121.897588] [TonyBai]-FilterOutput:IN= OUT=docker0 SRC=172.17.0.1 DST=172.17.0.2 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=51757 DF PROTO=TCP SPT=44120 DPT=12580 WINDOW=229 RES=0x00 ACK URGP=0

5、container to 10.10.126.187

场景：我们在container1中向与宿主机直接网络的主机10.10.126.187建立连接。我在container1中执 行：telnet 10.10.126.187 12580。187上启动服务程序在监听12580端口，因此这是个标准tcp连接建立过程（sync, ack sync, ack）。

分析：

container1视角：将sync包发个目的地址10.10.126.187，根据路由选择，从默认路由走，下一跳为Gateway，即 172.17.0.1。消息发到docker0。

切换到host视角：host从docker0网卡收到一个sync包，目的地址是10.10.126.187，进入到iptables：

Jan 14 14:47:17 pc-baim kernel: [846795.243863] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=34160 DF PROTO=TCP SPT=55148 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

路由选择后，匹配到host的直连网络路由(10.10.126.0/24 via eth0)，包将从eth0出去，于是docker0转发到eth0，走foward chain：

Jan 14 14:47:17 pc-baim kernel: [846795.243931] [TonyBai]-FwdId0Ond0:IN=docker0 OUT=eth0 PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34160 DF PROTO=TCP SPT=55148 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

出forward chain后，匹配到nat表的postrouting链，做Masquerade(SNAT)。将源地址从172.0.0.2换为 10.10.126.101再发出去。

Jan 14 14:47:17 pc-baim kernel: [846795.243940] [TonyBai]-NatPostRouting:IN= OUT=eth0 PHYSIN=vethd9f6465 SRC=172.17.0.2 DST=10.10.126.187 LEN=60 TOS=0x10 PREC=0x00 TTL=63 ID=34160 DF PROTO=TCP SPT=55148 DPT=12580 WINDOW=29200 RES=0x00 SYN URGP=0

10.10.126.187收到后，回复ack sync。由于10.10.126.187上增加了172.17.0.0/16的路由，gateway为10.10.126.101，因此ack sync被回送给宿主机，host会从187收到ack sync包。

Jan 14 14:47:17 pc-baim kernel: [846795.244155] [TonyBai]-RawPrerouting:IN=eth0 OUT= MAC=2c:59:e5:01:98:28:00:19:bb:5e:0a:86:08:00 SRC=10.10.126.187 DST=10.10.126.101 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=55148 WINDOW=5792 RES=0x00 ACK SYN URGP=0

进入iptables时，目的地址还是10.10.126.101，进入路由选择前iptables会将10.10.126.101换成 172.17.0.2（由于之间在natpostrouting做了masquerade）。这样后续路由的目的地址为docker0，需要由 eth0转到docker0，走 forward链。由于是RELATED, ESTABLISHED 连接，因此匹配到FwdOd0:

Jan 14 14:47:17 pc-baim kernel: [846795.244182] [TonyBai]-FwdOd0:IN=eth0 OUT=docker0 MAC=2c:59:e5:01:98:28:00:19:bb:5e:0a:86:08:00 SRC=10.10.126.187 DST=172.17.0.2 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=12580 DPT=55148 WINDOW=5792 RES=0x00 ACK SYN URGP=0

切换到container1视角。收到ack sync后，回复ack，同sync流程，不赘述：

Jan 14 14:47:17 pc-baim kernel: [846795.244249] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=34161 DF PROTO=TCP SPT=55148 DPT=12580 WINDOW=229 RES=0x00 ACK URGP=0
Jan 14 14:47:17 pc-baim kernel: [846795.244266] [TonyBai]-FwdId0Ond0:IN=docker0 OUT=eth0 PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=52 TOS=0x10 PREC=0x00 TTL=63 ID=34161 DF PROTO=TCP SPT=55148 DPT=12580 WINDOW=229 RES=0x00 ACK URGP=0

不用再走一遍natpostrouting，属于一个流的包只会 经过这个表一次。如果第一个包被允许做NAT或Masqueraded，那么余下的包都会自 动地被做 相同的操作。也就是说,余下的包不会再通过这个表一个一个的被NAT，而是自动地完成。

6、10.10.126.187 to container

场景：我们在10.10.126.187向container1建立连接。我在187中执行：telnet 172.17.0.2 12580。container1上启动服务程序在监听12580端口，因此这是个标准tcp连接建立过程（sync, ack sync, ack）。

分析：

由于187上增加了container1的路由，187将sync包发到gateway 10.10.126.101。

宿主机视角：从eth0收到目的地址为172.17.0.2的sync包，到达iptables：

Jan 14 15:06:08 pc-baim kernel: [847926.218791] [TonyBai]-RawPrerouting:IN=eth0 OUT= MAC=2c:59:e5:01:98:28:00:19:bb:5e:0a:86:08:00 SRC=10.10.126.187 DST=172.17.0.2 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=48735 DF PROTO=TCP SPT=53225 DPT=12580 WINDOW=5840 RES=0x00 SYN URGP=0

路由后应该通过docker0发到直连网络。应该走Forward链，但由于上面的log没有覆盖到，只是匹配到DOCKER chain，没有匹配到可以log的rules，没有打印出来log。

docker0将sync发给container1，container1回复ack sync。消息报目的地址187，走gateway，即docker0。

再回到主机视角，host从docker0网卡收到ack sync包，目的187，因此路由后，走直连网络转发口eth0。iptables中走forward chain：FwdId0Ond0:

Jan 14 15:06:08 pc-baim kernel: [847926.219010] [TonyBai]-RawPrerouting:IN=docker0 OUT= PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=12580 DPT=53225 WINDOW=28960 RES=0x00 ACK SYN URGP=0
Jan 14 15:06:08 pc-baim kernel: [847926.219103] [TonyBai]-FwdId0Ond0:IN=docker0 OUT=eth0 PHYSIN=vethd9f6465 MAC=02:42:f9:f8:c9:ad:02:42:ac:11:00:02:08:00 SRC=172.17.0.2 DST=10.10.126.187 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=12580 DPT=53225 WINDOW=28960 RES=0x00 ACK SYN URGP=0

注意这块是已经建立的连接，双方都知道对方的地址了（187上配置了172.17.0.2的路由），因此并没有走nat postroutiing chain，没有SNAT转换地址。

187收到后，回复ack。这个过程重复sync过程，但forward链可以匹配到FwdOd0：

Jan 14 15:06:08 pc-baim kernel: [847926.219417] [TonyBai]-RawPrerouting:IN=eth0 OUT= MAC=2c:59:e5:01:98:28:00:19:bb:5e:0a:86:08:00 SRC=10.10.126.187 DST=172.17.0.2 LEN=52 TOS=0x10 PREC=0x00 TTL=64 ID=48736 DF PROTO=TCP SPT=53225 DPT=12580 WINDOW=92 RES=0x00 ACK URGP=0
Jan 14 15:06:08 pc-baim kernel: [847926.219477] [TonyBai]-FwdOd0:IN=eth0 OUT=docker0 MAC=2c:59:e5:01:98:28:00:19:bb:5e:0a:86:08:00 SRC=10.10.126.187 DST=172.17.0.2 LEN=52 TOS=0x10 PREC=0x00 TTL=63 ID=48736 DF PROTO=TCP SPT=53225 DPT=12580 WINDOW=92 RES=0x00 ACK URGP=0

八、容器网络性能测量

这里顺便对容器网络性能做一个初步的测量，测量可以考虑使用传统工具：netperf，其服务端为netserver，会同netperf一并安装到主机中。但前些时候发现了一款显示结果更直观的用go实现的工具：sparkyfish。这里我打算用这个新工具来粗粗的测量一下容器网络的性能。

由于sparkyfish会执行upload和download场景，因此server放在哪个位置均可。

我们执行两个场景，对比host和container的网络性能：

1、与同局域网的一个主机通信

我们在一台与host在同一局域网的主机(105.71)上启动sparkyfish-server，然后分别在host和container上执行sparkyfish-cli 10.10.105.71，结果截图如下：

host to 105.71

container to 105.71

对比发现：container、host到外部网络的度量值差不多，avg值几乎相同。

2、container to host and container

我们在host和另一个container2上分别启动一个sparkyfish-server，然后在container1上执行分别执行sparkyfish-cli 10.10.126.101和sparkyfish-cli 172.17.0.3，结果截图如下：

container to host

container to container

对比可以看出：container to container的出入网络性能均仅为container to host的网络性能的三分之一不到。

九、小结

以上粗略理解了docker单机容器网络，有些地方理解难免有偏颇，甚至是错误，欢迎指正。
Docker技术虽然成长迅猛，前景广阔，但Docker也非银弹，深入之处必然有坑。填坑之路虽然痛苦，但能有所收获也算是很好了。

虽然前一篇Blog宣称自己要用Markdown开始写Post，但实际操作起来还是发现了诸多不兼容问题(插件与主题间、插件与插件间的)，让编写和修改文章变得十分繁琐，于是我研究了一下静态Web站点生成工具Hugo。Hugo是由前Docker的重量级员工(2015年8月末从Docker离职)：Steve Francia实现的一个开源静态站点生成工具框架，类似于Jekyll、Octopress或Hexo，都是将特定格式(最常见的是Markdown格式)的文本文件转换为静态html文件而生成一个静态站点，多用于个人Blog站点、项目文档(Docker的官方manual Site就是用Hugo生成的)、初创公司站点等。这类工具越来越多的受到程序员等颇具“极客”精神的群体的欢迎，结合github.com等版本控制服务，采用具有简单语法格式但强大表达力的Markdown标记语言，人们可以在很短时间内就构建出一个符合自己需求的静态Web站点。在这些工具中，Hugo算是后起之秀了，它最大的优点就是Fast! 一个中等规模的站点在几分之一秒内就可以生成出来。其次是良好的跨平台特性、配置简单、使用方便等。这一切均源于其良好的基因：采用Go语言实现。Steve Francia除了Hugo平台自身外，还维护了一个Hugo Theme的Repo，这个Hugo主题库可以帮助Hugo使用者快速找到自己心仪的主题并快速搭建起静态站点。目前国内使用Hugo的人还不多，但感觉其趋势是在逐渐增多。这里写下这篇Post，也算是为大家入个门，引个路吧。

一、安装Hugo

Hugo托管在github.com上，因此获取Hugo很方面，目前有至少两种方法可以安装Hugo。

1、安装包

对于普通用户（无git、无开发经验）而言，直接下载安装包是最简单的方式。我们可以下载Hugo的Release版，截至目前为止最新版本是v0.14，可以在这里下载你的平台(支持linux, windows, darwin, netbsd, freebsd和arm等)对应的版本。不过我发现0.14版本似乎有Bug，在我的MacOsX上生成Hugo Docs站点总是panic。

2、源码编译

对于开发者而言，源码编译是最Geek的方式:

go get -u -v github.com/spf13/hugo
go build -o hugo main.go
mv hugo $GOPATH/bin

在命令行下执行hugo命令，如果得到类似下面结果，则说明你已经成功安装了Hugo：

$hugo version
Hugo Static Site Generator v0.15-DEV BuildDate: 2015-09-20T23:53:39+08:00

二、生成静态站点

1、创建静态站点

我们来创建一个名为”tonybai.com”的静态站点：

$hugo new site tonybai.com
$tree
.
└── tonybai.com
    ├── archetypes
    ├── config.toml
    ├── content
    ├── data
    ├── layouts
    └── static

我们看到，通过hugo new site命令，我们建立了tonybai.com站点的后台目录结构。但细心的你会发现：这里的目录都是空的。除了config.toml中可怜的三行内容：

baseurl = "http://replace-this-with-your-hugo-site.com/"
languageCode = "en-us"
title = "My New Hugo Site"

不过即便目录为空，这也是一个完整的静态站点源文件，我们可以基于这些文件生成我们的站点。

$cd tonybai.com
$hugo server

0 draft content
0 future content
0 pages created
0 paginator pages created
0 tags created
0 categories created
in 6 ms
Serving pages from /Users/tony/test/hugotest/tonybai.com/public
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

上面的hugo命令在将repo转换为静态Site文件放入public目录：

├── public
│   ├── 404.html
│   ├── index.html
│   ├── index.xml
│   └── sitemap.xml

之后Hugo启动了一个server作为该Site的Web Server。通过浏览器访问http://localhost:1313，你将看到一个完全空白的站点首页。虽然这个站点没啥实用价值（一片空白），但这却是一个良好的起点。

2、添加Theme

添加了Theme后的站点才有血有肉，丰富多彩。

添加Theme的步骤如下，我们以Hyde Theme为例：

首先创建themes目录，并下载Hyde Theme文件：

$ mkdir themes
$ cd themes
$ git clone https://github.com/spf13/hyde.git

接下来，我们需要对Site进行一些配置，tonybai.com/config.toml是Site的顶层配置文件，配置后的config.toml文件如下：

baseurl = "http://tonybai.com/"
languageCode = "en-us"
title = "Tony Bai"
theme = "hyde"

[params]
    description = "这里是Tony Bai的个人博客"
    themeColor = "theme-base-08" # for hyde theme

其中：
theme = “hyde” 指定站点使用Hyde主题；
themeColor = “theme-base-08″ 指定了站点的主题颜色（默认是黑色的，这里改成一种红色）

在tonybai.com目录下重新执行hugo server，并打开浏览器查看站点首页，你会发现视野里有内容了：

3、第一个Post

结构和样式有了，我们还没有内容。我们来创建站点的第一个Post：

$hugo new welcome.md
/Users/tony/Test/hugotest/tonybai.com/content/welcome.md created

hugo在content下创建welcome.md文件，我们编写一些文件内容：

+++
Categories = ["Development", "GoLang"]
Description = ""
Tags = ["Development", "golang"]
date = "2015-09-23T16:30:37+08:00"
menu = "main"
title = "你好，Hugo"

+++

这是使用Hugo创建的站点中的第一篇文章。

保存后，重新执行hugo server命令，打开浏览器，你将看到下面的情形：

至此，如果你是极简主义者，你对其他没有任何要求，你就可以用这个站点写Post了。

三、调试与部署站点

1、调试站点

采用Hugo的静态站点在编辑文章、调试站点时十分方便，你要做的就是编辑文本，保存后，打开浏览器看渲染后的结果。不过反复执行hugo server命令还是有些烦，hugo早想到了这一点，hugo提供了:
-w, --watch[=false]

执行hugo server命令时加上-w选项，hugo就可以自动检测本地站点文件的变更，并自动执行md -> html转换。这样刷新浏览器页面就可以看到你修改后的结果了：

$hugo server -w
0 draft content
0 future content
1 pages created
0 paginator pages created
2 tags created
2 categories created
in 16 ms
Watching for changes in /Users/tony/test/hugotest/tonybai.com/{data,content,layouts,static,themes/hyde}
Serving pages from /Users/tony/test/hugotest/tonybai.com/public
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

通过hugo server -w的输出日志来看，hugo可以自动检测data,content,layouts,static,themes/hyde目录下的变更，但站点顶层config.toml的改动无法被检测，还需要重启hugo server。

2、部署站点

和Jekyll类似，使用hugo的静态站点可以部署到github page中，不过这里不详细描述这种方法，可以看官方文档

如果是在vps下部署，那么hugo转换后的public文件夹可以被直接用于部署到像nginx、apache、caddy这样的Web Server下面。

当然hugo本身也可以作为一个Web server来支撑你的静态站点，就像上面提到的，你可以在你的站点目录(比如上面的”tonybai.com”)下执行：

$sudo hugo server --bind="0.0.0.0" -v -w -p 80 -b http://tonybai.com

如果无法使用80端口（比如通过apache2反向代理），那么需要加上–appendPort=false，否则转换后的public下面的url地址都会带上你的hugo端口（1313）：

$hugo server -v -w -p 1313 -b http://tonybai.com --appendPort=false

四、配置和维护站点

大多数人不会止步于上面那个仅仅能写Post的站点，配置分类、标签；修改字体样式；添加评论功能；增加统计代码；增加代码高亮(程序员最爱)；甚至定制主题是Geek们最喜欢折腾的事情，这里无法全表，列举几个常见的配置和维护方法，还是已hyde主题为例。

1、配置分类、标签

在浏览器中输入：http://localhost:1313/categories/或http://localhost:1313/tags，你会看到站点输出了一个类似目录列表似的页面：

development/
golang/

development和golang从何而来呢？

隐藏得再深，也要给它揪出来：

tonybai.com/themes/hyde/archetypes/default.md

+++
Description = ""
Tags = ["Development", "golang"]
Categories = ["Development", "GoLang"]
menu = "main"
+++

由于我们使用了hyde theme，所以我们只需看themes/hyde下面的目录结构即可，tonybai.com下面的除content之外的其他layout, data等可忽略不计。在hyde/archetypes下存放着这个主题下文章的默认分类和tags集合。这个default的作用是每次new post后，hugo会将default中的tags和categories自动copy到Post头中的tags和categories中。

每个Post的分类和tag在post自身的.md文件头中指定，见Categories和Tags两个配置项：

tonybai.com/content/welcome.md

+++
Categories = ["Development", "GoLang"]
Description = ""
Tags = ["Development", "golang"]
date = "2015-09-23T16:30:37+08:00"
menu = "main"
title = "你好，Hugo"

+++

你可以根据需要在你的post md文件中灵活增删你的tags和categories，不局限于default.md中的那些已知项。

2、修改字体样式

hyde主题的字体样式在tonybai.com/themes/hyde/layouts/partials/head.html中指定：

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">

由于googleapis在国内无法访问，因此要么注释掉这行（使用浏览器默认字体样式），要么将其换为其他字体公共服务，比如：

<link rel="stylesheet" href="http://fonts.useso.com/css?family=PT+Sans:400,400italic,700|Abril+Fatface">

字体的设置在tonybai.com/themes/hyde/static/css下的各个css文件中，谨慎调整。

3、添加评论功能

Hugo没有内置评论功能，要增加评论功能需要集成第三方评论服务，比如国外最流行的Disqus。hyde主题内置了disqus评论插件，不过需要你按如下操作配置一下，否则页面下方的disqus插件总是显示无法连接。

获取disqusShortname

这里用disqus主账号不行，需要用主账号login后：add a newsite to disqus，比如加入tonybaicom.disqus.com，这样你的disqusShortname就为：tonybaicom；

配置disqusShortname

在tonybai.com/config.toml中配置disqusShortname:

[params]
    disqusShortname = "tonybaicom"

如果你要使用国内的评论服务，比如：多说，你可以参考tonybai.com/themes/hyde/layouts/partials/disqus.html，用多说提供的install code替换disqus的code，形成duoshuo.html：

<!-- 多说评论框 start -->
<div class="ds-thread" data-thread-key="{{ .URL }}" data-title="{{ .Title }}" data-url="{{ .Permalink }}"></div>
<!-- 多说评论框 end -->

<!-- 多说公共JS代码 start (一个网页只需插入一次) -->
<script type="text/javascript">
    var duoshuoQuery = {short_name:"{{.Site.Params.duoshuoShortname}}"};

    (function() {
     var ds = document.createElement('script');
     ds.type = 'text/javascript';ds.async = true;
     ds.src = (document.location.protocol == 'https:' ? 'https:' : 'http:') + '//static.duoshuo.com/embed.js';
     ds.charset = 'UTF-8';
     (document.getElementsByTagName('head')[0]
      || document.getElementsByTagName('body')[0]).appendChild(ds);
     })();
    </script>
<!-- 多说公共JS代码 end -->

再在tonybai.com/themes/hyde/layouts/_default/single.html中替换下面的代码：

{{ if and (isset .Site.Params "disqusShortname") (ne .Site.Params.disqusShortname "") }}
                <h2>Comments</h2>
                {{ partial "disqus" . }}
            {{ end }}

为类似下面的代码：

{{ if and (isset .Site.Params "duoshuoShortname") (ne .Site.Params.duoshuoShortname"") }}
                <h2>Comments</h2>
                {{ partial "duoshuo" . }}
            {{ end }}

注意：一旦用上面多说代码，config.toml中就需要配置duoshuoShortname了：

[params]
    duoshuoShortname = "tonybaicom"

4、代码高亮

Hugo官方说明中采用Pygments来进行代码高亮的支持，在部署机上安装Pygments，个人觉得这个方法不好。于是换另一外一种js代码法，即采用highlightjs的方法支持代码高亮。

highlightjs同样很强大，支持135种语言（关键是支持Golang）和60多种样式（有我喜爱的github样式和monokai_sublime样式），但不支持linenumber。

我们首先将highlightjs下载到本地:

tonybai.com/themes/hyde/static/css/highlight.js/8.8.0/styles/github.min.css
tonybai.com/themes/hyde/static/js/highlight.js/8.8.0/highlight.min.js

然后在tonybai.com/themes/hyde/layouts/partials/head.html添加如下代码:

    <!-- Highlight.js and css -->
    <script src="{{ .Site.BaseURL }}js/highlight.js/8.8.0/highlight.min.js"></script>
    <link rel="stylesheet" href="{{ .Site.BaseURL }}css/highlight.js/8.8.0/styles/github.min.css">
    <script>hljs.initHighlightingOnLoad();</script>

highlightjs会自动检测语言类型，并使用github样式。

5、统计代码

提供统计服务的站点，比如statcounter.com一般都会提供安装代码（js）的，将那段代码copy到tonybai.com/themes/hyde/layouts/partials/head.html中即可。

四、进阶

1、index.html、single.html和list.html

站点的首页模板在themes/hyde/layouts/index.html中。除首页外，其他Post或叫Page，都被Hugo抽象为两类：单体页面和列表页面，对应这两种页面的默认模板都在themes/hyde/layouts/_default中，分别对应着single.html和list.html。

我们之前通过hugo new welcome.md创建的Post使用的是single.html模板，而查看tags或categories的页面默认采用的是list.html，比如查看tonybai.com/categories/golang，你会在浏览器中看到分类在golang这一类的所有Post列表。

2、type和section

我们执行如下两个命令：

$hugo new post/firstpost.md
tonybai.com/content/post/firstpost.md created
$hugo new post/secondpost.md
tonybai.com/content/post/secondpost.md created

创建后我们可以看到站点的源文件结构变成了：

... ...
├── archetypes
├── config.toml
├── content
│   ├── post
│   │   ├── firstpost.md
│   │   └── secondpost.md
│   └── welcome.md
... ...

hugo中源码文件的布局影响着最终生成的html文件的结构布局。有些时候我们的站点可能会分成若干个部分，每部分通过目录隔离开，比如这里content下的post目录，这样hugo转换后，firstpost.html和secondpost.html也会在public的post目录下。这里的“post”被称为一个section。

hugo会为每个section自动生成index.html页，采用的是index.html模板。

至于是否采用的是hyde/layouts/_default下的list.html，这要看host的匹配order，官方给出的是：

/layouts/section/SECTION.html
/layouts/_default/section.html
/layouts/_default/list.html
/themes/THEME/layouts/section/SECTION.html
/themes/THEME/layouts/_default/section.html
/themes/THEME/layouts/_default/list.html

这个例子中THEME=hyde, SECTION=post

在本例子中，/layouts/下是空的，不予考虑。/themes/hyde/layouts下没有建立section/post.html模板，/themes/hyde/layouts/_default/section.html也不存在，因此用的是_default/list.html。

hugo官方建议静态站点源码文件按section组织，每个section使用相应(同名）的type，这样section下面的.md就会自动使用响应type的meta data。

当我们hugo new post/firstpost.md时，hugo会到archetypes下找是否有post.md文件，如果有则使用post.md文件的categories和tags来初始化content/post/firstpost.md的元数据，如果没有post.md，则使用archetypes/default.md的。

3、模板语言

Hugo使用Golang的模板语法，表达能力很强大；配合Hugo predefined的变量或自定义变量，你可以玩转模板。关于模板内容较多，这里不赘述，需要时查看官方详细的manual。