如何轻松玩转 Docker 容器技术？

　　欢迎各位阅读本篇,Docker 是 PaaS 提供商 dotCloud 开源的一个基于 LXC 的高级容器引擎，源代码托管在 Github 上, 基于 go语言并遵从Apache2.0协议开源。本篇文章讲述了如何轻松玩转 Docker 容器技术?

　　下面我们讨论容器如何与外部世界通信。这里涉及两个方向：

　　容器访问外部世界

　　外部世界访问容器

　　容器访问外部世界

　　在我们当前的实验环境下，docker host 是可以访问外网的。

　　我们看一下容器是否也能访问外网呢?

　　可见，容器默认就能访问外网。

　　请注意：这里外网指的是容器网络以外的网络环境，并非特指 internet。

　　现象很简单，但更重要的：我们应该理解现象下的本质。

　　在上面的例子中，busybox 位于 docker0 这个私有 bridge 网络中(172.17.0.0/16)，当 busybox 从容器向外 ping 时，数据包是怎样到达 bing.com 的呢?

　　这里的关键就是 NAT。我们查看一下 docker host 上的 iptables 规则：

　　在 NAT 表中，有这么一条规则：

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

　　其含义是：如果网桥 docker0 收到来自 172.17.0.0/16 网段的外出包，把它交给 MASQUERADE 处理。而 MASQUERADE 的处理方式是将包的源地址替换成 host 的地址发送出去，即做了一次网络地址转换(NAT)。

　　下面我们通过 tcpdump 查看地址是如何转换的。先查看 docker host 的路由表：

　　默认路由通过 enp0s3 发出去，所以我们要同时监控 enp0s3 和 docker0 上的 icmp(ping)数据包。

　　当 busybox ping bing.com 时，tcpdump 输出如下：

　　docker0 收到 busybox 的 ping 包，源地址为容器 IP 172.17.0.2，这没问题，交给 MASQUERADE 处理。这时，在 enp0s3 上我们看到了变化：

　　ping 包的源地址变成了 enp0s3 的 IP 10.0.2.15

　　这就是 iptable NAT 规则处理的结果，从而保证数据包能够到达外网。下面用一张图来说明这个过程：

　　busybox 发送 ping 包：172.17.0.2 > www.bing.com。

　　docker0 收到包，发现是发送到外网的，交给 NAT 处理。

　　NAT 将源地址换成 enp0s3 的 IP：10.0.2.15 > www.bing.com。

　　ping 包从 enp0s3 发送出去，到达 www.bing.com。

　　通过 NAT，docker 实现了容器对外网的访问。

　　分享：

　　Docker核心解决的问题是利用LXC来实现类似VM的功能，从而利用更加节省的硬件资源提供给用户更多的计算资源。

　　同VM的方式不同, LXC 其并不是一套硬件虚拟化方法 - 无法归属到全虚拟化、部分虚拟化和半虚拟化中的任意一个，而是一个操作系统级虚拟化方法, 理解起来可能并不像VM那样直观。所以我们从虚拟化到docker要解决的问题出发，看看他是怎么满足用户虚拟化需求的。

　　用户需要考虑虚拟化方法，尤其是硬件虚拟化方法，需要借助其解决的主要是以下4个问题:

　　隔离性 - 每个用户实例之间相互隔离, 互不影响。 硬件虚拟化方法给出的方法是VM, LXC给出的方法是container，更细一点是kernel namespace

　　可配额/可度量 - 每个用户实例可以按需提供其计算资源，所使用的资源可以被计量。硬件虚拟化方法因为虚拟了CPU, memory可以方便实现, LXC则主要是利用cgroups来控制资源

　　移动性 - 用户的实例可以很方便地复制、移动和重建。硬件虚拟化方法提供snapshot和image来实现，docker(主要)利用AUFS实现

　　安全性 - 这个话题比较大，这里强调是host主机的角度尽量保护container。硬件虚拟化的方法因为虚拟化的水平比较高，用户进程都是在KVM等虚拟机容器中翻译运行的, 然而对于LXC, 用户的进程是lxc-start进程的子进程, 只是在Kernel的namespace中隔离的, 因此需要一些kernel的patch来保证用户的运行环境不会受到来自host主机的恶意入侵, dotcloud(主要是)利用kernel grsec patch解决的.