快速理解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

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2015-08-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

微服务相关技术概览

今天给大家走马观花的聊一下微服务相关的热门技术。 ? 如果问什么是微服务?那就很难回答了,而且容易引起争论,因为微服务不是一个技术定义;如果问微服务是什么?具备...

3798
来自专栏大魏分享(微信公众号:david-share)

从通过微信登录今日头条,看API的身份认证与授权 | API Management学习第六终结篇

API的计量与限速 | 将一个Web API纳入API管理 |API Management学习第二篇

1123
来自专栏后端技术探索

Uber工程技术栈(二):看曾经的独角兽背后用了哪些技术

我们的服务彼此交互,还与移动设备进行交互,而那些交互对业务状况(比如动态定价)和内部使用(比如调试)来说都很重要。就日志而言,我们使用了多个Kafka集群,数据...

614
来自专栏Rainbond开源「容器云平台」

视频 | Rainbond与Service mesh微服务架构

一体化架构为何遭遇强拆?开发语言为何自由选择?资源利用率为何大幅提高?微服务架构插件体系,应该怎样结合?独立部署、升级、替换、伸缩的微服务,运维应该是喜是忧?管...

3108
来自专栏CSDN技术头条

架构物联网:一种新的解决方案

本文将通过对几个项目的介绍,让读者完全了解并掌握如何架构物联网。 几周前我们在捷克的Linux大会“OpenAlt”上提出了这样的观点:物联网(IoT)是基于微...

1969
来自专栏数据和云

静默错误:为什么看了那么多灾难,还是过不好备份这一关?

可是毕竟广告好不好,还要看疗效,9个9的可靠性,你也永远无法论证你不是那 0.00000001%。

1081
来自专栏喔家ArchiSelf

智能家居系统的开源尝试

随着智能音箱的热卖,各种各样的智能家庭解决方案也如雨后春笋,但大多数都需要专业人员和熟练工作人员来安装/部署这些解决方案。此外,这些解决方案大多无法顺利融入已有...

634
来自专栏前沿技墅

微服务框架全家福【多语言版】

1765
来自专栏纯洁的微笑

为什么我会被 Kubernetes “洗脑”?

1054
来自专栏韩伟的专栏

互联网开发模式三:持续集成与DevOps

持续集成的意义和实践 不管是敏捷开发的快速迭代,还是重构系统,我们都将频繁的编译代码、部署、测试,也就是所谓的集成。如果我们的系统集成效率太低,那么快速的迭代可...

3356

扫描关注云+社区