快速理解docker

技术源头

简单的说Docker是一个构建在LXC之上的,基于进程容器(Processcontainer)的轻量级VM解决方案，Docker container和普通的虚拟机Image相比, 最大的区别是它并不包含操作系统内核。因此非常轻量。

 

普通虚拟机将整个操作系统运行在虚拟的硬件平台上, 进而提供完整的运行环境供应用程序运行, 而Docker则直接在宿主平台上加载运行应用程序. 本质上他在底层使用LXC启动一个Linux Container,通过cgroup等机制对不同的container内运行的应用程序进行隔离,权限管理和quota分配等，每个container拥有自己独立的各种命名空间(亦即资源)包括:PID 进程, MNT 文件系统, NET 网络, IPC , UTS 主机名 等。

 

Build,Ship,Run

 

LXC(linux container)已经出来很多年了，一直不温不火，docker为啥突然这么火？Docker引入了ship（发布）这个重要概念，打通了build，ship，run这一套软件开发流程。使软件开发、发布，运行变得简单，契合当前时髦的DeveOps的理念。

 

从技术角度看，基本上你可以认为目前的Docker是LXC的一个高级封装,提供了各种辅助工具和标准接口方便你使用LXC,你可以依靠LXC和各种脚本实现与docker类似的功能，就像你不使用APT/yum等工具也可以自己搞定软件包安装一样，你使用他们的关键原因是方便易用！实际使用中，你一般不用关心底层LXC的细节,同时也不排将来docker实现基于非LXC方案的可能性在LXC的基础上, Docker额外提供的Feature包括：标准统一的打包部署运行方案， 历史版本控制， Image的重用，Image共享发布等等。

 

什么阻碍docker的广泛应用

Docker理念非常好，当前技术也非常热门，但其实在实际产品中，真正用到docker的非常少。

安全问题，虚拟机的安全是经过验证的，这种轻量级的通过内存空间的隔离host OS非常容易被攻破，所以目前docker在公有云上的应用非常少。当能docker已经在这方面进行了很多改进，比如运行时的系统调用黑名单，围绕镜像的安全也引起了关注。

大型应用/复杂应用使用dockerfile基本是不可能的事情，由于他抽象层次太高，以至于不能应对复杂度的用例。

依赖大量的内核的新特性，而这些内核特性还远未成熟，在实际的使用过程中，常常出现稳定性问题。

虽然说这项技术还在成熟，总的来说，docker是一项非常有前景的技术。

docker生态系统

2013年是容器和周边技术高歌猛进的一年，这其中以Docker的流行为代表，以下两家公司和他们的产品具有标志意义。

• 2013年，Docker version 0.10：Docker是PaaS提供商dotCloud（最近已经正式改名为Docker Inc.）开源的一个基于LXC的高级容器引擎，源代码托管在GitHub上，基于Go语言并遵从Apache 2.0协议开源。Docker的出现极大简化了容器的创建和管理，分层式的AUFS实现了Docker镜像。

• 2013年，CoreOS：这家在硅谷某个车库里成立的创业公司发布了专门为大规模服务器部署定制的Linux精简系统，目的是为运行以轻量级容器为载体的应用提供一个高度优化的底层系统。

2014年，大量围绕Docker和CoreOS的创业公司、新近开源的软件项目、大型企业和互联网公司的加入，使轻量级容器技术的浪潮更上一层楼。

正如定义所言，Docker是“Container Engine”，它是一个把cgroup、namespace等容器底层技术抽象的一个引擎，为用户提供了创建和管理容器的便捷界面（包括命令行和API）。

概念明晰了，我们先从技术栈的维度来看Docker和它的生态系统，把从Linux到Docker做四个层面的分层。

• Linux操作系统。完整的Linux内核，履行操作的使命：管理硬件，调度任务，提供用户界面和服务等。

• 容器的内核实现。这主要包括Linux内核中的cgroup、namespace等，它们为容器（用户进程）的资源隔离性提供了内核层面的保障。

• 轻量级容器的基础工具。通过LXC这样的工具可以完成容器创建、启动等基本操作，但使用LXC需要熟知容器内核实现原理。这对于普通用户来说有一定难度，并且LXC在不同Linux发行版不一致。

• 容器管理引擎。Docker是这一层的主角。Docker由Docker engine和Docker client组成。Docker engine将神秘的cgroup、复杂的LXC统统隐藏起来，使用简单的命令即可完成容器的运行和管理。它的另一个独特之处在于AUFS的运用，Copy on write模式的分层文件系统使容器的镜像可以像搭积木一样灵活创建和修改，并在网络上实现增量分发。Docker client，特别是它的API，为在Docker之上的生态系统发展提供了可能性。

Docker的出现和标准化，为以轻量级容器为核心的生态系统提供了爆发式增长的机会。我们从以下几个角度来看Docker的生态系统。

Docker和容器宿主

前文提到的Docker Inc.和CoreOS已经赚足眼球，投资者接踵而至，大规模融资此起彼伏。企业级厂商如红帽、Ubuntu等不甘寂寞，纷纷亮明旗帜，选择站队。

6月在旧金山举行的DockerCon 2014展示了Docker对未来的雄心壮志。在Docker engine逐渐稳定并标准化的背景下，Docker的未来目标是为互联网基础架构制定新的标准。最近开源的libcontainer、libchan和libswarm三个项目，吹响了这场战役的冲锋号。

• 在新版本Docker engine中，由Go语言开发的libcontainer库已取代LXC。我认为，它更大的目的是反向定义容器的实现标准，将底层实现（也许可以完全不用cgroup甚至Linux）都抽象化到libcontainer的接口。

• libchan类库，以标准接口的方式解决容器的互联互通，实现跨平台，能更好支持分布式系统和并发编程。

• · libswarm是另一个很简单的类库，但它将实质性地推动互联网应用架构的创新。它抽象了应用部署和集群管理的细节，为应用程序赋予了跨云平台和互联网级弹性。

 

CoreOS的口号“A new way to think about servers”，这句话阐明了他们对改造互联网服务器的目标。CoreOS通过最小化的定制版Linux系统为容器运行提供载体。2014年8月14日，传来了CoreOS收购Quay.IO并推出CoreOS Enterprise Registry服务的新闻。显然，CoreOS并不满足于服务器层的工作，其目标定位在为企业用户提供完整的容器技术服务栈，提供管理大型容器集群的整体解决方案。在这个类别中生存的是标准定义者，它们是整个Docker生态系统的基础。

镜像存储和容器托管

这包括容器的镜像存储和CaaS（Container as a Service）类的容器运行托管，有代表性的公司是StackDock、Orchard、Tutum、Quay.IO、Baremetal.IO等。

这几家几乎全都是创业公司，他们围绕轻量级容器的整个生命周期来设计自己的产品，有的聚焦容器镜像描述文件（Dockerfile）向导化生成和构建过程的优化（如StackDock），有的提供包括SSD在内的高性能托管环境（如StackDock和Tutum），有的在监控和弹性扩展方面做足文章（如Tutum），也有像Baremetal.IO这样针对企业级整体解决方案的公司。

容器的镜像存储和运行托管是Docker生态体系中非常接近最终用户的一层。这个类别中的公司也许并没有高深莫测的技术，也不是标准的定义者，但通过它们与细分市场中客户的长期沟通合作，积累了大量Docker商用化的经验和实践。

基于Docker的微PaaS

镜像存储（静态）和容器托管（动态）都是以容器为单位的。下面我们将要讲述以应用为单位，以容器为底层技术实现的微PaaS。

这几年随着Microsoft Azure、Cloud Foundry的普及，PaaS的概念已经深入人心。传统意义上PaaS实例一般都与一个特定的IaaS平台绑定，提供部署接口、负载平衡、服务绑定等，然而Docker世界中产生的微PaaS，在此基础上进一步创新。这个领域比较有代表性的是Flynn和Deis.IO，它们都是开源项目。

Flynn分为Layer 0和Layer 1两层。Layer 0主要做底层硬件和云平台的抽象，分布式配置、任务调度、服务发现等基础工作，它为上层的容器运行环境提供了一个抽象的资源平台。Flynn可以快速部署在AWS上，今后也可扩展到其他公有云和私有云。Layer 1主要服务于应用，是PaaS功能的具体实现层，它提供了基本的管理API和客户端，实现了Git Receiver、Heroku Buildpacks、Routing和Datastore等PaaS核心功能。Layer 1本身和它所管理的应用，都以容器为载体。

Deis.IO，它的一个亮点是用CoreOS承担底层资源管理的任务。在部署Deis PaaS环境时，首先安装的Controller会创建一个CoreOS系统，然后在其之上以容器的方式运行Deis的所有组件。对CoreOS的支持是一个非常聪明的选择，目前CoreOS已可以运行在多个公有云平台、虚拟机和物理机环境下，这为Deis提供了与生俱来的跨云平台能力。

Flynn和Deis的共同特点，是对复杂和大规模分布式应用的原生支持。Heroku创始人Adam Wiggins曾发布著名的“十二要素应用宣言（The Twelve-Factor App）”，这个宣言定义了以服务方式和通过互联网交付的软件应该遵循的十二个要素。Flynn和Deis都是十二要素的忠实拥护者，它们的微PaaS平台与Heroku有极好的兼容性。

微PaaS创业公司层出不穷，竞争十分激烈，但也许走到最后的只是少数。在这一轮容器技术热潮中，微PaaS正在影响软件开发和运维流程，改变软件的交付方式，把十二要素类互联网应用架构标准化。

Orchestration、Management和Moni-t­oring

围绕Docker API做Web UI的门槛相对较低，受到了大家的追捧，这一类主要有DockerUI、Shipyard、maDocker等。它们无一例外都调用Docker API和其他类库，把对容器的管理和监控呈现在Web页面中，这在某种程度上降低了企业网管对这些新技术的恐惧。

这一领域有三个不得不提的高富帅项目：Google Kubernetes、Cloud Foundry的BOSH和Diego。

Kubernetes是构建在Docker之上的容器集群管理系统，Google在2014年6月将这个项目开源。它可以为用户提供跨平台的处理能力，不但能够在Google的基础架构中运行，同时可以访问其他的云计算服务器，如AWS，甚至是私有云。

这个系统一经开源，就得到了IBM、红帽、微软、Docker、Mesosphere、CoreOS和SaltStack等厂商的支持：微软将确保Kubernetes能够在其Azure云中作为基于Linux的虚拟机系统容器并正常运作；红帽则将其引入了自己的云产品；IBM的计划是为Kubernetes与Docker贡献代码；CoreOS将在其操作系统发行版中为Kubernetes提供支持；SaltStack正努力简化Kubernetes运行在其他环境下的部署流程；而Mesosphere则打算将这项技术加入到自己的Mesos同名开源项目当中。Google一呼百应的大将之风展露无遗。

Cloud Foundry的BOSH是部署和运维工具，它通过类似操作系统驱动程序的CPI（Cloud Provider Interface）来实现对多种异构云平台的支持和抽象，以近乎优雅的方式管理VM模板【注：在Cloud Foundry术语中称为干细胞（stemcell）】、软件发布（release）和部署配置脚本文件。最近BOSH推出了一个试验性质的项目BOSH Release for Docker。

Cloud Foundry在它的DEA（Droplet Execution Agent）中使用基于Warden的容器技术来做PaaS的应用隔离。最新的Diego（Go语言版DEA）项目目标是让Cloud Foundry在跨运行时环境方面更具有扩展性，这些运行时环境就包括Docker，也可能会原生支持Windows Server。

网络层的增强和解决方案

容器之间如何互联互通？Docker引擎中的内联网络能否满足企业级别网络的需求？当容器像今天的虚拟机一样在企业环境大规模部署时，复杂的网络需求如网络配置管理、安全监控、流量QoS、网络隔离等一定会出现。

在虚拟化的世界里，这些需求催生了庞大的网络虚拟化（SDN）产业，在容器的环境中，是否有同样的挑战和机会？在这个领域中，目前受关注较多的是Skydock和VNS3开源项目，但整体上还都处在萌芽起步阶段。

 

参考文献

http://www.csdn.net/article/2014-09-24/2821832/1