介绍

Docker容器是将应用与其依赖的库打包成一个独立的运行环境(本质上就是一个目录和运行时的一些库文件)，利用Linux内核的namespace可以将这个应用直接运行在Linux主机内核上，并与主机的网络与存储隔离运行，资源利用率接近于Linux原生进程，比虚拟机高。有利于解决应用的环境依赖问题，方便应用的开发部署。

应用场景

• 适合于需要经常部署的模块，良好的封装会让持续部署变得方便。
• 适合于无状态服务，迁移、重部署、水平扩展都很方便。
• 还很适合于测试环境，因为封装良好，做各种场景模拟测试和压力测试都很方便。

Docker希望应用尽量无状态、可重新部署、可水平扩展，如果应用比较传统可能需要调整。

与VM的一个最直观的区别是，docker上只能运行Linux系统上的应用，因为它是在Linux内核的基础上构建，是一个应用。而VM是在硬件层次进行虚拟化，可以运行不同的操作系统，是一种基础设施。

基本概念

• image: 已经打包的应用镜像，docker可以直接通过他生成一个运行实例
• container: image的一个运行实例
• registry: image仓库，负责image索引、存储、分发。

一般的流程是docker 从hub.docker.com(registry)拉取(pull)应用镜像(image), 并利用这些镜像生成container

架构

C/S架构

• docker: C端负责image的制作管理、container启停。
• docker-daemon: S端负责container的正常运行。

四种网络模式

四种网络模式摘自 Docker网络详解及 pipework源码解读与实践

docker run 创建 Docker 容器时，可以用 --net 选项指定容器的网络模式，Docker 有以下 4 种网络模式：

• host 模式，使用 --net=host 指定。
• container 模式，使用 --net=container:NAMEorID 指定。
• none 模式，使用 --net=none 指定。
• bridge 模式，使用 --net=bridge 指定，默认设置。

host 模式

如果启动容器的时候使用 host 模式，那么这个容器将不会获得一个独立的 Network Namespace，而是和宿主机共用一个 Network Namespace。容器将不会虚拟出自己的网卡，配置自己的 IP 等，而是使用宿主机的 IP 和端口。

例如，我们在 10.10.101.105/24 的机器上用 host 模式启动一个含有 web 应用的 Docker 容器，监听 tcp 80 端口。当我们在容器中执行任何类似 ifconfig 命令查看网络环境时，看到的都是宿主机上的信息。而外界访问容器中的应用，则直接使用 10.10.101.105:80 即可，不用任何 NAT 转换，就如直接跑在宿主机中一样。但是，容器的其他方面，如文件系统、进程列表等还是和宿主机隔离的。

container 模式

这个模式指定新创建的容器和已经存在的一个容器共享一个 Network Namespace，而不是和宿主机共享。新创建的容器不会创建自己的网卡，配置自己的 IP，而是和一个指定的容器共享 IP、端口范围等。同样，两个容器除了网络方面，其他的如文件系统、进程列表等还是隔离的。两个容器的进程可以通过 lo 网卡设备通信。

none 模式

这个模式和前两个不同。在这种模式下，Docker 容器拥有自己的 Network Namespace，但是，并不为 Docker容器进行任何网络配置。也就是说，这个 Docker 容器没有网卡、IP、路由等信息。需要我们自己为 Docker 容器添加网卡、配置 IP 等。

bridge模式

bridge 模式是 Docker 默认的网络设置，此模式会为每一个容器分配 Network Namespace、设置 IP 等，并将一个主机上的 Docker 容器连接到一个虚拟网桥上。当 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 的，可以认为它是网桥的管理接口，在宿主机上作为一块虚拟网卡使用）

docker 底层技术

docker是lxc的管理器，lxc是cgroup的管理工具，cgroup是namespace的用户空间的管理接口。namespace是linux内核在task_struct中对进程组管理的基础机制。

再详细点说：
docker是用go来实现的，自动化了对lxc的管理过程，能够自动在线下载相应的发行版本的rootfs。
lxc可以直接chroot到任意的系统的rootfs上并通过cgroup的限制机制来控制容器内系统的资源占有率。
cgroup通过配置文件或者命令配置后，限制相应进程或一组进程使用的系统资源。
很明显，在lxc以上已经借助于chroot机制在一个限制的容器中运行一个完整的系统了，这样多个不通过虚拟化技术的新系统就在特定的占有物理资源的限制上运行起来。据说运行效率直逼实际机器。

Linux namespace

Linux Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。因此在操作系统层面上看，就会出现多个相同pid的进程。系统中可以同时存在两个进程号为0,1,2的进程，由于属于不同的namespace，所以它们之间并不冲突。而在用户层面上只能看到属于用户自己namespace下的资源，例如使用ps命令只能列出自己namespace下的进程。这样每个namespace看上去就像一个单独的Linux系统。

资源配额Cgroups（control group）

cgroups 实现了对资源的配额和度量。 cgroups 的使用非常简单，提供类似文件的接口，在 /cgroup 目录下新建一个文件夹即可新建一个 group，在此文件夹中新建 task 文件，并将 pid 写入该文件，即可实现对该进程的资源控制。具体的资源配置选项可以在该文件夹中新建子 subsystem ，{子系统前缀}.{资源项} 是典型的配置方法， 如 memory.usageinbytes 就定义了该 group 在 subsystem memory 中的一个内存限制选项。 另外，cgroups 中的 subsystem 可以随意组合，一个 subsystem 可以在不同的 group 中，也可以一个 group 包含多个 subsystem - 也就是说一个 subsystem。

• memory
  内存相关的限制
• cpu
  在 cgroup 中，并不能像硬件虚拟化方案一样能够定义 CPU 能力，但是能够定义 CPU 轮转的优先级，因此具有较高 CPU 优先级的进程会更可能得到 CPU 运算。 通过将参数写入 cpu.shares ,即可定义改 cgroup 的 CPU 优先级 - 这里是一个相对权重，而非绝对值
• blkio
  block IO 相关的统计和限制，byte/operation 统计和限制 (IOPS 等)，读写速度限制等，但是这里主要统计的都是同步 IO
• devices
  设备权限限制

POC测试结果

参与Dockers POC一共两家公司，Rancher, 数人云，目标是测试大数据在Docker上的应用，在与两家进行详细交流之后发现，Docker伸缩特性更适合于计算密集型的应用，而hadoop生态下的应用更多的是计算向数据移动的，无法发挥Docker的特性。故最后的目标定在Docker在大数据应用的可用性上，并不进行性能与可靠性测试。
我们挑选了大数据中几个经典的场景进行测试：
1. MongoDB: 计算与数据紧密结合类型应用
2. Storm：纯计算类型应用
3. Spark：因为数人云的系统结构中整合了Mesos，故想测试Spark on Mesos是否更有优势。

MongoDB on Docker

• 部署方式
  ReplicatSet:1 Master, 2 Slaver
• 测试工具包: YCSB github
  YCSB: 50% read 50% write
• 测试结果

• 结论

       两个系统部署的MongoDB集群均可以稳定运行，测试结果其实基本上都是依赖于Docker， 故性能相差也不大。

Storm on Docker

• 部署方式：
  1 Nimbus, 3 Supervisor
• 测试工具包 storm-benchmark github
• 测试结果
  我们测试了SQL用例，并在计算过程中进行Supervisor个数伸缩测试，系统均可以正常运行。
• 结论
  这种模式下并不依赖各个系统特性，仅是docker功能上的测试，两个系统均可以正常管理集群，计算中集群状态正常。

Spark on Docker

• 部署方式：
  standalone模式
  1 Master, 3 Slave
• 测试工具包
  Pi Estatmation
• 测试结果
  standalone模式下对两个系统部署方法一致，均可以正常计算

结论

共同点

两个系统均可以通过前端(Web)界面对集群进行动态伸缩扩展, 达到对docker集群管理的功能。

Rancher

• 面向集群的管理，使用一个独立开发的docker调度平台cattle,
• 系统界面全英文，可以通过预计定义的应用拓扑直接启动一个应用docker集群，可以通过脚本定义集群的生成方式。
• 所有的docker构成一个独立的虚拟网络，docker之间没有网络隔离。

Dataman

• 直接对镜像进行操作，首先做好应用中每个角色的镜像，然后通过其系统直接将每个镜像分配到物理机器上启动，调度的算法是在Mesos制作一个FrameWork，利用Mesos进行资源的分配，当然也可以通过对物理机器打上标签手动控制docker镜像启动的机器。
• 面向镜像,调度的单位是一个个预先制做好的镜像。