您所在的位置： &
Docker Compose介绍： “应用层”的服务
Docker Compose介绍： “应用层”的服务
Docker Compose是Docker编排服务的最后一块，前面提到的 Machine可以让用户在其它平台快速安装Docker， Swarm可以让Docker容器在集群中高效运转，而Compose可以让用户在集群中部署分布式应用。简单的说，Docker Compose属于一个“应用层”的服务，用户可以定义哪个容器组运行哪个应用，它支持动态改变应用，并在需要时扩展。
Docker Compose是Docker编排服务的最后一块，前面提到的 Machine可以让用户在其它平台快速安装Docker， Swarm可以让Docker容器在集群中高效运转，而Compose可以让用户在集群中部署分布式应用。简单的说，Docker Compose属于一个&应用层&的服务，用户可以定义哪个容器组运行哪个应用，它支持动态改变应用，并在需要时扩展。
Docker Compose介绍
使用Compose的第一步是使用YAML文件来定义容器应用的状态：
containers:&web:&build:&.&command:&python&app.py&ports:&-&&&&volumes:&-&.:/code&links:&-&redis&environment:&-&PYTHONUNBUFFERED=1&redis:&image:&redis:latest&command:&redis-server&--appendonly&yes&
上面的YAML文件定义了两个容器应用，第一个容器运行Python应用，并通过当前目录的Dockerfile文件构建。第二个容器是从Docker Hub注册中心的Redis官方仓库中构建。 links指令用来定义依赖，意思是Python应用依赖于Redis应用。
定义完成后，通过下面的命令来启动应用：
%&docker&up&
简单吧？通过YAML文件定义的容器应用已经成功启动起来，启动过程会按照YAML的配置严格运行。Python容器通过Dockerfile自动构建， 同时从注册中心拉取Redis容器构建。 links指令关注的是Python和Redis容器之间的依赖关系，Redis容器是最先开始构建，紧随其后的是Python容器。
Docker Compose应用目前还在紧张开发中，感兴趣的读者可以关注 GitHub动态。
本文出自：【编辑推荐】【责任编辑： TEL：（010）】
关于&&&&的更多文章
OpenStack是一个美国国家航空航天局和Rackspace合作研发的，以Ap
180天的Windows Server 2012试用版下载（标准版或数据中心版）
讲师： 279人学习过讲师： 425人学习过讲师： 624人学习过
本专题将着重介绍Hyper-V在虚拟机网络方面的改进；网
【51CTO】技术牛人直通车――Windows Server 2012专列
在学校的教育里，信息化使以教师为中心、面对面、"黑
本书是为北大燕工教育研究院编写的计算机网络技术的学习教材。它以实际教学大纲为依据，全面系统的介绍了计算机网络技术知识
51CTO旗下网站Docker集群管理之Docker Compose
发表于 10:31|
摘要：Docker Compose是一个部署多个容器的简单但是非常必要的工具，Docker Compose在实际工作中非常有价值，相信随着Docker Compose的完善，其必将取代docker run成为开发者启动docker容器的首选。
前言：在上一篇中，我们通过源码分析了解了Docker Machine的工作原理，使用者可以通过Docker Machine的一条命令在任意支持的平台创建一个Docker主机，并能集中管理这些主机。Docker主机创建好之后，接下来就该考虑Docker容器部署的问题了。本篇中我们将通过分析Docker Compose的源码，了解Docker Compose的工作原理。预告：9月1日晚上8点整，杜航将通过在线培训的方式详细探讨《Docker集群管理三剑客》，报名地址请与容器技术同样受到关注的微服务架构也在潜移默化的改变着应用的部署方式，其提倡将应用分割成一系列细小的服务，每个服务专注于单一业务功能，服务之间采用轻量级通信机制相互沟通。同时数据库解决方案也在发生在变化，多种持久化混合方案（Polyglot Persistence）提倡将数据存放在最适合的数据库解决方案中，而传统的数据库解决方案将数据存在在同一个数据库服务中。服务数量的增加也就意味着容器数量的增多，逐渐增加的容器数量为容器部署，运行及管理带来了挑战。Docker Compose的出现解决多个容器部署的问题并提高了多个容器解决方案的可移植性。Docker Compose的前身是Fig，它是一个定义及运行多个Docker容器的工具。使用Docker Compose你只需要在一个配置文件中定义多个Docker容器，然后使用一条命令将多个容器启动，Docker Compose会通过解析容器件的依赖关系（link, 网络容器 –net-from或数据容器 –volume-from）按先后顺序启动所定义的容器。安装Docker Compose可以通过下载二进制可执行文件的方式安装Docker ComposeDocker Compose的工作原理Docker Compose将所管理的容器分为三层，工程（project），服务（service）以及容器（contaienr）。Docker Compose运行的目录下的所有文件（docker-compose.yml, extends文件或环境变量文件等）组成一个工程，若无特殊指定工程名即为当前目录名。一个工程当中可包含多个服务，每个服务中定义了容器运行的镜像，参数，依赖。一个服务当中可包括多个容器实例，Docker Compose并没有解决负载均衡的问题，因此需要借助其他工具实现服务发现及负载均衡。Docker Compose的工程配置文件默认为docker-compose.yml，可通过环境变量COMPOSE_FILE或-f参数自定义配置文件，其定义了多个有依赖关系的服务及每个服务运行的容器。以下是一个简单的配置文件：其定义了两个服务web和redis。web服务的镜像需要在当前目录实时构建，其容器运行时需要在宿主机开放端口5000并映射到容器端口5000，并且挂载存储卷/code以及关联服务redis。redis服务通过镜像redis启动。Docker Compose是由python语言实现的，它通过调用docker-py库（可参考/docker/docker-py）与docker engine通信实现构建docker镜像，启动停止docker容器等。Docker-py库调用docker remote API（可参考/reference/api/docker_remote_api/）与Docker Daemon通信，可通过DOCKER_HOST配置本地或远程Docker Daemon的地址。下面我们通过分析docker-compose最复杂的命令up的源码来了解一下docker compose的工作原理。通过命令docker-compose up -d启动以上docker-compose.yml定义的服务。我们可以看到redis服务先于web服务创建，这是因为docker-compose解析到服务间的依赖关系，web服务依赖于redis服务，所以进行了排序。我们来看一下docker compose up的工作流程。1. 工程初始化 – 解析配置文件（包括docker-compose.yml，外部配置文件extends files，环境变量配置文件env_file），并将每个服务的配置转换成python字典，初始化docker-py客户端用于与本地或远端的docker engine通信。2. 根据docker-compose的命令参数将命令分发给相应的处理函数，此处为up3. 调用project类的up函数，得到当前工程中的所有服务，并根据服务的依赖性（links，external links – 本工程或docker-compose之外的容器，多用于多项目共用容器，网络容器net-from以及数据容器volume-from）进行排序并去掉重复出现服务（此情况可因某服务被其他多个服务依赖所造成）4. &Docker Compose使用labels标记启动的容器使用docker inspect可以看到一个通过docker compose启动的容器被添加了一些compose使用的标记5. &Docker Compose通过compose工程名以及服务名从docker engine获取当前所有含有此标记的容器以检查当前工程所包含的服务状态，根据当前状态为每个服务制定接下来的动作。a. 若容器不存在，则服务动作设置为创建（create）b. 若容器存在但设置不允许重建，则服务动作设置为启动（start）c. 若容器配置发生变化（config-hash）或者设置强制重建标志，则服务动作设置为重建（recreate）d. 若容器状态为停止，则服务动作设置为启动（start）e. 若容器状态为运行但其依赖容器需要重建，则服务状态设置为重建（recreate）f. &若容器状态为运行其无配置改变则不作操作6. 根据每个服务不同的动作执行不同的操作服务动作为创建a. &检查镜像是否存在（调用docker-py client inspect函数从本地或远程的docker engine获取镜像信息）。若镜像不存在，则检查配置文件中关于镜像的定义。如果在配置文件中设置为build则调用docker-py build函数与docker engine通信完成docker build的功能。如果在配置文件中设置为image则通过docker-py pull函数与docker engine通信完成docker pull的功能。b. &获取当前服务中容器的配置信息，如端口，存储卷，主机名，使用镜像环境变量等配置的信息。若在配置中指定本服务必须与某个服务在同一台主机（previous_container，用于集群）则在环境变量中设置affinity:container=&container name&。通过docker-py与docker engine通信创建并启动容器。服务动作为重建a. 停止当前的容器b. 将现有的容器重命名，这样数据卷在原容器被删除前就可以拷贝到新创建的容器中了c. &创建并启动新容器，previsous_container设置为原容器确保其运行在同一台主机（存储卷挂载）d. &删除旧容器服务动作为启动则启动停止的容器7. &若docker-compose up没有指明-d即前台运行，则将所有各个容器的输出汇聚打印8. &注册信号SIGINT处理函数，若收到信号SIGINT则并行杀掉所有容器到此为止docker-compose up的命令执行完毕，docker-compose.yml文件中定义的服务 全部启动。Docker Compose的命令主要分为以下几类管理服务：up/start/scale/stop/restart/rm/kill管理镜像：build/pull查看服务运行状态：ps/port打印运行中的服务log：logs在一个服务中执行一个一次性命令：run以上这些命令都是通过label标记来过滤当前工程里的容器，然后调用docker-py库调用Docker remote API与docker engine通信控制容器。Docker Compose是一个部署多个容器的简单但是非常必要的工具，它使你使用一条简单的命令部署多个容器。Docker Compose在实际工作中非常有价值，其大大简化了多容器的部署过程，避免了在不同环境运行多个重复步骤所带来的错误可能，使多容器移植变得简单可控。从其Roadmap可以看出，Docker Compose的目标是做一个生产环境可用的工具，包括服务回滚，多环境支持（dev/test/staging/prod），支持在线服务部署升级，防止服务中断并且监控服务使其始终运行在正确的状态。Roadmap中的另一个目标是更好的与Docker Swarm集成，目前版本存在的主要问题是无法保证处于多个主机的容器间正常通信因为目前不支持跨主机间容器通信，我们相信新的Docker网络实现将会解决这一问题。另一个问题是在Docker Compose中定义构建的镜像只存在在一台Docker Swarm主机上，无法做到多主机共享，因此目前需要手动构建镜像并上传到一个镜像仓库使多个Docker Swarm主机可以访问并下载镜像。相信随着Docker Compose的完善，其必将取代docker run成为开发者启动docker容器的首选。作者简介：杜航，Websense云基础架构组开发经理，专注于Openstack和Docker。灵雀云资深用户。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章在长春市，一家鱼庄正在装修外墙，墙上挂满了“鱼”。
作为家中的独生女，父母虽不舍，但依然支持她的决定。
声明：本文由入驻搜狐公众平台的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
　　编者按：2015年的容器技术圈，是各家施展手脚封疆划土的扩张一年，也是Docker以及容器技术生态参与者不断完善自己的进化一年。本文作者张磊，浙江大学VLIS/SEL实验室云计算团队负责人，Kubernetes项目Collaborator。本文由36氪转载自微信公众号infoQ。
　　回顾2015年容器技术的发展历程，我们可以用两个关键词来概括：扩张与进化。
　　如果说2014年仅仅是Docker为主的容器技术在云计算以及DevOps圈初露锋芒的话，那么2015年则是以Docker为核心的容器生态圈迅猛扩张的一年。这种扩张的态势，一直从2015上半年火爆的DockerCon蔓延到了2015年的最后一天。伴随着容器技术快速发展的过程，国内外的技术人员有幸亲历了OCI、CNCF两大标准组织的确立，第一时间体验了Docker1.8和1.9两大关键版本的发布，见识到了CoreOS一系列关键技术革新与战略布局，也感受到了国内Docker创业圈的如火如荼。
　　国外容器技术项目
　　在2015年，一直以“善意独裁”面孔示人的Docker公司终于迈出了合作的第一步。OCI组织的成立宣告了工业界对Docker提出的容器技术的高度认同，也暗含了后进场玩家试图从这个由startup开创的新领域中分得一杯羹的决心。然而runC项目运作到现在，依然没能够进入DockerDaemon的实现主干，也没有任何巨头发布以runC为基础的新容器实现。Docker而不是runC被用户当作容器技术的事实标准的现状在短期内（1-2年）恐怕还很难发生本质改变。
　　容器技术领域多样化的任务目前还是落在直接竞争对手CoreOS，以及另辟蹊径的虚拟化容器技术比如Hyper和IntelClearLinux身上。但是无论如何，诞生于startup的Docker容器注定要经历更多的考验才能在巨头林立的云计算领域真正地扎根生长，无论其是否愿意，将容器技术标准化是这条道路上必须面对的选择和进化方向。
　　另一方面，Docker公司这种独一无二的亲和力和号召力正是2015年Docker为主的容器生态圈版图迅速扩张的主要基石。当然，既然是扩张，这张容器生态圈版图的背后也必然少不了大小领主“封地”的确立和斗争。
　　2015年，Google和RedHat联盟以Kubernetes1.0为阵地宣告了大规模容器编排与管理领域的领主地位。号称以Borg等Google多年容器技术实践经验为理论指导、以Google和RedHatPaaS团队为主要工程力量的Kubernetes项目一经宣布生产级别可用，便立刻吸引了的工业界乃至学术界的大量关注和投入。尽管不是第一家，但是我们不得不承认Google的号召力和Kubernetes不凡的背景直接推动了CNCF这一容器编排管理标准组织的诞生。
　　在技术方向上，Kubernetes团队则试图以Kubernetes为依托来对外输出Google的容器技术的思想和经验，或多或少有点要弥补LMCTFY项目中途夭折的意思。无论如何，Kubernetes所体现出的前瞻性的容器技术实践思路，确实值得我们每一个容器技术实践者重点关注和学习。无论是Pod及伙伴容器、单Pod单IP网络模型、volume插件机制、容器生命周期钩子这种对容器技术本身的改造，还是虚拟IP与负载均衡、垂直健康检查、密码数据卷管理、元数据API等平台级别能力的实现，都展现出了Kubernetes与其他编排管理项目与众不同的技术视野和团队实力。在未来发展方向上，Kubernetes已经开始向1000+节点的集群规模进发，毕竟在性能和规模化领域，Kubernetes没有理由落后竞争者太久。
　　另一方面，除了常规的longtimerunning任务，其他类型任务比如短任务和daemon任务的支持都已经引入了项目主干，类似bigdata业务的支持将是未来的一个重要方向。
　　在与Docker”分手“之后，CoreOS一直在积极地寻求展示自己技术想法的机会，包括加入OCI组织以及在Kubernetes上同Google开展深度的合作。鉴于OCI最开始只关注于containerruntime的实现标准，CoreOS的AppC一直在积极推进镜像标准的概念。目前这个标准已经在Kubernetes上初见雏形。最值得关注的是，CoreOS还在0.8.0版本发布时高调宣布了同IntelClearLinux团队合作在rkt上实现了基于虚拟化技术隔离的容器（这与国内的Hyper团队的做法不谋而合，只不过后者是在Docker上做出的类似实现）。
　　这种hypervisor-basedcontainer是目前在公有云上提供容器服务最佳选择，CoreOS在容器安全和隔离性问题上进行本质革新的做法的确很有说服力。而在容器编排管理领域，CoreOS公司将Kubernetes组件内置到CoreOS项目中作为主要的底层依赖之一。Etcd的作者目前也正在Kubernetes社区积极推进项目整体性能提升和调度效率优化的工作，毕竟作为整个项目的核心依赖，Etcd的作者们有足够的理由和能力承担起Kubernetes性能提升的重任。这一点上其他容器管理项目可能要稍微眼红一下了。
　　而在另一边，Mesosphere公司借助在资源调度管理领域与生俱来的优势，在2015年成功开拓出了一片以DCOS为核心、兼顾大数据和应用托管的服务平台市场。
　　ApacheMesos项目原生的两级调度和多框架支持使得用户在自己的组织内部设施云计算平台终于变得唾手可得。尤其是在传统技术型企业转型互联网架构的过程中，Mesos生态圈能够非常方便的在企业内部迅速实现一套原本在一线互联网公司中都算得上“黑科技”的资源调度管理平台，然后快速搭建起PaaS和BigData服务。尽管Mesos原生并非针对容器设计，Mesosphere所提供的诸如Marathon等上层解决方案也明显在成熟度和技术实现上有着这样那样的不足，但是不得不说Mesos生态体系目前是企业自建私有云最快速、最有利于展示POC的一套技术方案。
　　鉴于Mesos本身较难只针对Docker进行根本性的改造，Mesosphere生态圈目前依赖于Marathon等上层项目来响应Docker容器技术的快速发展，在这种形势下，一组包含了用户生命周期管理、多维度监控、整合大数据业务管理等功能的完善的PaaS很可能是这些上层框架的最终形态。
　　当然，最后一定要说的就是Docker公司了。在进入2015年之后，雄心勃勃的Docker公司在Docker源码层面开始了大规模的重构，将原先仓促发布的很多模块进行了统一的抽象和整合，使得在1.9版本彻底解耦Volume和Network成为了可能。
　　另一方面，Docker公司加紧了自己在组建生态圈闭环上的战略布局，这一点以年末收购Tutum为2015年画上了圆满的句号。之所以强调这一点，是因为Docker之前的收购对象都是在某一领域具有独创性的公司或团队，比如容器编排上的Fig，容器网络上的SocketPlane，而Tutum虽然在ControlPanel以及产品化上做的很早很出色，但是类似的竞争者却不在少数且产品能力也很强，更何况Docker公司自己在这一领域已经有所动作。所以Tutum最终胜出的确是自身技术和产品实力的最有力证明。
　　在技术路线上，Docker把同runC的集成列到了高优先级任务上，并且已经为之做了大量重构工作，但是奈何daemon同libcontainer的交互过于繁杂，此项工作进展一直缓慢。好消息是Docker在年末发布了Containerd项目来专门负责同runC进行交互，此项目最终会进入DockerEngine主干从而间接实现Docker同libcontainer的解耦。
　　一旦这个目的达成，Dockerdaemon的复杂度会大大降低，性能也很可能得到大幅提升，更重要的是届时容器开发者将有能力定制自己的daemon，在容器端加入定制化的功能和特性，这才是runC项目的真正意义和玩法，非常值得期待。Docker公司在2015年的另一个大动作便是1.9版本的发布终于完成了存储和网络功能的解耦，使得用户可以以插件的方式提供第三方存储和网络功能来支持远程数据卷和跨主机网络。
　　但是需要提醒读者的是，无论是网络还是存储，这些插件方式的工作原理与非插件方式并没有本质区别，Docker并没有能力也没有理由提供任何优化。所以在这一点上，普通用户在前期阶段需要寄希望于社区里的插件开发者的能力和技术水平不要太低。
　　因为我前面的经验表明即使是Docker官方比如SocketPlane提供的网络方案，在稳定性、可用性上也没有特别值得表扬的地方，建议用户保守上线该功能，必要时自己按需开发插件。“Docker之心，路人皆知”。这家已经在云计算领域掀起革命的startup背后的野心之大，的确配得上目前它在轻量级应用容器界的号召力和绝对地位。在未来的发展方向上，有如下几个方向上的进化是一定会发生的：
　　DockerEngine的进一步模块化和解耦，最终用户一定可以选择使用其中的一部分来达成自己的目的
　　runC全面取代execdriver来执行容器
　　更丰富的插件能力和以此为基础的数据卷管理能力（类似Flocker）
　　在容器编排与管理领域，Docker已经构建出了Compose+Swarm+Machine的技术闭环，这套技术栈的最大亮点是全面兼容DockerAPI。当然，这个优势的前提是目前Docker而不是runC仍然是业界公认的容器标准。在这个领域，Docker目前选择了重点照顾用户友好度而适当放弃性能和规模能力的路线，毕竟在兼容DockerAPI的前提下引入更复杂的编排、调度和管理能力是比较困难的。这也是为什么Swarm现在正在推进同Mesos集成以提高调度方面的性能和可扩展能力，虽然我认为这个路线可能并不太友好（想象一下宿主机上同时运行着Dckerdameon，Swarmagent和MesosSlave的场景）。
　　总之，Docker目前在容器界的领导地位已经毋庸置疑。一系列产品和技术布局的完成也确立了Docker公司在这一由它自己开拓的疆土上的霸主地位。接下来，如何在不甘心的巨头们设置的规则丛林里生存、壮大并且健康发展下去，甚至达成Linux项目的创举，则是考验这家已经创造了一个不小的奇迹的初创团队真正实力和水平的难题。
　　与国外相比，以Docker为主的容器技术在国内的发展势头甚至要更猛烈一些，其中部分原因是因为2014年以前的PaaS风潮没能够在国内掀起本质上的变革，使得国内云计算圈子在除了IaaS之外的领域颇有点一筹莫展的感觉。在这层意义上，Docker容器技术的诞生和普及绝对起到了久旱逢甘霖的效果。容器创业组织雨后春笋般萌发，不少团队的背景也跟经典PaaS领域息息相关；另一方面原先经典PaaS从业者的转型到容器创业领域的也不在少数。所以目前国内Docker创业项目的产品形态，有一部分延续了原先PaaS项目的产品路线（尤其是CloudFoundry），比如：
　　重点关注应用生命周期管理
　　强调应用访问和域名绑定
　　纳入Docker的部分概念比如数据卷和镜像
　　对用户屏蔽网络、存储和调度细节
　　将数据库等应用依赖抽象成”服务”
　　而另外一部分则选择了稍微偏向通用化的产品形态，这类项目一般会强调自己为CaaS（ContainerasaService），例如：
　　更多地对外暴露Docker容器各类概念
　　强调容器的IP而不是域名
　　不区分应用和它所依赖的“服务”
　　强调直接运维容器而不是应用
　　这种类型的创业组织提供出来的更类似基于容器的IaaS，意在给用户更大的自由度和发挥空间。当然，无论哪种形态，大家一般都会把CI/CD流程的支持纳入到自己的主要产品体系，毕竟这是Docker最受大家认同的一个场景；而且各家产品也都在功能上互相渗透，其实并没有一个非常明确的边界。
　　从这个角度出发，当前的大多数创业组织的产品在大方向上会逐渐趋同，毕竟Docker本来的发展路线也是淡化云计算的分层理念，变轻，变薄。然后在小方向上营造差异化，比如有的组织会选择构建各类开发者工具形成产品链，有的会选择在Infra层面提供更优质、廉价、可靠的计算和存储资源（比如SSD，高效的调度策略，最大程度压榨IaaS层利用率，甚至提供基于虚拟化技术的容器以彻底解决安全和隔离性问题）。
　　总之，目前国内容器创业圈子产品能力优秀，相比之下即使是刚刚被Docker收购的Tutum恐怕在这一领域也没有太多优势；但是创新能力稍显不足，各个技术和产品点都是跟随者，尚没有展现出自己独有的优势。
　　2015年国内容器技术圈的另一大事件便是巨头的跟进。各类互联网甚至传统技术企业在自己内部进行容器的规模化应用的案例早已不是新闻，而阿里云，阿里百川TAE，新浪SAE，网易等诸多厂商也都在2015年开始对外提供或基于容器提供云计算服务，我们相信还有更多的团队还在酝酿中。一般来说国内的AE类型的厂商（TAESAEBAE）会优先选择提供PaaS类型的产品，原先的IaaS厂商则更愿意提供容器云服务。
　　不管是哪种形态，国内容器服务的热度值的确做到了另前来布道的Docker、Google的老外们都惊叹不已的程度。但是稍微令我担忧的是，这种热度的发展，可能会过早的将国内容器技术提供商拖到价格战的泥潭，届时大家过早停滞技术和产品的打磨而开始拼价格、拼渠道、拼运营，长远来看可能并不利于国内容器圈子的发展。
　　关于传统PaaS和laaS
　　国内容器技术热火朝天的背后，或多或少反衬出了传统PaaS和IaaS提供商的些许落寞。而事实上，传统PaaS和IaaS厂商在2015年依旧取得了不菲的成绩，仅以PivotalCloudFoundry为例，其商业产品已打入了大量国际一线制造业和金融业巨头，仅其中某一个大客户的日均运行容器数量恐怕目前尚没有哪家互联网公司能望其项背。
　　就这一点而言，目前的Docker容器服务商恐怕在很长一段时间之后都很难出现这种规模和高质量的客户案例。但是商业归商业，开发者归开发者，Docker为主的容器技术掀起的风潮起始于一线技术人员，也风靡于一线技术人员，这与商业产品的成功路线本质上就是不同的。这也正是为什么很多PaaS和IaaS厂商2015年甚至更早开始宣布支持Docker的最主要原因，OpenShift甚至完全转型基于Kubernetes进行彻底重构。但是无论如何，在关系更密切的开发者服务场景下，目前startup做的更好。
　　另一方面，OpenStack社区也在积极的寻求同Docker等容器技术的结合点来试图扩展一线技术人员这一不能忽视客户群，但是稍显遗憾的是哪怕是2015年被反复提及的Magnum项目都没有针对容器而对OpenStack本身做本质的改进和集成，项目依然是停留在调用OpenStackAPI然后把容器运行在VM里的程度。
　　我认为，考虑到当前情况下虚拟机的不可替代性，OpenStack如果能够提供虚拟机和物理机上容器的统一调度，或者引入类似Hyper或者ClearLinux这样的虚拟化技术容器，进而提供任务优先级、抢占、混部等一系列数据中心级别的高级特性，也不失为一种进取的手段。仅就OpenStack社区目前的应对方案来看，仍然不足以解决开发者的目光被Docker吸引并且采用容器作为OpenStack替代方案的情况。当然，OpenStack无论是社区质量、规模还是产品、生态圈都不是现在的Docker所能挑战的，只是在社区层面对Docker以及容器技术的支持上做的还不够好。
　　综上所述，2015年的容器技术圈，是各家施展手脚封疆划土的扩张一年，也是Docker以及容器技术生态参与者不断完善自己的进化一年。总的来说，尽管有不少亮点涌现，这一年的容器技术仍然处于厚积阶段，标准尚未达成，社区缺乏平衡，跟进者多创新者少。
　　但是，我们也不得不考虑到很可能这才是容器技术发展的一种常态，而不是重复其他开源项目的发展模式。或许在未来，容器技术生态圈的参与者始终会保持着这种不断进化的姿态以应对瞬息万变的应用场景和捉摸不定的开发者意图，很难达成一种平衡或者稳定的状态。毕竟在容器技术这种无限贴近于每一个一线技术人员的特殊领域里，“唯有适者，才能生存”。
欢迎举报抄袭、转载、暴力色情及含有欺诈和虚假信息的不良文章。
请先登录再操作
请先登录再操作
微信扫一扫分享至朋友圈
搜狐公众平台官方账号
生活时尚&搭配博主 /生活时尚自媒体 /时尚类书籍作者
搜狐网教育频道官方账号
全球最大华文占星网站-专业研究星座命理及测算服务机构
河南省唯一重点新闻网站，是经河南省委、省政府同意，由河南报...
229962文章数
主演：黄晓明/陈乔恩/乔任梁/谢君豪/吕佳容/戚迹
主演：陈晓/陈妍希/张馨予/杨明娜/毛晓彤/孙耀琦
主演：陈键锋/李依晓/张迪/郑亦桐/张明明/何彦霓
主演：尚格?云顿/乔?弗拉尼甘/Bianca Bree
主演：艾斯?库珀/ 查宁?塔图姆/ 乔纳?希尔
baby14岁写真曝光
李冰冰向成龙撒娇争宠
李湘遭闺蜜曝光旧爱
美女模特教老板走秀
曝搬砖男神奇葩择偶观
柳岩被迫成赚钱工具
大屁小P虐心恋
匆匆那年大结局
乔杉遭粉丝骚扰
男闺蜜的尴尬初夜
客服热线：86-10-
客服邮箱：}